IoTScanner Detecting and Classifying Privacy Threats inIoT Neighborhoods

Sandra Sibysandra_ds

sutdedusg

Rajib Ranjan Maitirajib_maiti

sutdedusg

Nils Ole Tippenhauernils_tippenhauer

sutdedusg

Singapore University of Technology and Design (SUTD)8 Somapah Road487372 Singapore

ABSTRACTIn the context of the emerging Internet of Things (IoT) aproliferation of wireless connectivity can be expected Thatubiquitous wireless communication will be hard to centrallymanage and control and can be expected to be opaque toend users As a result owners and users of physical space arethreatened to lose control over their digital environments

In this work we propose the idea of an IoTScanner TheIoTScanner integrates a range of radios to allow local re-connaissance of existing wireless infrastructure and partic-ipating nodes It enumerates such devices identifies con-nection patterns and provides valuable insights for techni-cal support and home users alike Using our IoTScannerwe attempt to classify actively streaming IP cameras fromother non-camera devices using simple heuristics We showthat our classification approach achieves a high accuracy inan IoT setting consisting of a large number of IoT devicesWhile related work usually focuses on detecting either theinfrastructure or eavesdropping on traffic from a specificnode we focus on providing a general overview of operationsin all observed networks We do not assume prior knowledgeof used SSIDs preshared passwords or similar

1 INTRODUCTIONIn the context of the emerging Internet of Things (IoT) a

proliferation of wireless connectivity can be expected withpredictions reaching as many as 500 smart devices per house-hold in 2022 [17] Heterogeneous smart devices that re-quire transparent Internet connectivity need to be integratedinto a common infrastructure In particular communicationstandards such as Zigbee Bluetooth Bluetooth Low Energyand WiFi are expected to provide such infrastructure eitheras mesh networks or traditional single-hop access pointsOften vendors will sell their own application gateway withintegrated access point which to a certain degree hides theunderlying communication from the owner Although wire-less communications have many benefits in terms of usabil-ity flexibility and accessibility there are also security con-cerns [34] Among those concerns are privacy and in generalcontrollability With this growth in the size and complexityof wireless networks appropriate tools are required to betterunderstand the environmentrsquos wireless traffic

In this work we propose the idea of an IoTScanner TheIoTScanner is a system that allows for passive real-timemonitoring of an existing wireless infrastructure The IoTScan-

ner classifies and identifies devices that are communicatingusing the infrastructure and traffic patterns among the par-ticipating devices The IoTScanner will supply this infor-mation in a structured manner so as to provide valuableinsights for technical support and home users alike

While related work usually focuses on detecting either theinfrastructure or eavesdropping on traffic from a specificnode we focus on providing a general overview of opera-tions in all observed networks We do not assume priorknowledge of used SSIDs preshared passwords or similarIn addition to this the IoTScanner operates passively with-out active probing or other transmission Our emphasis isalso on providing real-time analysis and visualization of thescanned network unlike some related work that focuses onoffline analysis

We note that we do not consider physical layer effectssuch as collisions and packet loss goodput or interferencebetween networks in this work We leverage recent develop-ments in the area of cheap software-defined radio modulesto handle the physical layer of the wireless traffic to providethe Link layer traffic As most wireless communication stan-dards nowadays by default encrypt the Link layer payloadwe consider only Link layer traffic for analysis in this work(without considering higher layer traffic) In particular weaim to address the issue of providing controllability and pri-vacy to the user of an IoT environment The IoTScannercan provide details on the devices the links between themand the amount of traffic in any environment in which it isplaced This information can then be used to classify andidentify devices that could impact the privacy of the userThree communication standards (WiFi Bluetooth Low En-ergy (BLE) and Zigbee) are considered in this work

We summarize our contributions as follows

bull We identify the issue of opaqueness in IoTsintegrationof heterogeneous IoT devices will lead to a plethora ofwireless standard and networks operated in parallelWithout a system like the IoT scanner it will be diffi-cult to keep overview of communication in a space (inparticular for third-party networks)

bull We propose an abstract system design that allows toseamlessly integrate a range of radio devices with ascanning server The serverrsquos data can then be ac-cessed by users through a RESTful API The data ob-tained via the REST API can then be used for visual-ization of the scanned environment and further analy-

arX

iv1

701

0500

7v1

[cs

CR

] 1

8 Ja

n 20

17

sis

bull We present an implementation of the proposed designand demonstrate its effectiveness through a set of ex-periments

bull We discuss how our system can be potentially used toidentify privacy threats in an IoT environment

The structure of this work is as follows In Section 2 webriefly summarize the relevant background for our work Wepropose our system design for the IoTScanner in Section 3Our implementation is described in Section 4 In Section 5we run some experiments to evaluate our implementationin an environment that consists of WiFi devices In addi-tion we discuss the feasibility of the IoTScanner to performtraffic classification and device identification in this sectionSections 6 and 7 describe experiments in BLE and Zigbeeenvironments We discuss some of the challenges we facedin Section 8 Related work and comparison of features withexisting tools is summarized in Section 9 We conclude thepaper and discuss possible future work in Section 10

2 BACKGROUND

21 Internet of ThingsThe Internet of Things (IoT) refers to a network of phys-

ical devices that have the capability of gathering and trans-ferring data from the environment and interacting with re-mote computers over Internet [4 18] IoT devices can beanything from cellphones to smart lamps as long as theyhave the ability to transfer data over the Internet which es-sentially means they are assigned some public IP addresses

22 Passive MonitoringPassive monitoring is a technique for observing the traffic

in a network only by listening to signals that are alreadyavailable in the network without injecting any extra signalUnlike active monitoring passive monitors do not probe thedevices they are observing [22] In the context of wirelessnetwork the technique is more suitable as it only requiresa traffic interceptor to be physically present in the envi-ronment without requiring any wire tapping or so Devicescalled sniffers or monitors are placed in the network to inter-cept frames transmitted by devices in their vicinity Radiosthat can be used to sniff different standards (WiFi Blue-tooth Zigbee) are available on the market and can be usedfor passive monitoring

23 System ModelIn our systems model we assume that there are one or

more wireless networks in an IoT scenario in which the scan-ner is placed For example in a smart home the electronicgadgets like smart lighting can make use of Zigbee commu-nication personalized health monitoring can use BluetoothInternet access can happen via WiFi communication Thescenario can have one or more IoT devices but not all thedevices need to be active (ie sending or receiving someinformation) all the time For example a smart blood pres-sure monitor may get activated only about 2-3 times a daywhereas smart light need to be active throughout the dayIn the basic operation mode the scanner needs no priorknowledge of the infrastructure and network configurationin the IoT environment ie no information is required about

which device used for what purpose or what kind of encryp-tion is used by them if any We assume that the user of ourIoTScanner system does not have any control over the de-vices or know if they are present or where exactly they arelocated Hence there is a chance that IoT devices that arepresent in the environment (but not actively participatingin the network) are not detected by the scanner

24 Attacker ModelWe assume a limited attacker who is honest but curious

For example the attacker might access a webcam set up in aroom to spy on persons in the room but the attacker will notset up a dedicated device for this (in particular the devicewill not use some non-standard wireless communication)By obtaining the images from the camera over a certaintime period the attacker violates the privacy of the userHow the attacker obtained access to the camera does notmatter for our analysis

As we do not assume that we have control over the net-work(s) in the environment we will not be able to detectthe camera activity on the Network Layer or at a gatewayor similar

3 A PASSIVE ANALYSIS FRAMEWORKIn the following we provide details on our proposed pas-

sive analysis framework We start with a concise problemstatement summarize the intuition behind our design andthen provide additional details on individual components

31 Problem StatementIn this work we address the following problem ldquoIn an IoT

environment which devices are present and communicatingvia wireless communicationsrdquo That information can thenbe used to address questions such as ldquoAre the IoT devices inmy environment used by an attacker to violate my privacyrdquoIdeally such a goal should be reached passively withoutactively interfering with the environment (which could be apublic place such as an airport hotel or similar)

This problem cannot be solved by normal end-users easilyit requires specific software hardware and technical under-standing of wireless protocols We refer to this challenge aswireless opaqueness for the end users they are agnostic tothe way networking works which links exists and how dataflows in the neighborhood

32 IntuitionTo address the problem stated above we now propose the

IoTScanner The aim of the IoTScanner is to provide real-time passive monitoring of an existing wireless infrastruc-ture that potentially constitute an IoT environment Thescanner will identify active devices that are communicat-ing using that infrastructure and attempt to categorize IoTtraffic depending on features such as the volume of trafficobserved

In particular we use to following constraints to achievepassive monitoring The IoTScanner

bull will not associate with any access point present

bull will not perform active probing or fingerprinting and

bull will not decrypt the observed network traffic

Traffic Interceptor Traffic Analyzer Data Storage Visualizer

Figure 1 Overview of the IoTScanner architecturewhich consists of four modules traffic interceptortraffic analyzer data storage and traffic visualiza-tion

The IoTScanner only observes the network traffic at the Linklayer and then analyzes this traffic using frame header in-formation A more offensive active scanner would not needto follow those constraints

The long term goal is to turn the IoTScanner into a con-venient hand-held device In the context of this paper weare using a Raspberry Pi 3 [31] as platform together withdevices such as Android tablets for visualization via a webapplication

33 IoTScanner System ArchitectureThe main features provided by our IoTScanner are ubiqui-

tous (wireless) signal interception packet filtering analysisof the captured packets and storage of the results Finallyresults will be accessible via APIs to be visualized througha web-based visualization system

Figure 1 shows the overall architecture of our proposedPassive Analysis Framework termed as IoTScanner TheIoTScanner has four main functional modules traffic inter-ceptor (captures wireless signals) traffic analyzer (analyzesMAC frames) data storage (stores processed frames and re-sults) traffic visualizer (displays the status of network)

Each of these modules is described in detail in the follow-ing We provide a detailed comparison of the IoTScannerwith other related projects in Section 9

34 Traffic InterceptorThe traffic interceptor module provides flexible low level

access to the wireless medium In the context of IoT widelyused protocols are 80211WiFi Bluetooth Bluetooth LEZigbee and Z-Wave each being prevalent in particular ap-plication area(s) For example the devices accessing In-ternet primarily use WiFi wearableon-body devices (egblood pressure monitor smart watch) use Bluetooth or Blue-tooth LE to connect to their parent devices smart homeappliances (eg smart meter) use Zigbee and electronicappliances (eg AC fridge fan) use Z-Wave protocols [4]However there is no clear line of separation on what devicecan use which protocol it primarily depends on the usageof the devices or the energy consumption behavior of themTherefore it is important to have interception capabilitiesleveraging multiple radios either one radio for each proto-col or software defined radios to cope up with the varietyof protocols available in the IoT spectrum

If multiple channels of the same standard should be reli-ably monitored it might even be necessary to use multipleradios of the same kind each on its own channel

35 Traffic AnalyzerThe traffic analyzer scrutinizes each Link layer frame cap-

tured by the traffic interceptor by parsing only the frameoverhead (ie header and trailer) harnessing on passive anal-ysis philosophy of the IoTScanner It extracts relevant infor-mation such as the source and destination addresses frametype and sub-type SSIDs present from those the framesto be used for targeted analytics We note that the framesneed to be treated on a protocol by protocol basis becauseparsing Bluetooth LE frames is significantly different fromparsing WiFi frames or Zigbee frames In addition the ana-lyzer records some additional useful information such as thechannel number on which the interceptor is capturing traf-fic size of the frame captured (in bytes) and the timestampat which the frame is captured It sends the extracted frameinformation to the data storage module on per frame basiswhere actual analytics is performed

36 Data StorageThe data storage module acting as a simple server pro-

vides a stable storage unit primarily for storing processedinformation about individual frames The storage can bedone by various means however we prefer to employ a sim-ple and light weight database system In addition to storingthe information the system provides a simple interface forquerying the database to carry out analytics For exam-ple the data storage interface can be realized using a set ofRESTful APIs that can easily accessed over Internet and beused by third-party applications The APIs are provided forthe following functions storage and retrieval of frame infor-mation generalized categorical queries on the DB storageand retrieval of analysis results

37 Traffic VisualizerThe traffic visualizer provides a visual representation of

the observed IoT environment at a particular time windowA network ie an IoT environment can be viewed fromdifferent perspectives starting from device-to-device connec-tion to device or link specific information to semantics of theunderline possibly collaborative activity performed by IoTestablishment In this paper we consider a mix of all theseperspective at a high level for an initial comprehension of theIoT environment where we display a graphical view of theunderlying network along with some supporting descriptionof the devices and the associated links if any We do notinfer any application specific information eg if the IoT isused for maintaining room temperature by controlling ACrather our interest in this paper is to create an inventoryof the devices present and the amount of traffic generatedby each of those devices Because the devices need not besending or receiving frames all the time the traffic visual-izer needs to automatically and periodically update to reflectany changes (in terms of both the devices and links) in theIoT environment under surveillance Note that the visual-izer displays only those nodes and accounts for only thoselinks that are present in the database currently

4 SYSTEM IMPLEMENTATIONIn this section we present our implementation of the four

proposed IoTScanner modules (traffic interceptor traffic an-alyzer data storage and traffic visualizer) An overview ofour implementation is shown in Figure 1 We use differentwireless interfaces for the traffic interceptor Scapy (a python

library) for the traffic analyzer SQLite for the data storageand Javascript for the data visualization The data storageuses RESTful APIs to communicate with the analyzer andthe visualizer modules The interceptor and analyzer com-ponents run on a Raspberry Pi 3 device the data storage canbe run on the same device or a server and the visualizationis displayed on an Android Tablet

41 Traffic InterceptorThe traffic interceptor module can be implemented by a

number of radio interfaces or by using software defined ra-dios We decide to use the following radio interfaces that arecommercially available and connectable via USB the TP-Link TL-WN722N 80211n wireless adapter (for WiFi) theUbertooth One (for Bluetooth LE) and Atmel-RZUSBstick(for Zigbee)

The TP-Link TL-WN722N adapter [36] can be easily con-figured to operate in monitor mode and capture WiFi frameswith configurable channel hopping (over 13 channels) Theadapter can also support certain active attacks such as deau-thentication attacks a useful feature in case we extend thefunctionality of the IoTScanner to include traffic decryp-tion We perform sequential channel hopping to obtain anoverview of the traffic on all channels The interface dwellson a particular channel for a certain period of time beforehopping to the next channel The dwell time can be config-ured by the user otherwise takes a default constant value

We note that since we dwell on a single channel at a timeframes on channels the interceptor is not listening on willnot be captured Hence we capture a subset of the overalltraffic

For Bluetooth Low Energy (BLE) traffic capture we usethe Ubertooth One [29] an open source Bluetooth moni-toring platform Compared to other Bluetooth monitoringsolutions this platform is inexpensive and easily adaptableto our settings We focus on Bluetooth Low Energy (BLE)traffic as its presence is increasing in IoT devices especiallythose used in healthcare The Ubertooth One is able todetect the channel hopping map from sniffed BLE connec-tion request packets and follow connections by hopping inthe same pattern The Ubertooth also has a promiscuousmodemdashto follow connections that were already establishedat the time of sniffing As in the case of WiFi the intercep-tor may miss out some devices as result of channel hoppingwhich may be compensated by increasing the observationperiod

For Zigbee traffic capture we use the RZUSBstick fromAtmel [3] which supports low power wireless applicationsusing Zigbee 6LoWPAN and IEEE 802154 networks Thisadapter can also perform channel hopping (over 16 channelsfrom channel 11 to channel 26 in the 24 GHz band) Otherfeatures of this traffic capturing procedure is similar to WiFior Bluetooth networks

42 Traffic AnalyzerThe traffic analyzer module consists of three sub-modules

extractor collector and storage handler as shown in Fig-ure 3 The extractor and the collector modules are imple-mented using Scapy [6] a python library for packet cap-ture and analysis Every frame captured by the traffic in-terceptor is an input to both the extractor and collectorsub-modules Since the aim of the IoTScanner is to pro-vide a quick overview of the IoT environment only rele-

vant pieces of information are extracted from every capturedframe This is performed online (without buffering) so asto find quick answers to only those questions that we haveassumed to be sufficient to provide an overview of the envi-ronment The extractor module extracts the following fromthe respective frames

bull In WiFi frames (type sub-type length MAC addressand SSID)

bull In Bluetooth LE frames (type length MAC addresstype (public or random) MAC address node localname)

bull In Zigbee frames (type length PAN ID addresses )

The collector module collects information such as the sys-tem time during frame capture the channel number on whichthe frame is captured and the RSSI (for potential devicelocalization) Both of these modules supply the capturedinformation to the storage handler module

The storage handler sub-module sends the collected andextracted information to the data storage module It sendsthe frame information (in JSON format) to the data stor-age module via HTTP POST method The module alsohas the option of storing the frames in a PCAP file and pe-riodically sending the files to the data storage for furtheranalysis of the overall traffic (which might be more compu-tationally intensive) It is worth mentioning that high levelframe analysis is not possible at the traffic analyzer sincethis requires aggregated information from multiple framesand hence such analysis is performed at the data storageserver end

43 Data StorageThe data storage module of the IoTScanner provides a

database server to be accessible via a set of APIs to storeand retrieve the extractedcollected frame information Twomodules the traffic analyzer and the traffic visualizer inter-act with the storage module using these APIs over networkpotentially the Internet We have implemented this moduleas a web server which interacts with a light-weight databaseThe APIs in the server are developed using Flask (a Pythonweb framework) which helps to easily build the RESTfulAPIs for our purpose We use SQLite to build a light-weightrelational database system for our data storage module

44 Traffic VisualizerWe implement the traffic visualizer using Javascript with

D3 [7] library for network visualization The visualizer iscompatible with any hand-held devices such as smart phonestablets etc in addition to the desktop browsers The vi-sualizer displays the IoT environment in a number of ways(eg summary text connectivity graph bipartite relationetc) to make it suitable for the user to understand differentaspects of the underlying network By default it displays anetwork graph accompanied by a brief summary text

Figure 4 shows a sample network graph obtained duringone of our experiments The colored circles represent thenodes in the network and the arrows between a pair of nodesindicate that the pair exchanged at least one frame Weidentify the access points from beacon and probe requestframes and internet gateways using simple heuristics Theaccess points and gateways have icons to identify them inthe visualizer

Figure 2 Overview of IoTScanner implementation

Figure 3 Traffic Analyzer module of our IoTScan-ner for WiFi frames

Our visual display is interactive in the sense that on se-lecting a node or an edge more details about the selectedcomponent are displayed For example in the Figure 4 theselected nodes and edge are highlighted in red and their de-tails are displayed in the sidebar The graph is updated at afixed interval of p (configurable) seconds in order to reflectany changes in the number of devices or the communicationlinks in the network

Our overall implementation using the Raspberry Pi as in-terceptor (along with the tablet as visualizer) is shown inFigure 5

5 WIFI EXPERIMENTSIn all our experiments we place the scanner in an IoT

testbed [33] that contains a number of IoT devices Weconduct experiments with devices that use WiFi BluetoothLow Energy and Zigbee communication with a larger focuson WiFi enabled devices since it is the predominant modeof communication for IoT devices We perform our exper-iments in three phases after grouping the devices based onnetworking technology In this section we discuss the exper-iments using WiFi enabled IoT devices Experiments withBLE and Zigbee are described in Sections 6 and 7

51 IoTScanner configurationThe IoTScanner while intercepting WiFi traffic uses two

Figure 4 Example screenshot of our visualizationapp IoT scenario represented using a graph struc-ture Selecting a node (red circle) in the graph dis-plays the details about the underlying device

input parameters

bull Dwell Time (Td) period of time (in seconds) that thetraffic interceptor listens on a channel before movingto next channel (Td isin 5 10 20 30(default) 40 50 60)

bull Hops Th number of channel hops performed by thetraffic interceptor (Th isin 1 6 13(default) 26 65 130)

These parameters account for the amount of time theIoTScanner is exposed to an IoT environment for exam-ple Th = 13 and Td = 5s implies that the traffic interceptorscans for 13 times 5 = 65s and the analysis will be performedonly on the traffic captured during this period

52 Evaluation metricsFollowing are the common metrics for our experiments

bull nodes the total number of active devices in the ob-served environment (including access points) A de-vice is considered to be active if it is observed to havesentreceived at least one frame

bull links the number of unique pairs of nodes that haveexchanged at least one frame (excluding broadcast andmulticast frames)

bull SSIDs the number of access points seen in the envi-ronment

Figure 5 IoTScanner with visualization on a hand-held device

bull Frames the total number of frames (sent or received)per device these are further classified by type intocFrames (control) mFrames (management) and dFrames(data)

bull Bytes the aggregated number of bytes (sent and re-ceived) per device these are further classified by typeinto cBytes (control) mBytes (management) and dBytes(data)

53 Experiment SettingsIn our controlled experiments we use six IoT devices one

Nest Cam security camera one Netatmo camera (with facerecognition feature) one TP Link security camera (of rela-tively lower resolution compared to the other two cameras)one Amazon Echo wireless speaker one desktop with wire-less adapter (to perform general web surfing) and one WiFiaccess point We conduct 10 experiments each in a high-load(being default setting) and a low-load setting

High-load This is the default setting for our experimentsand in this setting all three cameras (focusing on the samearea) are actively streaming video via Internet to a mobiledevice located outside the test environment The AmazonEcho [2] loudspeaker is streaming audio songs continuouslyduring the experiments The desktop with wireless adapteris used to browse web pages intermittently

Low-load In this setting all the devices are present butnone of them are actively used For example the IP camerasare switched on but the live video is not accessed TheAmazon Echo is kept on but is not playing any music

Understanding the Network Structure First we ver-ify if IoTScanner can identify the nodes (with their MACaddresses) and the links among them from the capturedtraffic hence determining the underlying network structureWe observe that our IoTScanner can correctly capture traf-fic from all the six devices in each of our experiments Thescanner identifies the devices that sent out broadcast framesto advertise their presence in the network and the wirelesschannels on which each of these devices sentreceive trafficWe experiment with various values (as noted earlier) of thetwo input parameters dwell time (Td) and hops (Th) We

Label Device Name

Dev-1 DesktopDev-2 Netatmo cameraDev-3 TP-Link cameraDev-4 Access PointDev-5 GatewayDev-6 Amazon EchoDev-7 Nest Cam camera

Table 1 Device labels and the corresponding de-vices used in WiFi experiments

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000000

2000000

3000000

4000000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

5000

6000

7000B Frames

total mframes cframes dframes

Figure 6 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in high-load setting

observe that lower values of these parameters result in thescanner being unable to capture all the devices during theobservation window After multiple rounds of experimentswe conclude that Td = 30 and Th = 13 are optimal values toquickly capture a sufficient amount of traffic for the trafficclassification analytics we want to perform Finally we usebeacon and probe request frames to identify access points inthe network and simple heuristics (on amount of data anddestination MAC addresses) to identify the Internet gate-way

Results of these experiments are not presented here asthey are used more as a check of the correctness of ourIoTScanner system We present more interesting resultsthat are obtained from the traffic analyzer of our systemon device classification in an IoT environment

54 Per-node Traffic ClassificationWe perform simple analytics on the captured traffic to

classify IoT devices The mapping between the device labelswe use and their actual name is shown in Table 1

Frames mFrames cFrames and dFrames First wefind the total amount of traffic associated with each device

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0100000200000300000400000500000600000700000800000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

B Frames

total mframes cframes dframes

Figure 7 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in low-load setting

in the network along with the type (management controland data) in the high-load setting We determine the trafficin terms of bytes (Figure 6A) and frames (Figure 6B) Aframe is associated with a device if its MAC address is foundin the frame either as the source or destination address

Interestingly it can be seen that the traffic amount andits type can classify the devices at a high level For exam-ple the highest amount of traffic in terms of both bytesand frames is associated with Dev-4 which is the accesspoint (see Table 1) that connects to all other devices presentDev-5 which has no control and management frames is thegateway device connected through Ethernet to the accesspoint The lowest amount of traffic is seen in Dev-1 thedesktop and it is used for occasional browsing during theexperiments The rest of the devices (Dev-2 Dev-3 Dev-6and Dev-7) are associated with high traffic as they are ei-ther IP cameras or the Amazon Echo performing continuousstreaming In each of the devices it can be seen that thedata traffic (in bytes) dominates the control or managementtraffic and is almost equal to the total amount of traffic ofthe corresponding devices However the difference betweenthe number of control and data frames is not as high es-pecially in the case of the cameras We observe that theacknowledgement frames contribute to the large number ofcontrol frames in this case

We explore the traffic volume in low-load settings (resultsshown in Figure 7) It can be seen that almost all the deviceshave control traffic comparable to data traffic (in bytes) asopposed to high-load settings where data traffic dominatesthe control traffic In fact standard deviation of traffic vol-ume is quite significant in this setting in all the devicesperhaps because the devices send their status informationmore at times Thus an analysis of the traffic amount andits composition can potentially be used to learn if an IoTsetting generates a high volume of data traffic

Sent and Received Volume Since the overall traffic

mainly consists of data frames we investigate the amountof data traffic (in terms of bytes and number of frames) sentand received by each device (Figure 8 shows results in high-load settings) The highest amount of traffic (either sentor received) is observed in Dev-4 which is the access pointDev-5 (the gateway) has about three times higher receivedtraffic (in Bytes) as compared to sent Note that the traffictowards the Internet is the received traffic for the gatewayand traffic coming into the local network accounts for sentfor it Thus the result is consistent with the ground truthas there are three cameras sending video traffic We also no-tice that the cameras (Dev-2 Dev-3 and Dev-7 ) have a highamount of sent traffic as expected However the amount ofsent traffic varies significantly among the cameras The re-ceived traffic is higher than the sent traffic for Dev-6 whichis the Amazon Echo continuously streaming and playing au-dio songs from its server Our experiments indicate thatactive IoT devices such as IP cameras or music streamingdevices can be identified by analysis of sent and receivedtraffic volumes in high-load settings

We also investigate traffic flow in the low-load settings(results shown in Figure 9) Surprisingly it can be seen thatcameras do not necessarily produce a higher amount of senttraffic compared to receive traffic (eg Dev-2) The AmazonEcho sends and receives almost equal amount of data in thissetting As expected the gateway still receives more datathan it sends probably because these IoT devices continueto update their status to their associated cloud servers

Sent-to-Received Ratio We explore the possibility ofidentifying the devices by computing the ratio of sent toreceived traffic (in terms of both bytes and frames) Weconsider only data traffic for this analysis and ignore man-agement and control frames Figures 10A and 10B show thesent-to-received ratios in high-load and low-load settings re-spectively In the high-load setting the IP cameras (Dev-2Dev-3 and Dev-7 ) have a ratio greater than 4 for traffic inbytes and greater than 15 for traffic in number of framesThis indicates that an IP camera that actively streams videotraffic may potentially be identified when the ratio is greaterthan 10 Also the ratio in bytes is greater than the ratio inframes for the cameras implying that per frame a largeramount of data is originated from the cameras The desk-top with adapter (Dev-1 ) has a lower ratio (gt10) than thecameras but higher than the access point (asymp 10) and gate-way (lt10) The ratio of frames is much higher than theratio in bytes which indicates that the desktop sends morenumber of frames of smaller size The access point can beclearly identified as it has a ratio close to 10 for both bytesand frames The gateway (Dev-5 ) has a ratio less than 10which indicates higher received traffic Finally the AmazonEcho (Dev-6 ) shows a ratio less than 10 as it continuouslydownloads audio traffic from the Internet

In the low load setting the sent-to-receive ratio does notlook promising as a metric to classify the devices The ratiodoes not behave in the same manner for all the IP cameras- Dev-2 has a ratio less than 10 while Dev-3 and Dev-7have a higher amount of sent traffic The Amazon Echo hasa ratio higher than 10 in this setting Our experiments showthat an analysis of the ratio alone in low-load settings maynot be good enough to identify IoT devices

55 Classifying Streaming CameraFinally we present a use case of our IoTScanner system

Figure 8 Variation of the number of frames andits types for each participating device in high-loadsetting

Figure 9 Variation of the number of frames andits types for each participating device in low-loadsetting

that addresses the issue of privacy in an IoT environment Inparticular we show how to differentiate nearby IoT camerasthat are streaming data from other devices To achieve thatwe leverage our experience on traffic patterns as discussedin previous sections It may be tempting to consider abso-lute traffic volume per device for the classification as any IPcamera produces a lot of traffic compared to other devices(Figure 6) Unfortunately there are a number of poten-tial issues with that approach The traffic volume can varysignificantly depending on the observation window size Inaddition as different wireless channels can be used to carrytraffic and our scanner performs channel hopping it may notbe able to capture all traffic for each and every device Thecamera can also produce varying amount of traffic dependingon its vendor (see Figure 8) Finally the identification maybecome dependent on system parameters such as dwell time

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

5

10

15

20

25

sent

rece

ive

A High Load

Bytes Frames

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1

2

3

4

5

6

7

8

sent

rece

ive

B Low Load

Bytes Frames

Figure 10 Variation of the ratio of sent and receivedtraffic per device basis in both high- and low-loadsettings

Table 2 Confusion matrix to identify streamingcamera ldquoothersrdquo = devices other than cameras

n = 95 classified as camera classified as otherscamera 10 2others 3 80

and hops Therefore we consider ratio on different types oftraffic volume as it looks promising (see Figure 10)

We perform this analysis only on data traffic as it domi-nates control or management traffic in high-load settings forall the devices (Figure 6)

We use two parameters here

bull Rsr - the ratio of sent to received data traffic ieRsr = TrsTrr where Trs and Trr are the amount ofdata traffic (in Bytes) sent from and received respec-tively by a device

bull Rbf - the ratio of the traffic volume in bytes and inframes for a device ie Rbf = BytesFrames whereBytes and Frames are the amount of traffic in bytesand the frames respectively as defined earlier

Our experimental setup consists of the three IP cameras asbefore and some additional WiFi enabled devices like smart-phones laptops tablets and a printer We run eight exper-iments in total having a varying number of active deviceswith at least one active camera in each experiment We havea total number of 95 devices spread over all the experiments

The goal is to classify the cameras that are actively stream-ing The status (active or non-active) of a camera is notchanged during a single experiment though it may changeacross different experiments

Results from the previous experiments give us an Rsr

range of 12plusmn8 and an Rbf range of 1000plusmn500 bytesframeThus a device is identified as an actively streaming cam-era in an experiment only if it satisfies the conditions 40 leRsr le 20 and 500 le Rbf le 1500 In each of the experi-ments we calculate the Rsr and Rbf for every device andcheck if they can be identified as a streaming camera oth-erwise it is identified as a non-camera device (denoted asldquoothersrdquo) The results of these experiments are shown in aconfusion matrix in Table 2 We see that out of 95 deviceidentifications there were 3 false positives and 2 false nega-tives This gives a false acceptance rate (FAR) of asymp 361and a false rejection rate (FRR) of asymp 1667

False positive identification of one device occurs due to thepresence of one Withings IP camera in our test settings Thecamera is kept switched on and configured but no remoteaccess of live video is performed during the experimentsHence it is considered as a non-camera device Howeverthe camera starts streaming to its associated cloud serveras soon as it detects some movement in the area of focuscausing it to be detected as an IP camera Similarly a cou-ple of false negative cases are reported due to the Netatmocamera in our settings This is because our scanner fails tosniff sufficient traffic for the device as it performs channelhopping making a false prediction case

As the aim of our study is to defend against an ldquohonestbut curiousrdquo attacker that makes use of existing networkinginfrastructure to obtain insights about not only the IoT in-frastructure itself but also human users associated with iteg by accessing a surveillance camera we use only MAC

layer un-decrypted traffic for this purpose Preliminary re-sults of our analysis on identifying such streaming camerasin an IoT environment are promising and can lead to futurestudies for identifying other devices from MAC layer traf-fic obtained by passive sniffing Thus our IoTScanner canplay an important role for initiating the process of address-ing the problem of identifying potential privacy breaches inany personalized IoT environment

6 BLUETOOTH LE EXPERIMENTSFor the Bluetooth Low Energy (BLE) experiments we

consider six devices - a OnePlus smartphone an Augustsmart lock two Fitbits and two Lenovo tablets The smart-phone operates the smart lock via an Android app Eachtablet is associated with a Fitbit and operates it via an An-droid app In each experiment one of the Fitbit is pairedallowed to sync its data and unpaired from the associatedtablet the smart lock is also paired locked and unlocked(3-4 times) via commands from the app and unpaired fromthe smartphone Similar to the WiFi experiments we con-duct 10 experiments in each case and compute an averageof each of the measures We do not attempt to decrypt theframes in these experiments as well

We initiate experiments to probe our network settings bydetecting BLE nodes and links Then we attempt to clas-sify the devices via traffic categorization It is seen thatout IoTScanner is able to detect all three pairs of devicesand their links Surprisingly we observe that the smart lockadvertising frames do not follow BLE MAC address random-ization (ie a feature expected to be used by BLE devicesfor privacy reason where the device MAC is replaced withsome random MAC in the BLE frames) In the Fitbit casewe do not detect advertising frames (refer to Section 8)hence no information regarding MAC randomization is re-vealed During the data exchange phase the access addressis seen to change every time the smart lock is paired TheFitbit pairs use a single access address across all pairingevents Hence the access address can be used to identifythe Fitbit-tablet communication

In the smart lock case we observe three types of con-trol frames in addition to the advertising and data frames(BTLE DATA) Those are scan request (SCAN REQ) scanresponse (SCAN RESP) and connection request (CONN REQ)frames No such control frames are seen in the Fitbit caseIn both cases we observe that the data frames (observedon non-advertising channels) are further classified into datacontrol and reserved sub-types We denote the control sub-type frames as data-control (see Figure 11)

We observe traffic on all data channels in the case of theFitbit except for a few experiments where only one channelis seen to be carrying traffic However for the smart lockonly about 4 channels on average carry traffic

We present the results on the data and control traffic perBLE pair in Figure 11

Both the Fitbit pairs generate significantly higher datatraffic when compared to the smart lock (the inset figureshows a magnified version that displays data-control frames)This is expected as Fitbits perform a number of actions likemovement detection quality of sleep estimation and loca-tion information collection during every syncing with thephone whereas the smart lock exchanges only lockunlockcommands The variation in data traffic for the Fitbit canbe explained by the differences in user activity for each ex-

Pair-

1

Pair-

2

Pair-

30

20000

40000

60000

80000

100000

120000

count(

x)

data data-control Control

Pair-

1

Pair-

2

Pair-

30

50100150200250300

Figure 11 Variation of data and control frames (in-dicated by x in count(x)) Pair-1 and Pair-2 are Fit-bit devices and Pair-3 is smart lock device (insetplot shows data-control frames)

Table 3 Label-device mapping for Zigbee experi-ments

Label Device Name

Zig-1 Bulb - switched on and off onceZig-2 Hue BridgeZig-3 Bulb - changed colorZig-4 Bulb - switched on and off multiple times

periment (relation between traffic and activity are describedin [12]) Our experiments show that BLE pairs can also beclassified using traffic volume analysis though this is notdone here due to insufficient number of devices at the timeof experiments

7 ZIGBEE EXPERIMENTSFor the Zigbee experiments we employ the Philips Hue

lighting system that consists of one Hue bridge controllingthree light bulbs We intercept the traffic among the fourdevices and find the number of links nodes and amount oftraffic on each link We conduct 10 experiments in totalIn each experiment we execute different commands on thethree bulbsmdashone bulb is switched on and off once duringthe experiment one bulb is switched on and off 6 timesand one bulb is made to change its color 6 times Eachexperiment lasts 120 seconds The devices are labeled asshown in Table 3

In all the experiments our traffic interceptor detects allfour devices (results are not presented here) We concentrateon the identification of devices using traffic analysis

Figure 12 shows the amount of data sent and received bythe four devices (each indicated by Zig-i) We note that theHue bridge (Zig-2) sends and receives a higher amount ofdata (in size and number of frames) when compared to thelight bulbs Among the light bulbs the bulb with the lowestamount of activity (switching on and off once) ie Zig-1has a smaller number of sent and received frames

The results also show that the controller receives about40 more data than it sends whereas the bulbs have about50 less data received compared to sent These initial tests

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

sis

bull We present an implementation of the proposed designand demonstrate its effectiveness through a set of ex-periments

bull We discuss how our system can be potentially used toidentify privacy threats in an IoT environment

The structure of this work is as follows In Section 2 webriefly summarize the relevant background for our work Wepropose our system design for the IoTScanner in Section 3Our implementation is described in Section 4 In Section 5we run some experiments to evaluate our implementationin an environment that consists of WiFi devices In addi-tion we discuss the feasibility of the IoTScanner to performtraffic classification and device identification in this sectionSections 6 and 7 describe experiments in BLE and Zigbeeenvironments We discuss some of the challenges we facedin Section 8 Related work and comparison of features withexisting tools is summarized in Section 9 We conclude thepaper and discuss possible future work in Section 10

2 BACKGROUND

21 Internet of ThingsThe Internet of Things (IoT) refers to a network of phys-

ical devices that have the capability of gathering and trans-ferring data from the environment and interacting with re-mote computers over Internet [4 18] IoT devices can beanything from cellphones to smart lamps as long as theyhave the ability to transfer data over the Internet which es-sentially means they are assigned some public IP addresses

22 Passive MonitoringPassive monitoring is a technique for observing the traffic

in a network only by listening to signals that are alreadyavailable in the network without injecting any extra signalUnlike active monitoring passive monitors do not probe thedevices they are observing [22] In the context of wirelessnetwork the technique is more suitable as it only requiresa traffic interceptor to be physically present in the envi-ronment without requiring any wire tapping or so Devicescalled sniffers or monitors are placed in the network to inter-cept frames transmitted by devices in their vicinity Radiosthat can be used to sniff different standards (WiFi Blue-tooth Zigbee) are available on the market and can be usedfor passive monitoring

23 System ModelIn our systems model we assume that there are one or

more wireless networks in an IoT scenario in which the scan-ner is placed For example in a smart home the electronicgadgets like smart lighting can make use of Zigbee commu-nication personalized health monitoring can use BluetoothInternet access can happen via WiFi communication Thescenario can have one or more IoT devices but not all thedevices need to be active (ie sending or receiving someinformation) all the time For example a smart blood pres-sure monitor may get activated only about 2-3 times a daywhereas smart light need to be active throughout the dayIn the basic operation mode the scanner needs no priorknowledge of the infrastructure and network configurationin the IoT environment ie no information is required about

which device used for what purpose or what kind of encryp-tion is used by them if any We assume that the user of ourIoTScanner system does not have any control over the de-vices or know if they are present or where exactly they arelocated Hence there is a chance that IoT devices that arepresent in the environment (but not actively participatingin the network) are not detected by the scanner

24 Attacker ModelWe assume a limited attacker who is honest but curious

For example the attacker might access a webcam set up in aroom to spy on persons in the room but the attacker will notset up a dedicated device for this (in particular the devicewill not use some non-standard wireless communication)By obtaining the images from the camera over a certaintime period the attacker violates the privacy of the userHow the attacker obtained access to the camera does notmatter for our analysis

As we do not assume that we have control over the net-work(s) in the environment we will not be able to detectthe camera activity on the Network Layer or at a gatewayor similar

3 A PASSIVE ANALYSIS FRAMEWORKIn the following we provide details on our proposed pas-

sive analysis framework We start with a concise problemstatement summarize the intuition behind our design andthen provide additional details on individual components

31 Problem StatementIn this work we address the following problem ldquoIn an IoT

environment which devices are present and communicatingvia wireless communicationsrdquo That information can thenbe used to address questions such as ldquoAre the IoT devices inmy environment used by an attacker to violate my privacyrdquoIdeally such a goal should be reached passively withoutactively interfering with the environment (which could be apublic place such as an airport hotel or similar)

This problem cannot be solved by normal end-users easilyit requires specific software hardware and technical under-standing of wireless protocols We refer to this challenge aswireless opaqueness for the end users they are agnostic tothe way networking works which links exists and how dataflows in the neighborhood

32 IntuitionTo address the problem stated above we now propose the

IoTScanner The aim of the IoTScanner is to provide real-time passive monitoring of an existing wireless infrastruc-ture that potentially constitute an IoT environment Thescanner will identify active devices that are communicat-ing using that infrastructure and attempt to categorize IoTtraffic depending on features such as the volume of trafficobserved

In particular we use to following constraints to achievepassive monitoring The IoTScanner

bull will not associate with any access point present

bull will not perform active probing or fingerprinting and

bull will not decrypt the observed network traffic

Traffic Interceptor Traffic Analyzer Data Storage Visualizer

Figure 1 Overview of the IoTScanner architecturewhich consists of four modules traffic interceptortraffic analyzer data storage and traffic visualiza-tion

The IoTScanner only observes the network traffic at the Linklayer and then analyzes this traffic using frame header in-formation A more offensive active scanner would not needto follow those constraints

The long term goal is to turn the IoTScanner into a con-venient hand-held device In the context of this paper weare using a Raspberry Pi 3 [31] as platform together withdevices such as Android tablets for visualization via a webapplication

33 IoTScanner System ArchitectureThe main features provided by our IoTScanner are ubiqui-

tous (wireless) signal interception packet filtering analysisof the captured packets and storage of the results Finallyresults will be accessible via APIs to be visualized througha web-based visualization system

Figure 1 shows the overall architecture of our proposedPassive Analysis Framework termed as IoTScanner TheIoTScanner has four main functional modules traffic inter-ceptor (captures wireless signals) traffic analyzer (analyzesMAC frames) data storage (stores processed frames and re-sults) traffic visualizer (displays the status of network)

Each of these modules is described in detail in the follow-ing We provide a detailed comparison of the IoTScannerwith other related projects in Section 9

34 Traffic InterceptorThe traffic interceptor module provides flexible low level

access to the wireless medium In the context of IoT widelyused protocols are 80211WiFi Bluetooth Bluetooth LEZigbee and Z-Wave each being prevalent in particular ap-plication area(s) For example the devices accessing In-ternet primarily use WiFi wearableon-body devices (egblood pressure monitor smart watch) use Bluetooth or Blue-tooth LE to connect to their parent devices smart homeappliances (eg smart meter) use Zigbee and electronicappliances (eg AC fridge fan) use Z-Wave protocols [4]However there is no clear line of separation on what devicecan use which protocol it primarily depends on the usageof the devices or the energy consumption behavior of themTherefore it is important to have interception capabilitiesleveraging multiple radios either one radio for each proto-col or software defined radios to cope up with the varietyof protocols available in the IoT spectrum

If multiple channels of the same standard should be reli-ably monitored it might even be necessary to use multipleradios of the same kind each on its own channel

35 Traffic AnalyzerThe traffic analyzer scrutinizes each Link layer frame cap-

tured by the traffic interceptor by parsing only the frameoverhead (ie header and trailer) harnessing on passive anal-ysis philosophy of the IoTScanner It extracts relevant infor-mation such as the source and destination addresses frametype and sub-type SSIDs present from those the framesto be used for targeted analytics We note that the framesneed to be treated on a protocol by protocol basis becauseparsing Bluetooth LE frames is significantly different fromparsing WiFi frames or Zigbee frames In addition the ana-lyzer records some additional useful information such as thechannel number on which the interceptor is capturing traf-fic size of the frame captured (in bytes) and the timestampat which the frame is captured It sends the extracted frameinformation to the data storage module on per frame basiswhere actual analytics is performed

36 Data StorageThe data storage module acting as a simple server pro-

vides a stable storage unit primarily for storing processedinformation about individual frames The storage can bedone by various means however we prefer to employ a sim-ple and light weight database system In addition to storingthe information the system provides a simple interface forquerying the database to carry out analytics For exam-ple the data storage interface can be realized using a set ofRESTful APIs that can easily accessed over Internet and beused by third-party applications The APIs are provided forthe following functions storage and retrieval of frame infor-mation generalized categorical queries on the DB storageand retrieval of analysis results

37 Traffic VisualizerThe traffic visualizer provides a visual representation of

the observed IoT environment at a particular time windowA network ie an IoT environment can be viewed fromdifferent perspectives starting from device-to-device connec-tion to device or link specific information to semantics of theunderline possibly collaborative activity performed by IoTestablishment In this paper we consider a mix of all theseperspective at a high level for an initial comprehension of theIoT environment where we display a graphical view of theunderlying network along with some supporting descriptionof the devices and the associated links if any We do notinfer any application specific information eg if the IoT isused for maintaining room temperature by controlling ACrather our interest in this paper is to create an inventoryof the devices present and the amount of traffic generatedby each of those devices Because the devices need not besending or receiving frames all the time the traffic visual-izer needs to automatically and periodically update to reflectany changes (in terms of both the devices and links) in theIoT environment under surveillance Note that the visual-izer displays only those nodes and accounts for only thoselinks that are present in the database currently

4 SYSTEM IMPLEMENTATIONIn this section we present our implementation of the four

proposed IoTScanner modules (traffic interceptor traffic an-alyzer data storage and traffic visualizer) An overview ofour implementation is shown in Figure 1 We use differentwireless interfaces for the traffic interceptor Scapy (a python

library) for the traffic analyzer SQLite for the data storageand Javascript for the data visualization The data storageuses RESTful APIs to communicate with the analyzer andthe visualizer modules The interceptor and analyzer com-ponents run on a Raspberry Pi 3 device the data storage canbe run on the same device or a server and the visualizationis displayed on an Android Tablet

41 Traffic InterceptorThe traffic interceptor module can be implemented by a

number of radio interfaces or by using software defined ra-dios We decide to use the following radio interfaces that arecommercially available and connectable via USB the TP-Link TL-WN722N 80211n wireless adapter (for WiFi) theUbertooth One (for Bluetooth LE) and Atmel-RZUSBstick(for Zigbee)

The TP-Link TL-WN722N adapter [36] can be easily con-figured to operate in monitor mode and capture WiFi frameswith configurable channel hopping (over 13 channels) Theadapter can also support certain active attacks such as deau-thentication attacks a useful feature in case we extend thefunctionality of the IoTScanner to include traffic decryp-tion We perform sequential channel hopping to obtain anoverview of the traffic on all channels The interface dwellson a particular channel for a certain period of time beforehopping to the next channel The dwell time can be config-ured by the user otherwise takes a default constant value

We note that since we dwell on a single channel at a timeframes on channels the interceptor is not listening on willnot be captured Hence we capture a subset of the overalltraffic

For Bluetooth Low Energy (BLE) traffic capture we usethe Ubertooth One [29] an open source Bluetooth moni-toring platform Compared to other Bluetooth monitoringsolutions this platform is inexpensive and easily adaptableto our settings We focus on Bluetooth Low Energy (BLE)traffic as its presence is increasing in IoT devices especiallythose used in healthcare The Ubertooth One is able todetect the channel hopping map from sniffed BLE connec-tion request packets and follow connections by hopping inthe same pattern The Ubertooth also has a promiscuousmodemdashto follow connections that were already establishedat the time of sniffing As in the case of WiFi the intercep-tor may miss out some devices as result of channel hoppingwhich may be compensated by increasing the observationperiod

For Zigbee traffic capture we use the RZUSBstick fromAtmel [3] which supports low power wireless applicationsusing Zigbee 6LoWPAN and IEEE 802154 networks Thisadapter can also perform channel hopping (over 16 channelsfrom channel 11 to channel 26 in the 24 GHz band) Otherfeatures of this traffic capturing procedure is similar to WiFior Bluetooth networks

42 Traffic AnalyzerThe traffic analyzer module consists of three sub-modules

extractor collector and storage handler as shown in Fig-ure 3 The extractor and the collector modules are imple-mented using Scapy [6] a python library for packet cap-ture and analysis Every frame captured by the traffic in-terceptor is an input to both the extractor and collectorsub-modules Since the aim of the IoTScanner is to pro-vide a quick overview of the IoT environment only rele-

vant pieces of information are extracted from every capturedframe This is performed online (without buffering) so asto find quick answers to only those questions that we haveassumed to be sufficient to provide an overview of the envi-ronment The extractor module extracts the following fromthe respective frames

bull In WiFi frames (type sub-type length MAC addressand SSID)

bull In Bluetooth LE frames (type length MAC addresstype (public or random) MAC address node localname)

bull In Zigbee frames (type length PAN ID addresses )

The collector module collects information such as the sys-tem time during frame capture the channel number on whichthe frame is captured and the RSSI (for potential devicelocalization) Both of these modules supply the capturedinformation to the storage handler module

The storage handler sub-module sends the collected andextracted information to the data storage module It sendsthe frame information (in JSON format) to the data stor-age module via HTTP POST method The module alsohas the option of storing the frames in a PCAP file and pe-riodically sending the files to the data storage for furtheranalysis of the overall traffic (which might be more compu-tationally intensive) It is worth mentioning that high levelframe analysis is not possible at the traffic analyzer sincethis requires aggregated information from multiple framesand hence such analysis is performed at the data storageserver end

43 Data StorageThe data storage module of the IoTScanner provides a

database server to be accessible via a set of APIs to storeand retrieve the extractedcollected frame information Twomodules the traffic analyzer and the traffic visualizer inter-act with the storage module using these APIs over networkpotentially the Internet We have implemented this moduleas a web server which interacts with a light-weight databaseThe APIs in the server are developed using Flask (a Pythonweb framework) which helps to easily build the RESTfulAPIs for our purpose We use SQLite to build a light-weightrelational database system for our data storage module

44 Traffic VisualizerWe implement the traffic visualizer using Javascript with

D3 [7] library for network visualization The visualizer iscompatible with any hand-held devices such as smart phonestablets etc in addition to the desktop browsers The vi-sualizer displays the IoT environment in a number of ways(eg summary text connectivity graph bipartite relationetc) to make it suitable for the user to understand differentaspects of the underlying network By default it displays anetwork graph accompanied by a brief summary text

Figure 4 shows a sample network graph obtained duringone of our experiments The colored circles represent thenodes in the network and the arrows between a pair of nodesindicate that the pair exchanged at least one frame Weidentify the access points from beacon and probe requestframes and internet gateways using simple heuristics Theaccess points and gateways have icons to identify them inthe visualizer

Figure 2 Overview of IoTScanner implementation

Figure 3 Traffic Analyzer module of our IoTScan-ner for WiFi frames

Our visual display is interactive in the sense that on se-lecting a node or an edge more details about the selectedcomponent are displayed For example in the Figure 4 theselected nodes and edge are highlighted in red and their de-tails are displayed in the sidebar The graph is updated at afixed interval of p (configurable) seconds in order to reflectany changes in the number of devices or the communicationlinks in the network

Our overall implementation using the Raspberry Pi as in-terceptor (along with the tablet as visualizer) is shown inFigure 5

5 WIFI EXPERIMENTSIn all our experiments we place the scanner in an IoT

testbed [33] that contains a number of IoT devices Weconduct experiments with devices that use WiFi BluetoothLow Energy and Zigbee communication with a larger focuson WiFi enabled devices since it is the predominant modeof communication for IoT devices We perform our exper-iments in three phases after grouping the devices based onnetworking technology In this section we discuss the exper-iments using WiFi enabled IoT devices Experiments withBLE and Zigbee are described in Sections 6 and 7

51 IoTScanner configurationThe IoTScanner while intercepting WiFi traffic uses two

Figure 4 Example screenshot of our visualizationapp IoT scenario represented using a graph struc-ture Selecting a node (red circle) in the graph dis-plays the details about the underlying device

input parameters

bull Dwell Time (Td) period of time (in seconds) that thetraffic interceptor listens on a channel before movingto next channel (Td isin 5 10 20 30(default) 40 50 60)

bull Hops Th number of channel hops performed by thetraffic interceptor (Th isin 1 6 13(default) 26 65 130)

These parameters account for the amount of time theIoTScanner is exposed to an IoT environment for exam-ple Th = 13 and Td = 5s implies that the traffic interceptorscans for 13 times 5 = 65s and the analysis will be performedonly on the traffic captured during this period

52 Evaluation metricsFollowing are the common metrics for our experiments

bull nodes the total number of active devices in the ob-served environment (including access points) A de-vice is considered to be active if it is observed to havesentreceived at least one frame

bull links the number of unique pairs of nodes that haveexchanged at least one frame (excluding broadcast andmulticast frames)

bull SSIDs the number of access points seen in the envi-ronment

Figure 5 IoTScanner with visualization on a hand-held device

bull Frames the total number of frames (sent or received)per device these are further classified by type intocFrames (control) mFrames (management) and dFrames(data)

bull Bytes the aggregated number of bytes (sent and re-ceived) per device these are further classified by typeinto cBytes (control) mBytes (management) and dBytes(data)

53 Experiment SettingsIn our controlled experiments we use six IoT devices one

Nest Cam security camera one Netatmo camera (with facerecognition feature) one TP Link security camera (of rela-tively lower resolution compared to the other two cameras)one Amazon Echo wireless speaker one desktop with wire-less adapter (to perform general web surfing) and one WiFiaccess point We conduct 10 experiments each in a high-load(being default setting) and a low-load setting

High-load This is the default setting for our experimentsand in this setting all three cameras (focusing on the samearea) are actively streaming video via Internet to a mobiledevice located outside the test environment The AmazonEcho [2] loudspeaker is streaming audio songs continuouslyduring the experiments The desktop with wireless adapteris used to browse web pages intermittently

Low-load In this setting all the devices are present butnone of them are actively used For example the IP camerasare switched on but the live video is not accessed TheAmazon Echo is kept on but is not playing any music

Understanding the Network Structure First we ver-ify if IoTScanner can identify the nodes (with their MACaddresses) and the links among them from the capturedtraffic hence determining the underlying network structureWe observe that our IoTScanner can correctly capture traf-fic from all the six devices in each of our experiments Thescanner identifies the devices that sent out broadcast framesto advertise their presence in the network and the wirelesschannels on which each of these devices sentreceive trafficWe experiment with various values (as noted earlier) of thetwo input parameters dwell time (Td) and hops (Th) We

Label Device Name

Dev-1 DesktopDev-2 Netatmo cameraDev-3 TP-Link cameraDev-4 Access PointDev-5 GatewayDev-6 Amazon EchoDev-7 Nest Cam camera

Table 1 Device labels and the corresponding de-vices used in WiFi experiments

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000000

2000000

3000000

4000000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

5000

6000

7000B Frames

total mframes cframes dframes

Figure 6 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in high-load setting

observe that lower values of these parameters result in thescanner being unable to capture all the devices during theobservation window After multiple rounds of experimentswe conclude that Td = 30 and Th = 13 are optimal values toquickly capture a sufficient amount of traffic for the trafficclassification analytics we want to perform Finally we usebeacon and probe request frames to identify access points inthe network and simple heuristics (on amount of data anddestination MAC addresses) to identify the Internet gate-way

Results of these experiments are not presented here asthey are used more as a check of the correctness of ourIoTScanner system We present more interesting resultsthat are obtained from the traffic analyzer of our systemon device classification in an IoT environment

54 Per-node Traffic ClassificationWe perform simple analytics on the captured traffic to

classify IoT devices The mapping between the device labelswe use and their actual name is shown in Table 1

Frames mFrames cFrames and dFrames First wefind the total amount of traffic associated with each device

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0100000200000300000400000500000600000700000800000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

B Frames

total mframes cframes dframes

Figure 7 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in low-load setting

in the network along with the type (management controland data) in the high-load setting We determine the trafficin terms of bytes (Figure 6A) and frames (Figure 6B) Aframe is associated with a device if its MAC address is foundin the frame either as the source or destination address

Interestingly it can be seen that the traffic amount andits type can classify the devices at a high level For exam-ple the highest amount of traffic in terms of both bytesand frames is associated with Dev-4 which is the accesspoint (see Table 1) that connects to all other devices presentDev-5 which has no control and management frames is thegateway device connected through Ethernet to the accesspoint The lowest amount of traffic is seen in Dev-1 thedesktop and it is used for occasional browsing during theexperiments The rest of the devices (Dev-2 Dev-3 Dev-6and Dev-7) are associated with high traffic as they are ei-ther IP cameras or the Amazon Echo performing continuousstreaming In each of the devices it can be seen that thedata traffic (in bytes) dominates the control or managementtraffic and is almost equal to the total amount of traffic ofthe corresponding devices However the difference betweenthe number of control and data frames is not as high es-pecially in the case of the cameras We observe that theacknowledgement frames contribute to the large number ofcontrol frames in this case

We explore the traffic volume in low-load settings (resultsshown in Figure 7) It can be seen that almost all the deviceshave control traffic comparable to data traffic (in bytes) asopposed to high-load settings where data traffic dominatesthe control traffic In fact standard deviation of traffic vol-ume is quite significant in this setting in all the devicesperhaps because the devices send their status informationmore at times Thus an analysis of the traffic amount andits composition can potentially be used to learn if an IoTsetting generates a high volume of data traffic

Sent and Received Volume Since the overall traffic

mainly consists of data frames we investigate the amountof data traffic (in terms of bytes and number of frames) sentand received by each device (Figure 8 shows results in high-load settings) The highest amount of traffic (either sentor received) is observed in Dev-4 which is the access pointDev-5 (the gateway) has about three times higher receivedtraffic (in Bytes) as compared to sent Note that the traffictowards the Internet is the received traffic for the gatewayand traffic coming into the local network accounts for sentfor it Thus the result is consistent with the ground truthas there are three cameras sending video traffic We also no-tice that the cameras (Dev-2 Dev-3 and Dev-7 ) have a highamount of sent traffic as expected However the amount ofsent traffic varies significantly among the cameras The re-ceived traffic is higher than the sent traffic for Dev-6 whichis the Amazon Echo continuously streaming and playing au-dio songs from its server Our experiments indicate thatactive IoT devices such as IP cameras or music streamingdevices can be identified by analysis of sent and receivedtraffic volumes in high-load settings

We also investigate traffic flow in the low-load settings(results shown in Figure 9) Surprisingly it can be seen thatcameras do not necessarily produce a higher amount of senttraffic compared to receive traffic (eg Dev-2) The AmazonEcho sends and receives almost equal amount of data in thissetting As expected the gateway still receives more datathan it sends probably because these IoT devices continueto update their status to their associated cloud servers

Sent-to-Received Ratio We explore the possibility ofidentifying the devices by computing the ratio of sent toreceived traffic (in terms of both bytes and frames) Weconsider only data traffic for this analysis and ignore man-agement and control frames Figures 10A and 10B show thesent-to-received ratios in high-load and low-load settings re-spectively In the high-load setting the IP cameras (Dev-2Dev-3 and Dev-7 ) have a ratio greater than 4 for traffic inbytes and greater than 15 for traffic in number of framesThis indicates that an IP camera that actively streams videotraffic may potentially be identified when the ratio is greaterthan 10 Also the ratio in bytes is greater than the ratio inframes for the cameras implying that per frame a largeramount of data is originated from the cameras The desk-top with adapter (Dev-1 ) has a lower ratio (gt10) than thecameras but higher than the access point (asymp 10) and gate-way (lt10) The ratio of frames is much higher than theratio in bytes which indicates that the desktop sends morenumber of frames of smaller size The access point can beclearly identified as it has a ratio close to 10 for both bytesand frames The gateway (Dev-5 ) has a ratio less than 10which indicates higher received traffic Finally the AmazonEcho (Dev-6 ) shows a ratio less than 10 as it continuouslydownloads audio traffic from the Internet

In the low load setting the sent-to-receive ratio does notlook promising as a metric to classify the devices The ratiodoes not behave in the same manner for all the IP cameras- Dev-2 has a ratio less than 10 while Dev-3 and Dev-7have a higher amount of sent traffic The Amazon Echo hasa ratio higher than 10 in this setting Our experiments showthat an analysis of the ratio alone in low-load settings maynot be good enough to identify IoT devices

55 Classifying Streaming CameraFinally we present a use case of our IoTScanner system

Figure 8 Variation of the number of frames andits types for each participating device in high-loadsetting

Figure 9 Variation of the number of frames andits types for each participating device in low-loadsetting

that addresses the issue of privacy in an IoT environment Inparticular we show how to differentiate nearby IoT camerasthat are streaming data from other devices To achieve thatwe leverage our experience on traffic patterns as discussedin previous sections It may be tempting to consider abso-lute traffic volume per device for the classification as any IPcamera produces a lot of traffic compared to other devices(Figure 6) Unfortunately there are a number of poten-tial issues with that approach The traffic volume can varysignificantly depending on the observation window size Inaddition as different wireless channels can be used to carrytraffic and our scanner performs channel hopping it may notbe able to capture all traffic for each and every device Thecamera can also produce varying amount of traffic dependingon its vendor (see Figure 8) Finally the identification maybecome dependent on system parameters such as dwell time

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

5

10

15

20

25

sent

rece

ive

A High Load

Bytes Frames

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1

2

3

4

5

6

7

8

sent

rece

ive

B Low Load

Bytes Frames

Figure 10 Variation of the ratio of sent and receivedtraffic per device basis in both high- and low-loadsettings

Table 2 Confusion matrix to identify streamingcamera ldquoothersrdquo = devices other than cameras

n = 95 classified as camera classified as otherscamera 10 2others 3 80

and hops Therefore we consider ratio on different types oftraffic volume as it looks promising (see Figure 10)

We perform this analysis only on data traffic as it domi-nates control or management traffic in high-load settings forall the devices (Figure 6)

We use two parameters here

bull Rsr - the ratio of sent to received data traffic ieRsr = TrsTrr where Trs and Trr are the amount ofdata traffic (in Bytes) sent from and received respec-tively by a device

bull Rbf - the ratio of the traffic volume in bytes and inframes for a device ie Rbf = BytesFrames whereBytes and Frames are the amount of traffic in bytesand the frames respectively as defined earlier

Our experimental setup consists of the three IP cameras asbefore and some additional WiFi enabled devices like smart-phones laptops tablets and a printer We run eight exper-iments in total having a varying number of active deviceswith at least one active camera in each experiment We havea total number of 95 devices spread over all the experiments

The goal is to classify the cameras that are actively stream-ing The status (active or non-active) of a camera is notchanged during a single experiment though it may changeacross different experiments

Results from the previous experiments give us an Rsr

range of 12plusmn8 and an Rbf range of 1000plusmn500 bytesframeThus a device is identified as an actively streaming cam-era in an experiment only if it satisfies the conditions 40 leRsr le 20 and 500 le Rbf le 1500 In each of the experi-ments we calculate the Rsr and Rbf for every device andcheck if they can be identified as a streaming camera oth-erwise it is identified as a non-camera device (denoted asldquoothersrdquo) The results of these experiments are shown in aconfusion matrix in Table 2 We see that out of 95 deviceidentifications there were 3 false positives and 2 false nega-tives This gives a false acceptance rate (FAR) of asymp 361and a false rejection rate (FRR) of asymp 1667

False positive identification of one device occurs due to thepresence of one Withings IP camera in our test settings Thecamera is kept switched on and configured but no remoteaccess of live video is performed during the experimentsHence it is considered as a non-camera device Howeverthe camera starts streaming to its associated cloud serveras soon as it detects some movement in the area of focuscausing it to be detected as an IP camera Similarly a cou-ple of false negative cases are reported due to the Netatmocamera in our settings This is because our scanner fails tosniff sufficient traffic for the device as it performs channelhopping making a false prediction case

As the aim of our study is to defend against an ldquohonestbut curiousrdquo attacker that makes use of existing networkinginfrastructure to obtain insights about not only the IoT in-frastructure itself but also human users associated with iteg by accessing a surveillance camera we use only MAC

layer un-decrypted traffic for this purpose Preliminary re-sults of our analysis on identifying such streaming camerasin an IoT environment are promising and can lead to futurestudies for identifying other devices from MAC layer traf-fic obtained by passive sniffing Thus our IoTScanner canplay an important role for initiating the process of address-ing the problem of identifying potential privacy breaches inany personalized IoT environment

6 BLUETOOTH LE EXPERIMENTSFor the Bluetooth Low Energy (BLE) experiments we

consider six devices - a OnePlus smartphone an Augustsmart lock two Fitbits and two Lenovo tablets The smart-phone operates the smart lock via an Android app Eachtablet is associated with a Fitbit and operates it via an An-droid app In each experiment one of the Fitbit is pairedallowed to sync its data and unpaired from the associatedtablet the smart lock is also paired locked and unlocked(3-4 times) via commands from the app and unpaired fromthe smartphone Similar to the WiFi experiments we con-duct 10 experiments in each case and compute an averageof each of the measures We do not attempt to decrypt theframes in these experiments as well

We initiate experiments to probe our network settings bydetecting BLE nodes and links Then we attempt to clas-sify the devices via traffic categorization It is seen thatout IoTScanner is able to detect all three pairs of devicesand their links Surprisingly we observe that the smart lockadvertising frames do not follow BLE MAC address random-ization (ie a feature expected to be used by BLE devicesfor privacy reason where the device MAC is replaced withsome random MAC in the BLE frames) In the Fitbit casewe do not detect advertising frames (refer to Section 8)hence no information regarding MAC randomization is re-vealed During the data exchange phase the access addressis seen to change every time the smart lock is paired TheFitbit pairs use a single access address across all pairingevents Hence the access address can be used to identifythe Fitbit-tablet communication

In the smart lock case we observe three types of con-trol frames in addition to the advertising and data frames(BTLE DATA) Those are scan request (SCAN REQ) scanresponse (SCAN RESP) and connection request (CONN REQ)frames No such control frames are seen in the Fitbit caseIn both cases we observe that the data frames (observedon non-advertising channels) are further classified into datacontrol and reserved sub-types We denote the control sub-type frames as data-control (see Figure 11)

We observe traffic on all data channels in the case of theFitbit except for a few experiments where only one channelis seen to be carrying traffic However for the smart lockonly about 4 channels on average carry traffic

We present the results on the data and control traffic perBLE pair in Figure 11

Both the Fitbit pairs generate significantly higher datatraffic when compared to the smart lock (the inset figureshows a magnified version that displays data-control frames)This is expected as Fitbits perform a number of actions likemovement detection quality of sleep estimation and loca-tion information collection during every syncing with thephone whereas the smart lock exchanges only lockunlockcommands The variation in data traffic for the Fitbit canbe explained by the differences in user activity for each ex-

Pair-

1

Pair-

2

Pair-

30

20000

40000

60000

80000

100000

120000

count(

x)

data data-control Control

Pair-

1

Pair-

2

Pair-

30

50100150200250300

Figure 11 Variation of data and control frames (in-dicated by x in count(x)) Pair-1 and Pair-2 are Fit-bit devices and Pair-3 is smart lock device (insetplot shows data-control frames)

Table 3 Label-device mapping for Zigbee experi-ments

Label Device Name

Zig-1 Bulb - switched on and off onceZig-2 Hue BridgeZig-3 Bulb - changed colorZig-4 Bulb - switched on and off multiple times

periment (relation between traffic and activity are describedin [12]) Our experiments show that BLE pairs can also beclassified using traffic volume analysis though this is notdone here due to insufficient number of devices at the timeof experiments

7 ZIGBEE EXPERIMENTSFor the Zigbee experiments we employ the Philips Hue

lighting system that consists of one Hue bridge controllingthree light bulbs We intercept the traffic among the fourdevices and find the number of links nodes and amount oftraffic on each link We conduct 10 experiments in totalIn each experiment we execute different commands on thethree bulbsmdashone bulb is switched on and off once duringthe experiment one bulb is switched on and off 6 timesand one bulb is made to change its color 6 times Eachexperiment lasts 120 seconds The devices are labeled asshown in Table 3

In all the experiments our traffic interceptor detects allfour devices (results are not presented here) We concentrateon the identification of devices using traffic analysis

Figure 12 shows the amount of data sent and received bythe four devices (each indicated by Zig-i) We note that theHue bridge (Zig-2) sends and receives a higher amount ofdata (in size and number of frames) when compared to thelight bulbs Among the light bulbs the bulb with the lowestamount of activity (switching on and off once) ie Zig-1has a smaller number of sent and received frames

The results also show that the controller receives about40 more data than it sends whereas the bulbs have about50 less data received compared to sent These initial tests

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

Traffic Interceptor Traffic Analyzer Data Storage Visualizer

Figure 1 Overview of the IoTScanner architecturewhich consists of four modules traffic interceptortraffic analyzer data storage and traffic visualiza-tion

The IoTScanner only observes the network traffic at the Linklayer and then analyzes this traffic using frame header in-formation A more offensive active scanner would not needto follow those constraints

The long term goal is to turn the IoTScanner into a con-venient hand-held device In the context of this paper weare using a Raspberry Pi 3 [31] as platform together withdevices such as Android tablets for visualization via a webapplication

33 IoTScanner System ArchitectureThe main features provided by our IoTScanner are ubiqui-

tous (wireless) signal interception packet filtering analysisof the captured packets and storage of the results Finallyresults will be accessible via APIs to be visualized througha web-based visualization system

Figure 1 shows the overall architecture of our proposedPassive Analysis Framework termed as IoTScanner TheIoTScanner has four main functional modules traffic inter-ceptor (captures wireless signals) traffic analyzer (analyzesMAC frames) data storage (stores processed frames and re-sults) traffic visualizer (displays the status of network)

Each of these modules is described in detail in the follow-ing We provide a detailed comparison of the IoTScannerwith other related projects in Section 9

34 Traffic InterceptorThe traffic interceptor module provides flexible low level

access to the wireless medium In the context of IoT widelyused protocols are 80211WiFi Bluetooth Bluetooth LEZigbee and Z-Wave each being prevalent in particular ap-plication area(s) For example the devices accessing In-ternet primarily use WiFi wearableon-body devices (egblood pressure monitor smart watch) use Bluetooth or Blue-tooth LE to connect to their parent devices smart homeappliances (eg smart meter) use Zigbee and electronicappliances (eg AC fridge fan) use Z-Wave protocols [4]However there is no clear line of separation on what devicecan use which protocol it primarily depends on the usageof the devices or the energy consumption behavior of themTherefore it is important to have interception capabilitiesleveraging multiple radios either one radio for each proto-col or software defined radios to cope up with the varietyof protocols available in the IoT spectrum

If multiple channels of the same standard should be reli-ably monitored it might even be necessary to use multipleradios of the same kind each on its own channel

35 Traffic AnalyzerThe traffic analyzer scrutinizes each Link layer frame cap-

tured by the traffic interceptor by parsing only the frameoverhead (ie header and trailer) harnessing on passive anal-ysis philosophy of the IoTScanner It extracts relevant infor-mation such as the source and destination addresses frametype and sub-type SSIDs present from those the framesto be used for targeted analytics We note that the framesneed to be treated on a protocol by protocol basis becauseparsing Bluetooth LE frames is significantly different fromparsing WiFi frames or Zigbee frames In addition the ana-lyzer records some additional useful information such as thechannel number on which the interceptor is capturing traf-fic size of the frame captured (in bytes) and the timestampat which the frame is captured It sends the extracted frameinformation to the data storage module on per frame basiswhere actual analytics is performed

36 Data StorageThe data storage module acting as a simple server pro-

vides a stable storage unit primarily for storing processedinformation about individual frames The storage can bedone by various means however we prefer to employ a sim-ple and light weight database system In addition to storingthe information the system provides a simple interface forquerying the database to carry out analytics For exam-ple the data storage interface can be realized using a set ofRESTful APIs that can easily accessed over Internet and beused by third-party applications The APIs are provided forthe following functions storage and retrieval of frame infor-mation generalized categorical queries on the DB storageand retrieval of analysis results

37 Traffic VisualizerThe traffic visualizer provides a visual representation of

the observed IoT environment at a particular time windowA network ie an IoT environment can be viewed fromdifferent perspectives starting from device-to-device connec-tion to device or link specific information to semantics of theunderline possibly collaborative activity performed by IoTestablishment In this paper we consider a mix of all theseperspective at a high level for an initial comprehension of theIoT environment where we display a graphical view of theunderlying network along with some supporting descriptionof the devices and the associated links if any We do notinfer any application specific information eg if the IoT isused for maintaining room temperature by controlling ACrather our interest in this paper is to create an inventoryof the devices present and the amount of traffic generatedby each of those devices Because the devices need not besending or receiving frames all the time the traffic visual-izer needs to automatically and periodically update to reflectany changes (in terms of both the devices and links) in theIoT environment under surveillance Note that the visual-izer displays only those nodes and accounts for only thoselinks that are present in the database currently

4 SYSTEM IMPLEMENTATIONIn this section we present our implementation of the four

proposed IoTScanner modules (traffic interceptor traffic an-alyzer data storage and traffic visualizer) An overview ofour implementation is shown in Figure 1 We use differentwireless interfaces for the traffic interceptor Scapy (a python

library) for the traffic analyzer SQLite for the data storageand Javascript for the data visualization The data storageuses RESTful APIs to communicate with the analyzer andthe visualizer modules The interceptor and analyzer com-ponents run on a Raspberry Pi 3 device the data storage canbe run on the same device or a server and the visualizationis displayed on an Android Tablet

41 Traffic InterceptorThe traffic interceptor module can be implemented by a

number of radio interfaces or by using software defined ra-dios We decide to use the following radio interfaces that arecommercially available and connectable via USB the TP-Link TL-WN722N 80211n wireless adapter (for WiFi) theUbertooth One (for Bluetooth LE) and Atmel-RZUSBstick(for Zigbee)

The TP-Link TL-WN722N adapter [36] can be easily con-figured to operate in monitor mode and capture WiFi frameswith configurable channel hopping (over 13 channels) Theadapter can also support certain active attacks such as deau-thentication attacks a useful feature in case we extend thefunctionality of the IoTScanner to include traffic decryp-tion We perform sequential channel hopping to obtain anoverview of the traffic on all channels The interface dwellson a particular channel for a certain period of time beforehopping to the next channel The dwell time can be config-ured by the user otherwise takes a default constant value

We note that since we dwell on a single channel at a timeframes on channels the interceptor is not listening on willnot be captured Hence we capture a subset of the overalltraffic

For Bluetooth Low Energy (BLE) traffic capture we usethe Ubertooth One [29] an open source Bluetooth moni-toring platform Compared to other Bluetooth monitoringsolutions this platform is inexpensive and easily adaptableto our settings We focus on Bluetooth Low Energy (BLE)traffic as its presence is increasing in IoT devices especiallythose used in healthcare The Ubertooth One is able todetect the channel hopping map from sniffed BLE connec-tion request packets and follow connections by hopping inthe same pattern The Ubertooth also has a promiscuousmodemdashto follow connections that were already establishedat the time of sniffing As in the case of WiFi the intercep-tor may miss out some devices as result of channel hoppingwhich may be compensated by increasing the observationperiod

For Zigbee traffic capture we use the RZUSBstick fromAtmel [3] which supports low power wireless applicationsusing Zigbee 6LoWPAN and IEEE 802154 networks Thisadapter can also perform channel hopping (over 16 channelsfrom channel 11 to channel 26 in the 24 GHz band) Otherfeatures of this traffic capturing procedure is similar to WiFior Bluetooth networks

42 Traffic AnalyzerThe traffic analyzer module consists of three sub-modules

extractor collector and storage handler as shown in Fig-ure 3 The extractor and the collector modules are imple-mented using Scapy [6] a python library for packet cap-ture and analysis Every frame captured by the traffic in-terceptor is an input to both the extractor and collectorsub-modules Since the aim of the IoTScanner is to pro-vide a quick overview of the IoT environment only rele-

vant pieces of information are extracted from every capturedframe This is performed online (without buffering) so asto find quick answers to only those questions that we haveassumed to be sufficient to provide an overview of the envi-ronment The extractor module extracts the following fromthe respective frames

bull In WiFi frames (type sub-type length MAC addressand SSID)

bull In Bluetooth LE frames (type length MAC addresstype (public or random) MAC address node localname)

bull In Zigbee frames (type length PAN ID addresses )

The collector module collects information such as the sys-tem time during frame capture the channel number on whichthe frame is captured and the RSSI (for potential devicelocalization) Both of these modules supply the capturedinformation to the storage handler module

The storage handler sub-module sends the collected andextracted information to the data storage module It sendsthe frame information (in JSON format) to the data stor-age module via HTTP POST method The module alsohas the option of storing the frames in a PCAP file and pe-riodically sending the files to the data storage for furtheranalysis of the overall traffic (which might be more compu-tationally intensive) It is worth mentioning that high levelframe analysis is not possible at the traffic analyzer sincethis requires aggregated information from multiple framesand hence such analysis is performed at the data storageserver end

43 Data StorageThe data storage module of the IoTScanner provides a

database server to be accessible via a set of APIs to storeand retrieve the extractedcollected frame information Twomodules the traffic analyzer and the traffic visualizer inter-act with the storage module using these APIs over networkpotentially the Internet We have implemented this moduleas a web server which interacts with a light-weight databaseThe APIs in the server are developed using Flask (a Pythonweb framework) which helps to easily build the RESTfulAPIs for our purpose We use SQLite to build a light-weightrelational database system for our data storage module

44 Traffic VisualizerWe implement the traffic visualizer using Javascript with

D3 [7] library for network visualization The visualizer iscompatible with any hand-held devices such as smart phonestablets etc in addition to the desktop browsers The vi-sualizer displays the IoT environment in a number of ways(eg summary text connectivity graph bipartite relationetc) to make it suitable for the user to understand differentaspects of the underlying network By default it displays anetwork graph accompanied by a brief summary text

Figure 4 shows a sample network graph obtained duringone of our experiments The colored circles represent thenodes in the network and the arrows between a pair of nodesindicate that the pair exchanged at least one frame Weidentify the access points from beacon and probe requestframes and internet gateways using simple heuristics Theaccess points and gateways have icons to identify them inthe visualizer

Figure 2 Overview of IoTScanner implementation

Figure 3 Traffic Analyzer module of our IoTScan-ner for WiFi frames

Our visual display is interactive in the sense that on se-lecting a node or an edge more details about the selectedcomponent are displayed For example in the Figure 4 theselected nodes and edge are highlighted in red and their de-tails are displayed in the sidebar The graph is updated at afixed interval of p (configurable) seconds in order to reflectany changes in the number of devices or the communicationlinks in the network

Our overall implementation using the Raspberry Pi as in-terceptor (along with the tablet as visualizer) is shown inFigure 5

5 WIFI EXPERIMENTSIn all our experiments we place the scanner in an IoT

testbed [33] that contains a number of IoT devices Weconduct experiments with devices that use WiFi BluetoothLow Energy and Zigbee communication with a larger focuson WiFi enabled devices since it is the predominant modeof communication for IoT devices We perform our exper-iments in three phases after grouping the devices based onnetworking technology In this section we discuss the exper-iments using WiFi enabled IoT devices Experiments withBLE and Zigbee are described in Sections 6 and 7

51 IoTScanner configurationThe IoTScanner while intercepting WiFi traffic uses two

Figure 4 Example screenshot of our visualizationapp IoT scenario represented using a graph struc-ture Selecting a node (red circle) in the graph dis-plays the details about the underlying device

input parameters

bull Dwell Time (Td) period of time (in seconds) that thetraffic interceptor listens on a channel before movingto next channel (Td isin 5 10 20 30(default) 40 50 60)

bull Hops Th number of channel hops performed by thetraffic interceptor (Th isin 1 6 13(default) 26 65 130)

These parameters account for the amount of time theIoTScanner is exposed to an IoT environment for exam-ple Th = 13 and Td = 5s implies that the traffic interceptorscans for 13 times 5 = 65s and the analysis will be performedonly on the traffic captured during this period

52 Evaluation metricsFollowing are the common metrics for our experiments

bull nodes the total number of active devices in the ob-served environment (including access points) A de-vice is considered to be active if it is observed to havesentreceived at least one frame

bull links the number of unique pairs of nodes that haveexchanged at least one frame (excluding broadcast andmulticast frames)

bull SSIDs the number of access points seen in the envi-ronment

Figure 5 IoTScanner with visualization on a hand-held device

bull Frames the total number of frames (sent or received)per device these are further classified by type intocFrames (control) mFrames (management) and dFrames(data)

bull Bytes the aggregated number of bytes (sent and re-ceived) per device these are further classified by typeinto cBytes (control) mBytes (management) and dBytes(data)

53 Experiment SettingsIn our controlled experiments we use six IoT devices one

Nest Cam security camera one Netatmo camera (with facerecognition feature) one TP Link security camera (of rela-tively lower resolution compared to the other two cameras)one Amazon Echo wireless speaker one desktop with wire-less adapter (to perform general web surfing) and one WiFiaccess point We conduct 10 experiments each in a high-load(being default setting) and a low-load setting

High-load This is the default setting for our experimentsand in this setting all three cameras (focusing on the samearea) are actively streaming video via Internet to a mobiledevice located outside the test environment The AmazonEcho [2] loudspeaker is streaming audio songs continuouslyduring the experiments The desktop with wireless adapteris used to browse web pages intermittently

Low-load In this setting all the devices are present butnone of them are actively used For example the IP camerasare switched on but the live video is not accessed TheAmazon Echo is kept on but is not playing any music

Understanding the Network Structure First we ver-ify if IoTScanner can identify the nodes (with their MACaddresses) and the links among them from the capturedtraffic hence determining the underlying network structureWe observe that our IoTScanner can correctly capture traf-fic from all the six devices in each of our experiments Thescanner identifies the devices that sent out broadcast framesto advertise their presence in the network and the wirelesschannels on which each of these devices sentreceive trafficWe experiment with various values (as noted earlier) of thetwo input parameters dwell time (Td) and hops (Th) We

Label Device Name

Dev-1 DesktopDev-2 Netatmo cameraDev-3 TP-Link cameraDev-4 Access PointDev-5 GatewayDev-6 Amazon EchoDev-7 Nest Cam camera

Table 1 Device labels and the corresponding de-vices used in WiFi experiments

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000000

2000000

3000000

4000000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

5000

6000

7000B Frames

total mframes cframes dframes

Figure 6 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in high-load setting

observe that lower values of these parameters result in thescanner being unable to capture all the devices during theobservation window After multiple rounds of experimentswe conclude that Td = 30 and Th = 13 are optimal values toquickly capture a sufficient amount of traffic for the trafficclassification analytics we want to perform Finally we usebeacon and probe request frames to identify access points inthe network and simple heuristics (on amount of data anddestination MAC addresses) to identify the Internet gate-way

Results of these experiments are not presented here asthey are used more as a check of the correctness of ourIoTScanner system We present more interesting resultsthat are obtained from the traffic analyzer of our systemon device classification in an IoT environment

54 Per-node Traffic ClassificationWe perform simple analytics on the captured traffic to

classify IoT devices The mapping between the device labelswe use and their actual name is shown in Table 1

Frames mFrames cFrames and dFrames First wefind the total amount of traffic associated with each device

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0100000200000300000400000500000600000700000800000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

B Frames

total mframes cframes dframes

Figure 7 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in low-load setting

in the network along with the type (management controland data) in the high-load setting We determine the trafficin terms of bytes (Figure 6A) and frames (Figure 6B) Aframe is associated with a device if its MAC address is foundin the frame either as the source or destination address

Interestingly it can be seen that the traffic amount andits type can classify the devices at a high level For exam-ple the highest amount of traffic in terms of both bytesand frames is associated with Dev-4 which is the accesspoint (see Table 1) that connects to all other devices presentDev-5 which has no control and management frames is thegateway device connected through Ethernet to the accesspoint The lowest amount of traffic is seen in Dev-1 thedesktop and it is used for occasional browsing during theexperiments The rest of the devices (Dev-2 Dev-3 Dev-6and Dev-7) are associated with high traffic as they are ei-ther IP cameras or the Amazon Echo performing continuousstreaming In each of the devices it can be seen that thedata traffic (in bytes) dominates the control or managementtraffic and is almost equal to the total amount of traffic ofthe corresponding devices However the difference betweenthe number of control and data frames is not as high es-pecially in the case of the cameras We observe that theacknowledgement frames contribute to the large number ofcontrol frames in this case

We explore the traffic volume in low-load settings (resultsshown in Figure 7) It can be seen that almost all the deviceshave control traffic comparable to data traffic (in bytes) asopposed to high-load settings where data traffic dominatesthe control traffic In fact standard deviation of traffic vol-ume is quite significant in this setting in all the devicesperhaps because the devices send their status informationmore at times Thus an analysis of the traffic amount andits composition can potentially be used to learn if an IoTsetting generates a high volume of data traffic

Sent and Received Volume Since the overall traffic

mainly consists of data frames we investigate the amountof data traffic (in terms of bytes and number of frames) sentand received by each device (Figure 8 shows results in high-load settings) The highest amount of traffic (either sentor received) is observed in Dev-4 which is the access pointDev-5 (the gateway) has about three times higher receivedtraffic (in Bytes) as compared to sent Note that the traffictowards the Internet is the received traffic for the gatewayand traffic coming into the local network accounts for sentfor it Thus the result is consistent with the ground truthas there are three cameras sending video traffic We also no-tice that the cameras (Dev-2 Dev-3 and Dev-7 ) have a highamount of sent traffic as expected However the amount ofsent traffic varies significantly among the cameras The re-ceived traffic is higher than the sent traffic for Dev-6 whichis the Amazon Echo continuously streaming and playing au-dio songs from its server Our experiments indicate thatactive IoT devices such as IP cameras or music streamingdevices can be identified by analysis of sent and receivedtraffic volumes in high-load settings

We also investigate traffic flow in the low-load settings(results shown in Figure 9) Surprisingly it can be seen thatcameras do not necessarily produce a higher amount of senttraffic compared to receive traffic (eg Dev-2) The AmazonEcho sends and receives almost equal amount of data in thissetting As expected the gateway still receives more datathan it sends probably because these IoT devices continueto update their status to their associated cloud servers

Sent-to-Received Ratio We explore the possibility ofidentifying the devices by computing the ratio of sent toreceived traffic (in terms of both bytes and frames) Weconsider only data traffic for this analysis and ignore man-agement and control frames Figures 10A and 10B show thesent-to-received ratios in high-load and low-load settings re-spectively In the high-load setting the IP cameras (Dev-2Dev-3 and Dev-7 ) have a ratio greater than 4 for traffic inbytes and greater than 15 for traffic in number of framesThis indicates that an IP camera that actively streams videotraffic may potentially be identified when the ratio is greaterthan 10 Also the ratio in bytes is greater than the ratio inframes for the cameras implying that per frame a largeramount of data is originated from the cameras The desk-top with adapter (Dev-1 ) has a lower ratio (gt10) than thecameras but higher than the access point (asymp 10) and gate-way (lt10) The ratio of frames is much higher than theratio in bytes which indicates that the desktop sends morenumber of frames of smaller size The access point can beclearly identified as it has a ratio close to 10 for both bytesand frames The gateway (Dev-5 ) has a ratio less than 10which indicates higher received traffic Finally the AmazonEcho (Dev-6 ) shows a ratio less than 10 as it continuouslydownloads audio traffic from the Internet

In the low load setting the sent-to-receive ratio does notlook promising as a metric to classify the devices The ratiodoes not behave in the same manner for all the IP cameras- Dev-2 has a ratio less than 10 while Dev-3 and Dev-7have a higher amount of sent traffic The Amazon Echo hasa ratio higher than 10 in this setting Our experiments showthat an analysis of the ratio alone in low-load settings maynot be good enough to identify IoT devices

55 Classifying Streaming CameraFinally we present a use case of our IoTScanner system

Figure 8 Variation of the number of frames andits types for each participating device in high-loadsetting

Figure 9 Variation of the number of frames andits types for each participating device in low-loadsetting

that addresses the issue of privacy in an IoT environment Inparticular we show how to differentiate nearby IoT camerasthat are streaming data from other devices To achieve thatwe leverage our experience on traffic patterns as discussedin previous sections It may be tempting to consider abso-lute traffic volume per device for the classification as any IPcamera produces a lot of traffic compared to other devices(Figure 6) Unfortunately there are a number of poten-tial issues with that approach The traffic volume can varysignificantly depending on the observation window size Inaddition as different wireless channels can be used to carrytraffic and our scanner performs channel hopping it may notbe able to capture all traffic for each and every device Thecamera can also produce varying amount of traffic dependingon its vendor (see Figure 8) Finally the identification maybecome dependent on system parameters such as dwell time

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

5

10

15

20

25

sent

rece

ive

A High Load

Bytes Frames

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1

2

3

4

5

6

7

8

sent

rece

ive

B Low Load

Bytes Frames

Figure 10 Variation of the ratio of sent and receivedtraffic per device basis in both high- and low-loadsettings

Table 2 Confusion matrix to identify streamingcamera ldquoothersrdquo = devices other than cameras

n = 95 classified as camera classified as otherscamera 10 2others 3 80

and hops Therefore we consider ratio on different types oftraffic volume as it looks promising (see Figure 10)

We perform this analysis only on data traffic as it domi-nates control or management traffic in high-load settings forall the devices (Figure 6)

We use two parameters here

bull Rsr - the ratio of sent to received data traffic ieRsr = TrsTrr where Trs and Trr are the amount ofdata traffic (in Bytes) sent from and received respec-tively by a device

bull Rbf - the ratio of the traffic volume in bytes and inframes for a device ie Rbf = BytesFrames whereBytes and Frames are the amount of traffic in bytesand the frames respectively as defined earlier

Our experimental setup consists of the three IP cameras asbefore and some additional WiFi enabled devices like smart-phones laptops tablets and a printer We run eight exper-iments in total having a varying number of active deviceswith at least one active camera in each experiment We havea total number of 95 devices spread over all the experiments

The goal is to classify the cameras that are actively stream-ing The status (active or non-active) of a camera is notchanged during a single experiment though it may changeacross different experiments

Results from the previous experiments give us an Rsr

range of 12plusmn8 and an Rbf range of 1000plusmn500 bytesframeThus a device is identified as an actively streaming cam-era in an experiment only if it satisfies the conditions 40 leRsr le 20 and 500 le Rbf le 1500 In each of the experi-ments we calculate the Rsr and Rbf for every device andcheck if they can be identified as a streaming camera oth-erwise it is identified as a non-camera device (denoted asldquoothersrdquo) The results of these experiments are shown in aconfusion matrix in Table 2 We see that out of 95 deviceidentifications there were 3 false positives and 2 false nega-tives This gives a false acceptance rate (FAR) of asymp 361and a false rejection rate (FRR) of asymp 1667

False positive identification of one device occurs due to thepresence of one Withings IP camera in our test settings Thecamera is kept switched on and configured but no remoteaccess of live video is performed during the experimentsHence it is considered as a non-camera device Howeverthe camera starts streaming to its associated cloud serveras soon as it detects some movement in the area of focuscausing it to be detected as an IP camera Similarly a cou-ple of false negative cases are reported due to the Netatmocamera in our settings This is because our scanner fails tosniff sufficient traffic for the device as it performs channelhopping making a false prediction case

As the aim of our study is to defend against an ldquohonestbut curiousrdquo attacker that makes use of existing networkinginfrastructure to obtain insights about not only the IoT in-frastructure itself but also human users associated with iteg by accessing a surveillance camera we use only MAC

layer un-decrypted traffic for this purpose Preliminary re-sults of our analysis on identifying such streaming camerasin an IoT environment are promising and can lead to futurestudies for identifying other devices from MAC layer traf-fic obtained by passive sniffing Thus our IoTScanner canplay an important role for initiating the process of address-ing the problem of identifying potential privacy breaches inany personalized IoT environment

6 BLUETOOTH LE EXPERIMENTSFor the Bluetooth Low Energy (BLE) experiments we

consider six devices - a OnePlus smartphone an Augustsmart lock two Fitbits and two Lenovo tablets The smart-phone operates the smart lock via an Android app Eachtablet is associated with a Fitbit and operates it via an An-droid app In each experiment one of the Fitbit is pairedallowed to sync its data and unpaired from the associatedtablet the smart lock is also paired locked and unlocked(3-4 times) via commands from the app and unpaired fromthe smartphone Similar to the WiFi experiments we con-duct 10 experiments in each case and compute an averageof each of the measures We do not attempt to decrypt theframes in these experiments as well

We initiate experiments to probe our network settings bydetecting BLE nodes and links Then we attempt to clas-sify the devices via traffic categorization It is seen thatout IoTScanner is able to detect all three pairs of devicesand their links Surprisingly we observe that the smart lockadvertising frames do not follow BLE MAC address random-ization (ie a feature expected to be used by BLE devicesfor privacy reason where the device MAC is replaced withsome random MAC in the BLE frames) In the Fitbit casewe do not detect advertising frames (refer to Section 8)hence no information regarding MAC randomization is re-vealed During the data exchange phase the access addressis seen to change every time the smart lock is paired TheFitbit pairs use a single access address across all pairingevents Hence the access address can be used to identifythe Fitbit-tablet communication

In the smart lock case we observe three types of con-trol frames in addition to the advertising and data frames(BTLE DATA) Those are scan request (SCAN REQ) scanresponse (SCAN RESP) and connection request (CONN REQ)frames No such control frames are seen in the Fitbit caseIn both cases we observe that the data frames (observedon non-advertising channels) are further classified into datacontrol and reserved sub-types We denote the control sub-type frames as data-control (see Figure 11)

We observe traffic on all data channels in the case of theFitbit except for a few experiments where only one channelis seen to be carrying traffic However for the smart lockonly about 4 channels on average carry traffic

We present the results on the data and control traffic perBLE pair in Figure 11

Both the Fitbit pairs generate significantly higher datatraffic when compared to the smart lock (the inset figureshows a magnified version that displays data-control frames)This is expected as Fitbits perform a number of actions likemovement detection quality of sleep estimation and loca-tion information collection during every syncing with thephone whereas the smart lock exchanges only lockunlockcommands The variation in data traffic for the Fitbit canbe explained by the differences in user activity for each ex-

Pair-

1

Pair-

2

Pair-

30

20000

40000

60000

80000

100000

120000

count(

x)

data data-control Control

Pair-

1

Pair-

2

Pair-

30

50100150200250300

Figure 11 Variation of data and control frames (in-dicated by x in count(x)) Pair-1 and Pair-2 are Fit-bit devices and Pair-3 is smart lock device (insetplot shows data-control frames)

Table 3 Label-device mapping for Zigbee experi-ments

Label Device Name

Zig-1 Bulb - switched on and off onceZig-2 Hue BridgeZig-3 Bulb - changed colorZig-4 Bulb - switched on and off multiple times

periment (relation between traffic and activity are describedin [12]) Our experiments show that BLE pairs can also beclassified using traffic volume analysis though this is notdone here due to insufficient number of devices at the timeof experiments

7 ZIGBEE EXPERIMENTSFor the Zigbee experiments we employ the Philips Hue

lighting system that consists of one Hue bridge controllingthree light bulbs We intercept the traffic among the fourdevices and find the number of links nodes and amount oftraffic on each link We conduct 10 experiments in totalIn each experiment we execute different commands on thethree bulbsmdashone bulb is switched on and off once duringthe experiment one bulb is switched on and off 6 timesand one bulb is made to change its color 6 times Eachexperiment lasts 120 seconds The devices are labeled asshown in Table 3

In all the experiments our traffic interceptor detects allfour devices (results are not presented here) We concentrateon the identification of devices using traffic analysis

Figure 12 shows the amount of data sent and received bythe four devices (each indicated by Zig-i) We note that theHue bridge (Zig-2) sends and receives a higher amount ofdata (in size and number of frames) when compared to thelight bulbs Among the light bulbs the bulb with the lowestamount of activity (switching on and off once) ie Zig-1has a smaller number of sent and received frames

The results also show that the controller receives about40 more data than it sends whereas the bulbs have about50 less data received compared to sent These initial tests

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

library) for the traffic analyzer SQLite for the data storageand Javascript for the data visualization The data storageuses RESTful APIs to communicate with the analyzer andthe visualizer modules The interceptor and analyzer com-ponents run on a Raspberry Pi 3 device the data storage canbe run on the same device or a server and the visualizationis displayed on an Android Tablet

41 Traffic InterceptorThe traffic interceptor module can be implemented by a

number of radio interfaces or by using software defined ra-dios We decide to use the following radio interfaces that arecommercially available and connectable via USB the TP-Link TL-WN722N 80211n wireless adapter (for WiFi) theUbertooth One (for Bluetooth LE) and Atmel-RZUSBstick(for Zigbee)

The TP-Link TL-WN722N adapter [36] can be easily con-figured to operate in monitor mode and capture WiFi frameswith configurable channel hopping (over 13 channels) Theadapter can also support certain active attacks such as deau-thentication attacks a useful feature in case we extend thefunctionality of the IoTScanner to include traffic decryp-tion We perform sequential channel hopping to obtain anoverview of the traffic on all channels The interface dwellson a particular channel for a certain period of time beforehopping to the next channel The dwell time can be config-ured by the user otherwise takes a default constant value

We note that since we dwell on a single channel at a timeframes on channels the interceptor is not listening on willnot be captured Hence we capture a subset of the overalltraffic

For Bluetooth Low Energy (BLE) traffic capture we usethe Ubertooth One [29] an open source Bluetooth moni-toring platform Compared to other Bluetooth monitoringsolutions this platform is inexpensive and easily adaptableto our settings We focus on Bluetooth Low Energy (BLE)traffic as its presence is increasing in IoT devices especiallythose used in healthcare The Ubertooth One is able todetect the channel hopping map from sniffed BLE connec-tion request packets and follow connections by hopping inthe same pattern The Ubertooth also has a promiscuousmodemdashto follow connections that were already establishedat the time of sniffing As in the case of WiFi the intercep-tor may miss out some devices as result of channel hoppingwhich may be compensated by increasing the observationperiod

For Zigbee traffic capture we use the RZUSBstick fromAtmel [3] which supports low power wireless applicationsusing Zigbee 6LoWPAN and IEEE 802154 networks Thisadapter can also perform channel hopping (over 16 channelsfrom channel 11 to channel 26 in the 24 GHz band) Otherfeatures of this traffic capturing procedure is similar to WiFior Bluetooth networks

42 Traffic AnalyzerThe traffic analyzer module consists of three sub-modules

extractor collector and storage handler as shown in Fig-ure 3 The extractor and the collector modules are imple-mented using Scapy [6] a python library for packet cap-ture and analysis Every frame captured by the traffic in-terceptor is an input to both the extractor and collectorsub-modules Since the aim of the IoTScanner is to pro-vide a quick overview of the IoT environment only rele-

vant pieces of information are extracted from every capturedframe This is performed online (without buffering) so asto find quick answers to only those questions that we haveassumed to be sufficient to provide an overview of the envi-ronment The extractor module extracts the following fromthe respective frames

bull In WiFi frames (type sub-type length MAC addressand SSID)

bull In Bluetooth LE frames (type length MAC addresstype (public or random) MAC address node localname)

bull In Zigbee frames (type length PAN ID addresses )

The collector module collects information such as the sys-tem time during frame capture the channel number on whichthe frame is captured and the RSSI (for potential devicelocalization) Both of these modules supply the capturedinformation to the storage handler module

The storage handler sub-module sends the collected andextracted information to the data storage module It sendsthe frame information (in JSON format) to the data stor-age module via HTTP POST method The module alsohas the option of storing the frames in a PCAP file and pe-riodically sending the files to the data storage for furtheranalysis of the overall traffic (which might be more compu-tationally intensive) It is worth mentioning that high levelframe analysis is not possible at the traffic analyzer sincethis requires aggregated information from multiple framesand hence such analysis is performed at the data storageserver end

43 Data StorageThe data storage module of the IoTScanner provides a

database server to be accessible via a set of APIs to storeand retrieve the extractedcollected frame information Twomodules the traffic analyzer and the traffic visualizer inter-act with the storage module using these APIs over networkpotentially the Internet We have implemented this moduleas a web server which interacts with a light-weight databaseThe APIs in the server are developed using Flask (a Pythonweb framework) which helps to easily build the RESTfulAPIs for our purpose We use SQLite to build a light-weightrelational database system for our data storage module

44 Traffic VisualizerWe implement the traffic visualizer using Javascript with

D3 [7] library for network visualization The visualizer iscompatible with any hand-held devices such as smart phonestablets etc in addition to the desktop browsers The vi-sualizer displays the IoT environment in a number of ways(eg summary text connectivity graph bipartite relationetc) to make it suitable for the user to understand differentaspects of the underlying network By default it displays anetwork graph accompanied by a brief summary text

Figure 4 shows a sample network graph obtained duringone of our experiments The colored circles represent thenodes in the network and the arrows between a pair of nodesindicate that the pair exchanged at least one frame Weidentify the access points from beacon and probe requestframes and internet gateways using simple heuristics Theaccess points and gateways have icons to identify them inthe visualizer

Figure 2 Overview of IoTScanner implementation

Figure 3 Traffic Analyzer module of our IoTScan-ner for WiFi frames

Our visual display is interactive in the sense that on se-lecting a node or an edge more details about the selectedcomponent are displayed For example in the Figure 4 theselected nodes and edge are highlighted in red and their de-tails are displayed in the sidebar The graph is updated at afixed interval of p (configurable) seconds in order to reflectany changes in the number of devices or the communicationlinks in the network

Our overall implementation using the Raspberry Pi as in-terceptor (along with the tablet as visualizer) is shown inFigure 5

5 WIFI EXPERIMENTSIn all our experiments we place the scanner in an IoT

testbed [33] that contains a number of IoT devices Weconduct experiments with devices that use WiFi BluetoothLow Energy and Zigbee communication with a larger focuson WiFi enabled devices since it is the predominant modeof communication for IoT devices We perform our exper-iments in three phases after grouping the devices based onnetworking technology In this section we discuss the exper-iments using WiFi enabled IoT devices Experiments withBLE and Zigbee are described in Sections 6 and 7

51 IoTScanner configurationThe IoTScanner while intercepting WiFi traffic uses two

Figure 4 Example screenshot of our visualizationapp IoT scenario represented using a graph struc-ture Selecting a node (red circle) in the graph dis-plays the details about the underlying device

input parameters

bull Dwell Time (Td) period of time (in seconds) that thetraffic interceptor listens on a channel before movingto next channel (Td isin 5 10 20 30(default) 40 50 60)

bull Hops Th number of channel hops performed by thetraffic interceptor (Th isin 1 6 13(default) 26 65 130)

These parameters account for the amount of time theIoTScanner is exposed to an IoT environment for exam-ple Th = 13 and Td = 5s implies that the traffic interceptorscans for 13 times 5 = 65s and the analysis will be performedonly on the traffic captured during this period

52 Evaluation metricsFollowing are the common metrics for our experiments

bull nodes the total number of active devices in the ob-served environment (including access points) A de-vice is considered to be active if it is observed to havesentreceived at least one frame

bull links the number of unique pairs of nodes that haveexchanged at least one frame (excluding broadcast andmulticast frames)

bull SSIDs the number of access points seen in the envi-ronment

Figure 5 IoTScanner with visualization on a hand-held device

bull Frames the total number of frames (sent or received)per device these are further classified by type intocFrames (control) mFrames (management) and dFrames(data)

bull Bytes the aggregated number of bytes (sent and re-ceived) per device these are further classified by typeinto cBytes (control) mBytes (management) and dBytes(data)

53 Experiment SettingsIn our controlled experiments we use six IoT devices one

Nest Cam security camera one Netatmo camera (with facerecognition feature) one TP Link security camera (of rela-tively lower resolution compared to the other two cameras)one Amazon Echo wireless speaker one desktop with wire-less adapter (to perform general web surfing) and one WiFiaccess point We conduct 10 experiments each in a high-load(being default setting) and a low-load setting

High-load This is the default setting for our experimentsand in this setting all three cameras (focusing on the samearea) are actively streaming video via Internet to a mobiledevice located outside the test environment The AmazonEcho [2] loudspeaker is streaming audio songs continuouslyduring the experiments The desktop with wireless adapteris used to browse web pages intermittently

Low-load In this setting all the devices are present butnone of them are actively used For example the IP camerasare switched on but the live video is not accessed TheAmazon Echo is kept on but is not playing any music

Understanding the Network Structure First we ver-ify if IoTScanner can identify the nodes (with their MACaddresses) and the links among them from the capturedtraffic hence determining the underlying network structureWe observe that our IoTScanner can correctly capture traf-fic from all the six devices in each of our experiments Thescanner identifies the devices that sent out broadcast framesto advertise their presence in the network and the wirelesschannels on which each of these devices sentreceive trafficWe experiment with various values (as noted earlier) of thetwo input parameters dwell time (Td) and hops (Th) We

Label Device Name

Dev-1 DesktopDev-2 Netatmo cameraDev-3 TP-Link cameraDev-4 Access PointDev-5 GatewayDev-6 Amazon EchoDev-7 Nest Cam camera

Table 1 Device labels and the corresponding de-vices used in WiFi experiments

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000000

2000000

3000000

4000000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

5000

6000

7000B Frames

total mframes cframes dframes

Figure 6 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in high-load setting

observe that lower values of these parameters result in thescanner being unable to capture all the devices during theobservation window After multiple rounds of experimentswe conclude that Td = 30 and Th = 13 are optimal values toquickly capture a sufficient amount of traffic for the trafficclassification analytics we want to perform Finally we usebeacon and probe request frames to identify access points inthe network and simple heuristics (on amount of data anddestination MAC addresses) to identify the Internet gate-way

Results of these experiments are not presented here asthey are used more as a check of the correctness of ourIoTScanner system We present more interesting resultsthat are obtained from the traffic analyzer of our systemon device classification in an IoT environment

54 Per-node Traffic ClassificationWe perform simple analytics on the captured traffic to

classify IoT devices The mapping between the device labelswe use and their actual name is shown in Table 1

Frames mFrames cFrames and dFrames First wefind the total amount of traffic associated with each device

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0100000200000300000400000500000600000700000800000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

B Frames

total mframes cframes dframes

Figure 7 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in low-load setting

in the network along with the type (management controland data) in the high-load setting We determine the trafficin terms of bytes (Figure 6A) and frames (Figure 6B) Aframe is associated with a device if its MAC address is foundin the frame either as the source or destination address

Interestingly it can be seen that the traffic amount andits type can classify the devices at a high level For exam-ple the highest amount of traffic in terms of both bytesand frames is associated with Dev-4 which is the accesspoint (see Table 1) that connects to all other devices presentDev-5 which has no control and management frames is thegateway device connected through Ethernet to the accesspoint The lowest amount of traffic is seen in Dev-1 thedesktop and it is used for occasional browsing during theexperiments The rest of the devices (Dev-2 Dev-3 Dev-6and Dev-7) are associated with high traffic as they are ei-ther IP cameras or the Amazon Echo performing continuousstreaming In each of the devices it can be seen that thedata traffic (in bytes) dominates the control or managementtraffic and is almost equal to the total amount of traffic ofthe corresponding devices However the difference betweenthe number of control and data frames is not as high es-pecially in the case of the cameras We observe that theacknowledgement frames contribute to the large number ofcontrol frames in this case

We explore the traffic volume in low-load settings (resultsshown in Figure 7) It can be seen that almost all the deviceshave control traffic comparable to data traffic (in bytes) asopposed to high-load settings where data traffic dominatesthe control traffic In fact standard deviation of traffic vol-ume is quite significant in this setting in all the devicesperhaps because the devices send their status informationmore at times Thus an analysis of the traffic amount andits composition can potentially be used to learn if an IoTsetting generates a high volume of data traffic

Sent and Received Volume Since the overall traffic

mainly consists of data frames we investigate the amountof data traffic (in terms of bytes and number of frames) sentand received by each device (Figure 8 shows results in high-load settings) The highest amount of traffic (either sentor received) is observed in Dev-4 which is the access pointDev-5 (the gateway) has about three times higher receivedtraffic (in Bytes) as compared to sent Note that the traffictowards the Internet is the received traffic for the gatewayand traffic coming into the local network accounts for sentfor it Thus the result is consistent with the ground truthas there are three cameras sending video traffic We also no-tice that the cameras (Dev-2 Dev-3 and Dev-7 ) have a highamount of sent traffic as expected However the amount ofsent traffic varies significantly among the cameras The re-ceived traffic is higher than the sent traffic for Dev-6 whichis the Amazon Echo continuously streaming and playing au-dio songs from its server Our experiments indicate thatactive IoT devices such as IP cameras or music streamingdevices can be identified by analysis of sent and receivedtraffic volumes in high-load settings

We also investigate traffic flow in the low-load settings(results shown in Figure 9) Surprisingly it can be seen thatcameras do not necessarily produce a higher amount of senttraffic compared to receive traffic (eg Dev-2) The AmazonEcho sends and receives almost equal amount of data in thissetting As expected the gateway still receives more datathan it sends probably because these IoT devices continueto update their status to their associated cloud servers

Sent-to-Received Ratio We explore the possibility ofidentifying the devices by computing the ratio of sent toreceived traffic (in terms of both bytes and frames) Weconsider only data traffic for this analysis and ignore man-agement and control frames Figures 10A and 10B show thesent-to-received ratios in high-load and low-load settings re-spectively In the high-load setting the IP cameras (Dev-2Dev-3 and Dev-7 ) have a ratio greater than 4 for traffic inbytes and greater than 15 for traffic in number of framesThis indicates that an IP camera that actively streams videotraffic may potentially be identified when the ratio is greaterthan 10 Also the ratio in bytes is greater than the ratio inframes for the cameras implying that per frame a largeramount of data is originated from the cameras The desk-top with adapter (Dev-1 ) has a lower ratio (gt10) than thecameras but higher than the access point (asymp 10) and gate-way (lt10) The ratio of frames is much higher than theratio in bytes which indicates that the desktop sends morenumber of frames of smaller size The access point can beclearly identified as it has a ratio close to 10 for both bytesand frames The gateway (Dev-5 ) has a ratio less than 10which indicates higher received traffic Finally the AmazonEcho (Dev-6 ) shows a ratio less than 10 as it continuouslydownloads audio traffic from the Internet

In the low load setting the sent-to-receive ratio does notlook promising as a metric to classify the devices The ratiodoes not behave in the same manner for all the IP cameras- Dev-2 has a ratio less than 10 while Dev-3 and Dev-7have a higher amount of sent traffic The Amazon Echo hasa ratio higher than 10 in this setting Our experiments showthat an analysis of the ratio alone in low-load settings maynot be good enough to identify IoT devices

55 Classifying Streaming CameraFinally we present a use case of our IoTScanner system

Figure 8 Variation of the number of frames andits types for each participating device in high-loadsetting

Figure 9 Variation of the number of frames andits types for each participating device in low-loadsetting

that addresses the issue of privacy in an IoT environment Inparticular we show how to differentiate nearby IoT camerasthat are streaming data from other devices To achieve thatwe leverage our experience on traffic patterns as discussedin previous sections It may be tempting to consider abso-lute traffic volume per device for the classification as any IPcamera produces a lot of traffic compared to other devices(Figure 6) Unfortunately there are a number of poten-tial issues with that approach The traffic volume can varysignificantly depending on the observation window size Inaddition as different wireless channels can be used to carrytraffic and our scanner performs channel hopping it may notbe able to capture all traffic for each and every device Thecamera can also produce varying amount of traffic dependingon its vendor (see Figure 8) Finally the identification maybecome dependent on system parameters such as dwell time

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

5

10

15

20

25

sent

rece

ive

A High Load

Bytes Frames

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1

2

3

4

5

6

7

8

sent

rece

ive

B Low Load

Bytes Frames

Figure 10 Variation of the ratio of sent and receivedtraffic per device basis in both high- and low-loadsettings

Table 2 Confusion matrix to identify streamingcamera ldquoothersrdquo = devices other than cameras

n = 95 classified as camera classified as otherscamera 10 2others 3 80

and hops Therefore we consider ratio on different types oftraffic volume as it looks promising (see Figure 10)

We perform this analysis only on data traffic as it domi-nates control or management traffic in high-load settings forall the devices (Figure 6)

We use two parameters here

bull Rsr - the ratio of sent to received data traffic ieRsr = TrsTrr where Trs and Trr are the amount ofdata traffic (in Bytes) sent from and received respec-tively by a device

bull Rbf - the ratio of the traffic volume in bytes and inframes for a device ie Rbf = BytesFrames whereBytes and Frames are the amount of traffic in bytesand the frames respectively as defined earlier

Our experimental setup consists of the three IP cameras asbefore and some additional WiFi enabled devices like smart-phones laptops tablets and a printer We run eight exper-iments in total having a varying number of active deviceswith at least one active camera in each experiment We havea total number of 95 devices spread over all the experiments

The goal is to classify the cameras that are actively stream-ing The status (active or non-active) of a camera is notchanged during a single experiment though it may changeacross different experiments

Results from the previous experiments give us an Rsr

range of 12plusmn8 and an Rbf range of 1000plusmn500 bytesframeThus a device is identified as an actively streaming cam-era in an experiment only if it satisfies the conditions 40 leRsr le 20 and 500 le Rbf le 1500 In each of the experi-ments we calculate the Rsr and Rbf for every device andcheck if they can be identified as a streaming camera oth-erwise it is identified as a non-camera device (denoted asldquoothersrdquo) The results of these experiments are shown in aconfusion matrix in Table 2 We see that out of 95 deviceidentifications there were 3 false positives and 2 false nega-tives This gives a false acceptance rate (FAR) of asymp 361and a false rejection rate (FRR) of asymp 1667

False positive identification of one device occurs due to thepresence of one Withings IP camera in our test settings Thecamera is kept switched on and configured but no remoteaccess of live video is performed during the experimentsHence it is considered as a non-camera device Howeverthe camera starts streaming to its associated cloud serveras soon as it detects some movement in the area of focuscausing it to be detected as an IP camera Similarly a cou-ple of false negative cases are reported due to the Netatmocamera in our settings This is because our scanner fails tosniff sufficient traffic for the device as it performs channelhopping making a false prediction case

As the aim of our study is to defend against an ldquohonestbut curiousrdquo attacker that makes use of existing networkinginfrastructure to obtain insights about not only the IoT in-frastructure itself but also human users associated with iteg by accessing a surveillance camera we use only MAC

layer un-decrypted traffic for this purpose Preliminary re-sults of our analysis on identifying such streaming camerasin an IoT environment are promising and can lead to futurestudies for identifying other devices from MAC layer traf-fic obtained by passive sniffing Thus our IoTScanner canplay an important role for initiating the process of address-ing the problem of identifying potential privacy breaches inany personalized IoT environment

6 BLUETOOTH LE EXPERIMENTSFor the Bluetooth Low Energy (BLE) experiments we

consider six devices - a OnePlus smartphone an Augustsmart lock two Fitbits and two Lenovo tablets The smart-phone operates the smart lock via an Android app Eachtablet is associated with a Fitbit and operates it via an An-droid app In each experiment one of the Fitbit is pairedallowed to sync its data and unpaired from the associatedtablet the smart lock is also paired locked and unlocked(3-4 times) via commands from the app and unpaired fromthe smartphone Similar to the WiFi experiments we con-duct 10 experiments in each case and compute an averageof each of the measures We do not attempt to decrypt theframes in these experiments as well

We initiate experiments to probe our network settings bydetecting BLE nodes and links Then we attempt to clas-sify the devices via traffic categorization It is seen thatout IoTScanner is able to detect all three pairs of devicesand their links Surprisingly we observe that the smart lockadvertising frames do not follow BLE MAC address random-ization (ie a feature expected to be used by BLE devicesfor privacy reason where the device MAC is replaced withsome random MAC in the BLE frames) In the Fitbit casewe do not detect advertising frames (refer to Section 8)hence no information regarding MAC randomization is re-vealed During the data exchange phase the access addressis seen to change every time the smart lock is paired TheFitbit pairs use a single access address across all pairingevents Hence the access address can be used to identifythe Fitbit-tablet communication

In the smart lock case we observe three types of con-trol frames in addition to the advertising and data frames(BTLE DATA) Those are scan request (SCAN REQ) scanresponse (SCAN RESP) and connection request (CONN REQ)frames No such control frames are seen in the Fitbit caseIn both cases we observe that the data frames (observedon non-advertising channels) are further classified into datacontrol and reserved sub-types We denote the control sub-type frames as data-control (see Figure 11)

We observe traffic on all data channels in the case of theFitbit except for a few experiments where only one channelis seen to be carrying traffic However for the smart lockonly about 4 channels on average carry traffic

We present the results on the data and control traffic perBLE pair in Figure 11

Both the Fitbit pairs generate significantly higher datatraffic when compared to the smart lock (the inset figureshows a magnified version that displays data-control frames)This is expected as Fitbits perform a number of actions likemovement detection quality of sleep estimation and loca-tion information collection during every syncing with thephone whereas the smart lock exchanges only lockunlockcommands The variation in data traffic for the Fitbit canbe explained by the differences in user activity for each ex-

Pair-

1

Pair-

2

Pair-

30

20000

40000

60000

80000

100000

120000

count(

x)

data data-control Control

Pair-

1

Pair-

2

Pair-

30

50100150200250300

Figure 11 Variation of data and control frames (in-dicated by x in count(x)) Pair-1 and Pair-2 are Fit-bit devices and Pair-3 is smart lock device (insetplot shows data-control frames)

Table 3 Label-device mapping for Zigbee experi-ments

Label Device Name

Zig-1 Bulb - switched on and off onceZig-2 Hue BridgeZig-3 Bulb - changed colorZig-4 Bulb - switched on and off multiple times

periment (relation between traffic and activity are describedin [12]) Our experiments show that BLE pairs can also beclassified using traffic volume analysis though this is notdone here due to insufficient number of devices at the timeof experiments

7 ZIGBEE EXPERIMENTSFor the Zigbee experiments we employ the Philips Hue

lighting system that consists of one Hue bridge controllingthree light bulbs We intercept the traffic among the fourdevices and find the number of links nodes and amount oftraffic on each link We conduct 10 experiments in totalIn each experiment we execute different commands on thethree bulbsmdashone bulb is switched on and off once duringthe experiment one bulb is switched on and off 6 timesand one bulb is made to change its color 6 times Eachexperiment lasts 120 seconds The devices are labeled asshown in Table 3

In all the experiments our traffic interceptor detects allfour devices (results are not presented here) We concentrateon the identification of devices using traffic analysis

Figure 12 shows the amount of data sent and received bythe four devices (each indicated by Zig-i) We note that theHue bridge (Zig-2) sends and receives a higher amount ofdata (in size and number of frames) when compared to thelight bulbs Among the light bulbs the bulb with the lowestamount of activity (switching on and off once) ie Zig-1has a smaller number of sent and received frames

The results also show that the controller receives about40 more data than it sends whereas the bulbs have about50 less data received compared to sent These initial tests

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

Figure 2 Overview of IoTScanner implementation

Figure 3 Traffic Analyzer module of our IoTScan-ner for WiFi frames

Our visual display is interactive in the sense that on se-lecting a node or an edge more details about the selectedcomponent are displayed For example in the Figure 4 theselected nodes and edge are highlighted in red and their de-tails are displayed in the sidebar The graph is updated at afixed interval of p (configurable) seconds in order to reflectany changes in the number of devices or the communicationlinks in the network

Our overall implementation using the Raspberry Pi as in-terceptor (along with the tablet as visualizer) is shown inFigure 5

5 WIFI EXPERIMENTSIn all our experiments we place the scanner in an IoT

testbed [33] that contains a number of IoT devices Weconduct experiments with devices that use WiFi BluetoothLow Energy and Zigbee communication with a larger focuson WiFi enabled devices since it is the predominant modeof communication for IoT devices We perform our exper-iments in three phases after grouping the devices based onnetworking technology In this section we discuss the exper-iments using WiFi enabled IoT devices Experiments withBLE and Zigbee are described in Sections 6 and 7

51 IoTScanner configurationThe IoTScanner while intercepting WiFi traffic uses two

Figure 4 Example screenshot of our visualizationapp IoT scenario represented using a graph struc-ture Selecting a node (red circle) in the graph dis-plays the details about the underlying device

input parameters

bull Dwell Time (Td) period of time (in seconds) that thetraffic interceptor listens on a channel before movingto next channel (Td isin 5 10 20 30(default) 40 50 60)

bull Hops Th number of channel hops performed by thetraffic interceptor (Th isin 1 6 13(default) 26 65 130)

These parameters account for the amount of time theIoTScanner is exposed to an IoT environment for exam-ple Th = 13 and Td = 5s implies that the traffic interceptorscans for 13 times 5 = 65s and the analysis will be performedonly on the traffic captured during this period

52 Evaluation metricsFollowing are the common metrics for our experiments

bull nodes the total number of active devices in the ob-served environment (including access points) A de-vice is considered to be active if it is observed to havesentreceived at least one frame

bull links the number of unique pairs of nodes that haveexchanged at least one frame (excluding broadcast andmulticast frames)

bull SSIDs the number of access points seen in the envi-ronment

Figure 5 IoTScanner with visualization on a hand-held device

bull Frames the total number of frames (sent or received)per device these are further classified by type intocFrames (control) mFrames (management) and dFrames(data)

bull Bytes the aggregated number of bytes (sent and re-ceived) per device these are further classified by typeinto cBytes (control) mBytes (management) and dBytes(data)

53 Experiment SettingsIn our controlled experiments we use six IoT devices one

Nest Cam security camera one Netatmo camera (with facerecognition feature) one TP Link security camera (of rela-tively lower resolution compared to the other two cameras)one Amazon Echo wireless speaker one desktop with wire-less adapter (to perform general web surfing) and one WiFiaccess point We conduct 10 experiments each in a high-load(being default setting) and a low-load setting

High-load This is the default setting for our experimentsand in this setting all three cameras (focusing on the samearea) are actively streaming video via Internet to a mobiledevice located outside the test environment The AmazonEcho [2] loudspeaker is streaming audio songs continuouslyduring the experiments The desktop with wireless adapteris used to browse web pages intermittently

Low-load In this setting all the devices are present butnone of them are actively used For example the IP camerasare switched on but the live video is not accessed TheAmazon Echo is kept on but is not playing any music

Understanding the Network Structure First we ver-ify if IoTScanner can identify the nodes (with their MACaddresses) and the links among them from the capturedtraffic hence determining the underlying network structureWe observe that our IoTScanner can correctly capture traf-fic from all the six devices in each of our experiments Thescanner identifies the devices that sent out broadcast framesto advertise their presence in the network and the wirelesschannels on which each of these devices sentreceive trafficWe experiment with various values (as noted earlier) of thetwo input parameters dwell time (Td) and hops (Th) We

Label Device Name

Dev-1 DesktopDev-2 Netatmo cameraDev-3 TP-Link cameraDev-4 Access PointDev-5 GatewayDev-6 Amazon EchoDev-7 Nest Cam camera

Table 1 Device labels and the corresponding de-vices used in WiFi experiments

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000000

2000000

3000000

4000000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

5000

6000

7000B Frames

total mframes cframes dframes

Figure 6 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in high-load setting

observe that lower values of these parameters result in thescanner being unable to capture all the devices during theobservation window After multiple rounds of experimentswe conclude that Td = 30 and Th = 13 are optimal values toquickly capture a sufficient amount of traffic for the trafficclassification analytics we want to perform Finally we usebeacon and probe request frames to identify access points inthe network and simple heuristics (on amount of data anddestination MAC addresses) to identify the Internet gate-way

Results of these experiments are not presented here asthey are used more as a check of the correctness of ourIoTScanner system We present more interesting resultsthat are obtained from the traffic analyzer of our systemon device classification in an IoT environment

54 Per-node Traffic ClassificationWe perform simple analytics on the captured traffic to

classify IoT devices The mapping between the device labelswe use and their actual name is shown in Table 1

Frames mFrames cFrames and dFrames First wefind the total amount of traffic associated with each device

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0100000200000300000400000500000600000700000800000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

B Frames

total mframes cframes dframes

Figure 7 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in low-load setting

in the network along with the type (management controland data) in the high-load setting We determine the trafficin terms of bytes (Figure 6A) and frames (Figure 6B) Aframe is associated with a device if its MAC address is foundin the frame either as the source or destination address

Interestingly it can be seen that the traffic amount andits type can classify the devices at a high level For exam-ple the highest amount of traffic in terms of both bytesand frames is associated with Dev-4 which is the accesspoint (see Table 1) that connects to all other devices presentDev-5 which has no control and management frames is thegateway device connected through Ethernet to the accesspoint The lowest amount of traffic is seen in Dev-1 thedesktop and it is used for occasional browsing during theexperiments The rest of the devices (Dev-2 Dev-3 Dev-6and Dev-7) are associated with high traffic as they are ei-ther IP cameras or the Amazon Echo performing continuousstreaming In each of the devices it can be seen that thedata traffic (in bytes) dominates the control or managementtraffic and is almost equal to the total amount of traffic ofthe corresponding devices However the difference betweenthe number of control and data frames is not as high es-pecially in the case of the cameras We observe that theacknowledgement frames contribute to the large number ofcontrol frames in this case

We explore the traffic volume in low-load settings (resultsshown in Figure 7) It can be seen that almost all the deviceshave control traffic comparable to data traffic (in bytes) asopposed to high-load settings where data traffic dominatesthe control traffic In fact standard deviation of traffic vol-ume is quite significant in this setting in all the devicesperhaps because the devices send their status informationmore at times Thus an analysis of the traffic amount andits composition can potentially be used to learn if an IoTsetting generates a high volume of data traffic

Sent and Received Volume Since the overall traffic

mainly consists of data frames we investigate the amountof data traffic (in terms of bytes and number of frames) sentand received by each device (Figure 8 shows results in high-load settings) The highest amount of traffic (either sentor received) is observed in Dev-4 which is the access pointDev-5 (the gateway) has about three times higher receivedtraffic (in Bytes) as compared to sent Note that the traffictowards the Internet is the received traffic for the gatewayand traffic coming into the local network accounts for sentfor it Thus the result is consistent with the ground truthas there are three cameras sending video traffic We also no-tice that the cameras (Dev-2 Dev-3 and Dev-7 ) have a highamount of sent traffic as expected However the amount ofsent traffic varies significantly among the cameras The re-ceived traffic is higher than the sent traffic for Dev-6 whichis the Amazon Echo continuously streaming and playing au-dio songs from its server Our experiments indicate thatactive IoT devices such as IP cameras or music streamingdevices can be identified by analysis of sent and receivedtraffic volumes in high-load settings

We also investigate traffic flow in the low-load settings(results shown in Figure 9) Surprisingly it can be seen thatcameras do not necessarily produce a higher amount of senttraffic compared to receive traffic (eg Dev-2) The AmazonEcho sends and receives almost equal amount of data in thissetting As expected the gateway still receives more datathan it sends probably because these IoT devices continueto update their status to their associated cloud servers

Sent-to-Received Ratio We explore the possibility ofidentifying the devices by computing the ratio of sent toreceived traffic (in terms of both bytes and frames) Weconsider only data traffic for this analysis and ignore man-agement and control frames Figures 10A and 10B show thesent-to-received ratios in high-load and low-load settings re-spectively In the high-load setting the IP cameras (Dev-2Dev-3 and Dev-7 ) have a ratio greater than 4 for traffic inbytes and greater than 15 for traffic in number of framesThis indicates that an IP camera that actively streams videotraffic may potentially be identified when the ratio is greaterthan 10 Also the ratio in bytes is greater than the ratio inframes for the cameras implying that per frame a largeramount of data is originated from the cameras The desk-top with adapter (Dev-1 ) has a lower ratio (gt10) than thecameras but higher than the access point (asymp 10) and gate-way (lt10) The ratio of frames is much higher than theratio in bytes which indicates that the desktop sends morenumber of frames of smaller size The access point can beclearly identified as it has a ratio close to 10 for both bytesand frames The gateway (Dev-5 ) has a ratio less than 10which indicates higher received traffic Finally the AmazonEcho (Dev-6 ) shows a ratio less than 10 as it continuouslydownloads audio traffic from the Internet

In the low load setting the sent-to-receive ratio does notlook promising as a metric to classify the devices The ratiodoes not behave in the same manner for all the IP cameras- Dev-2 has a ratio less than 10 while Dev-3 and Dev-7have a higher amount of sent traffic The Amazon Echo hasa ratio higher than 10 in this setting Our experiments showthat an analysis of the ratio alone in low-load settings maynot be good enough to identify IoT devices

55 Classifying Streaming CameraFinally we present a use case of our IoTScanner system

Figure 8 Variation of the number of frames andits types for each participating device in high-loadsetting

Figure 9 Variation of the number of frames andits types for each participating device in low-loadsetting

that addresses the issue of privacy in an IoT environment Inparticular we show how to differentiate nearby IoT camerasthat are streaming data from other devices To achieve thatwe leverage our experience on traffic patterns as discussedin previous sections It may be tempting to consider abso-lute traffic volume per device for the classification as any IPcamera produces a lot of traffic compared to other devices(Figure 6) Unfortunately there are a number of poten-tial issues with that approach The traffic volume can varysignificantly depending on the observation window size Inaddition as different wireless channels can be used to carrytraffic and our scanner performs channel hopping it may notbe able to capture all traffic for each and every device Thecamera can also produce varying amount of traffic dependingon its vendor (see Figure 8) Finally the identification maybecome dependent on system parameters such as dwell time

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

5

10

15

20

25

sent

rece

ive

A High Load

Bytes Frames

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1

2

3

4

5

6

7

8

sent

rece

ive

B Low Load

Bytes Frames

Figure 10 Variation of the ratio of sent and receivedtraffic per device basis in both high- and low-loadsettings

Table 2 Confusion matrix to identify streamingcamera ldquoothersrdquo = devices other than cameras

n = 95 classified as camera classified as otherscamera 10 2others 3 80

and hops Therefore we consider ratio on different types oftraffic volume as it looks promising (see Figure 10)

We perform this analysis only on data traffic as it domi-nates control or management traffic in high-load settings forall the devices (Figure 6)

We use two parameters here

bull Rsr - the ratio of sent to received data traffic ieRsr = TrsTrr where Trs and Trr are the amount ofdata traffic (in Bytes) sent from and received respec-tively by a device

bull Rbf - the ratio of the traffic volume in bytes and inframes for a device ie Rbf = BytesFrames whereBytes and Frames are the amount of traffic in bytesand the frames respectively as defined earlier

Our experimental setup consists of the three IP cameras asbefore and some additional WiFi enabled devices like smart-phones laptops tablets and a printer We run eight exper-iments in total having a varying number of active deviceswith at least one active camera in each experiment We havea total number of 95 devices spread over all the experiments

The goal is to classify the cameras that are actively stream-ing The status (active or non-active) of a camera is notchanged during a single experiment though it may changeacross different experiments

Results from the previous experiments give us an Rsr

range of 12plusmn8 and an Rbf range of 1000plusmn500 bytesframeThus a device is identified as an actively streaming cam-era in an experiment only if it satisfies the conditions 40 leRsr le 20 and 500 le Rbf le 1500 In each of the experi-ments we calculate the Rsr and Rbf for every device andcheck if they can be identified as a streaming camera oth-erwise it is identified as a non-camera device (denoted asldquoothersrdquo) The results of these experiments are shown in aconfusion matrix in Table 2 We see that out of 95 deviceidentifications there were 3 false positives and 2 false nega-tives This gives a false acceptance rate (FAR) of asymp 361and a false rejection rate (FRR) of asymp 1667

False positive identification of one device occurs due to thepresence of one Withings IP camera in our test settings Thecamera is kept switched on and configured but no remoteaccess of live video is performed during the experimentsHence it is considered as a non-camera device Howeverthe camera starts streaming to its associated cloud serveras soon as it detects some movement in the area of focuscausing it to be detected as an IP camera Similarly a cou-ple of false negative cases are reported due to the Netatmocamera in our settings This is because our scanner fails tosniff sufficient traffic for the device as it performs channelhopping making a false prediction case

As the aim of our study is to defend against an ldquohonestbut curiousrdquo attacker that makes use of existing networkinginfrastructure to obtain insights about not only the IoT in-frastructure itself but also human users associated with iteg by accessing a surveillance camera we use only MAC

layer un-decrypted traffic for this purpose Preliminary re-sults of our analysis on identifying such streaming camerasin an IoT environment are promising and can lead to futurestudies for identifying other devices from MAC layer traf-fic obtained by passive sniffing Thus our IoTScanner canplay an important role for initiating the process of address-ing the problem of identifying potential privacy breaches inany personalized IoT environment

6 BLUETOOTH LE EXPERIMENTSFor the Bluetooth Low Energy (BLE) experiments we

consider six devices - a OnePlus smartphone an Augustsmart lock two Fitbits and two Lenovo tablets The smart-phone operates the smart lock via an Android app Eachtablet is associated with a Fitbit and operates it via an An-droid app In each experiment one of the Fitbit is pairedallowed to sync its data and unpaired from the associatedtablet the smart lock is also paired locked and unlocked(3-4 times) via commands from the app and unpaired fromthe smartphone Similar to the WiFi experiments we con-duct 10 experiments in each case and compute an averageof each of the measures We do not attempt to decrypt theframes in these experiments as well

We initiate experiments to probe our network settings bydetecting BLE nodes and links Then we attempt to clas-sify the devices via traffic categorization It is seen thatout IoTScanner is able to detect all three pairs of devicesand their links Surprisingly we observe that the smart lockadvertising frames do not follow BLE MAC address random-ization (ie a feature expected to be used by BLE devicesfor privacy reason where the device MAC is replaced withsome random MAC in the BLE frames) In the Fitbit casewe do not detect advertising frames (refer to Section 8)hence no information regarding MAC randomization is re-vealed During the data exchange phase the access addressis seen to change every time the smart lock is paired TheFitbit pairs use a single access address across all pairingevents Hence the access address can be used to identifythe Fitbit-tablet communication

In the smart lock case we observe three types of con-trol frames in addition to the advertising and data frames(BTLE DATA) Those are scan request (SCAN REQ) scanresponse (SCAN RESP) and connection request (CONN REQ)frames No such control frames are seen in the Fitbit caseIn both cases we observe that the data frames (observedon non-advertising channels) are further classified into datacontrol and reserved sub-types We denote the control sub-type frames as data-control (see Figure 11)

We observe traffic on all data channels in the case of theFitbit except for a few experiments where only one channelis seen to be carrying traffic However for the smart lockonly about 4 channels on average carry traffic

We present the results on the data and control traffic perBLE pair in Figure 11

Both the Fitbit pairs generate significantly higher datatraffic when compared to the smart lock (the inset figureshows a magnified version that displays data-control frames)This is expected as Fitbits perform a number of actions likemovement detection quality of sleep estimation and loca-tion information collection during every syncing with thephone whereas the smart lock exchanges only lockunlockcommands The variation in data traffic for the Fitbit canbe explained by the differences in user activity for each ex-

Pair-

1

Pair-

2

Pair-

30

20000

40000

60000

80000

100000

120000

count(

x)

data data-control Control

Pair-

1

Pair-

2

Pair-

30

50100150200250300

Figure 11 Variation of data and control frames (in-dicated by x in count(x)) Pair-1 and Pair-2 are Fit-bit devices and Pair-3 is smart lock device (insetplot shows data-control frames)

Table 3 Label-device mapping for Zigbee experi-ments

Label Device Name

Zig-1 Bulb - switched on and off onceZig-2 Hue BridgeZig-3 Bulb - changed colorZig-4 Bulb - switched on and off multiple times

periment (relation between traffic and activity are describedin [12]) Our experiments show that BLE pairs can also beclassified using traffic volume analysis though this is notdone here due to insufficient number of devices at the timeof experiments

7 ZIGBEE EXPERIMENTSFor the Zigbee experiments we employ the Philips Hue

lighting system that consists of one Hue bridge controllingthree light bulbs We intercept the traffic among the fourdevices and find the number of links nodes and amount oftraffic on each link We conduct 10 experiments in totalIn each experiment we execute different commands on thethree bulbsmdashone bulb is switched on and off once duringthe experiment one bulb is switched on and off 6 timesand one bulb is made to change its color 6 times Eachexperiment lasts 120 seconds The devices are labeled asshown in Table 3

In all the experiments our traffic interceptor detects allfour devices (results are not presented here) We concentrateon the identification of devices using traffic analysis

Figure 12 shows the amount of data sent and received bythe four devices (each indicated by Zig-i) We note that theHue bridge (Zig-2) sends and receives a higher amount ofdata (in size and number of frames) when compared to thelight bulbs Among the light bulbs the bulb with the lowestamount of activity (switching on and off once) ie Zig-1has a smaller number of sent and received frames

The results also show that the controller receives about40 more data than it sends whereas the bulbs have about50 less data received compared to sent These initial tests

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

Figure 5 IoTScanner with visualization on a hand-held device

bull Frames the total number of frames (sent or received)per device these are further classified by type intocFrames (control) mFrames (management) and dFrames(data)

bull Bytes the aggregated number of bytes (sent and re-ceived) per device these are further classified by typeinto cBytes (control) mBytes (management) and dBytes(data)

53 Experiment SettingsIn our controlled experiments we use six IoT devices one

Nest Cam security camera one Netatmo camera (with facerecognition feature) one TP Link security camera (of rela-tively lower resolution compared to the other two cameras)one Amazon Echo wireless speaker one desktop with wire-less adapter (to perform general web surfing) and one WiFiaccess point We conduct 10 experiments each in a high-load(being default setting) and a low-load setting

High-load This is the default setting for our experimentsand in this setting all three cameras (focusing on the samearea) are actively streaming video via Internet to a mobiledevice located outside the test environment The AmazonEcho [2] loudspeaker is streaming audio songs continuouslyduring the experiments The desktop with wireless adapteris used to browse web pages intermittently

Low-load In this setting all the devices are present butnone of them are actively used For example the IP camerasare switched on but the live video is not accessed TheAmazon Echo is kept on but is not playing any music

Understanding the Network Structure First we ver-ify if IoTScanner can identify the nodes (with their MACaddresses) and the links among them from the capturedtraffic hence determining the underlying network structureWe observe that our IoTScanner can correctly capture traf-fic from all the six devices in each of our experiments Thescanner identifies the devices that sent out broadcast framesto advertise their presence in the network and the wirelesschannels on which each of these devices sentreceive trafficWe experiment with various values (as noted earlier) of thetwo input parameters dwell time (Td) and hops (Th) We

Label Device Name

Dev-1 DesktopDev-2 Netatmo cameraDev-3 TP-Link cameraDev-4 Access PointDev-5 GatewayDev-6 Amazon EchoDev-7 Nest Cam camera

Table 1 Device labels and the corresponding de-vices used in WiFi experiments

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000000

2000000

3000000

4000000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

5000

6000

7000B Frames

total mframes cframes dframes

Figure 6 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in high-load setting

observe that lower values of these parameters result in thescanner being unable to capture all the devices during theobservation window After multiple rounds of experimentswe conclude that Td = 30 and Th = 13 are optimal values toquickly capture a sufficient amount of traffic for the trafficclassification analytics we want to perform Finally we usebeacon and probe request frames to identify access points inthe network and simple heuristics (on amount of data anddestination MAC addresses) to identify the Internet gate-way

Results of these experiments are not presented here asthey are used more as a check of the correctness of ourIoTScanner system We present more interesting resultsthat are obtained from the traffic analyzer of our systemon device classification in an IoT environment

54 Per-node Traffic ClassificationWe perform simple analytics on the captured traffic to

classify IoT devices The mapping between the device labelswe use and their actual name is shown in Table 1

Frames mFrames cFrames and dFrames First wefind the total amount of traffic associated with each device

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0100000200000300000400000500000600000700000800000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

B Frames

total mframes cframes dframes

Figure 7 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in low-load setting

in the network along with the type (management controland data) in the high-load setting We determine the trafficin terms of bytes (Figure 6A) and frames (Figure 6B) Aframe is associated with a device if its MAC address is foundin the frame either as the source or destination address

Interestingly it can be seen that the traffic amount andits type can classify the devices at a high level For exam-ple the highest amount of traffic in terms of both bytesand frames is associated with Dev-4 which is the accesspoint (see Table 1) that connects to all other devices presentDev-5 which has no control and management frames is thegateway device connected through Ethernet to the accesspoint The lowest amount of traffic is seen in Dev-1 thedesktop and it is used for occasional browsing during theexperiments The rest of the devices (Dev-2 Dev-3 Dev-6and Dev-7) are associated with high traffic as they are ei-ther IP cameras or the Amazon Echo performing continuousstreaming In each of the devices it can be seen that thedata traffic (in bytes) dominates the control or managementtraffic and is almost equal to the total amount of traffic ofthe corresponding devices However the difference betweenthe number of control and data frames is not as high es-pecially in the case of the cameras We observe that theacknowledgement frames contribute to the large number ofcontrol frames in this case

We explore the traffic volume in low-load settings (resultsshown in Figure 7) It can be seen that almost all the deviceshave control traffic comparable to data traffic (in bytes) asopposed to high-load settings where data traffic dominatesthe control traffic In fact standard deviation of traffic vol-ume is quite significant in this setting in all the devicesperhaps because the devices send their status informationmore at times Thus an analysis of the traffic amount andits composition can potentially be used to learn if an IoTsetting generates a high volume of data traffic

Sent and Received Volume Since the overall traffic

mainly consists of data frames we investigate the amountof data traffic (in terms of bytes and number of frames) sentand received by each device (Figure 8 shows results in high-load settings) The highest amount of traffic (either sentor received) is observed in Dev-4 which is the access pointDev-5 (the gateway) has about three times higher receivedtraffic (in Bytes) as compared to sent Note that the traffictowards the Internet is the received traffic for the gatewayand traffic coming into the local network accounts for sentfor it Thus the result is consistent with the ground truthas there are three cameras sending video traffic We also no-tice that the cameras (Dev-2 Dev-3 and Dev-7 ) have a highamount of sent traffic as expected However the amount ofsent traffic varies significantly among the cameras The re-ceived traffic is higher than the sent traffic for Dev-6 whichis the Amazon Echo continuously streaming and playing au-dio songs from its server Our experiments indicate thatactive IoT devices such as IP cameras or music streamingdevices can be identified by analysis of sent and receivedtraffic volumes in high-load settings

We also investigate traffic flow in the low-load settings(results shown in Figure 9) Surprisingly it can be seen thatcameras do not necessarily produce a higher amount of senttraffic compared to receive traffic (eg Dev-2) The AmazonEcho sends and receives almost equal amount of data in thissetting As expected the gateway still receives more datathan it sends probably because these IoT devices continueto update their status to their associated cloud servers

Sent-to-Received Ratio We explore the possibility ofidentifying the devices by computing the ratio of sent toreceived traffic (in terms of both bytes and frames) Weconsider only data traffic for this analysis and ignore man-agement and control frames Figures 10A and 10B show thesent-to-received ratios in high-load and low-load settings re-spectively In the high-load setting the IP cameras (Dev-2Dev-3 and Dev-7 ) have a ratio greater than 4 for traffic inbytes and greater than 15 for traffic in number of framesThis indicates that an IP camera that actively streams videotraffic may potentially be identified when the ratio is greaterthan 10 Also the ratio in bytes is greater than the ratio inframes for the cameras implying that per frame a largeramount of data is originated from the cameras The desk-top with adapter (Dev-1 ) has a lower ratio (gt10) than thecameras but higher than the access point (asymp 10) and gate-way (lt10) The ratio of frames is much higher than theratio in bytes which indicates that the desktop sends morenumber of frames of smaller size The access point can beclearly identified as it has a ratio close to 10 for both bytesand frames The gateway (Dev-5 ) has a ratio less than 10which indicates higher received traffic Finally the AmazonEcho (Dev-6 ) shows a ratio less than 10 as it continuouslydownloads audio traffic from the Internet

In the low load setting the sent-to-receive ratio does notlook promising as a metric to classify the devices The ratiodoes not behave in the same manner for all the IP cameras- Dev-2 has a ratio less than 10 while Dev-3 and Dev-7have a higher amount of sent traffic The Amazon Echo hasa ratio higher than 10 in this setting Our experiments showthat an analysis of the ratio alone in low-load settings maynot be good enough to identify IoT devices

55 Classifying Streaming CameraFinally we present a use case of our IoTScanner system

Figure 8 Variation of the number of frames andits types for each participating device in high-loadsetting

Figure 9 Variation of the number of frames andits types for each participating device in low-loadsetting

that addresses the issue of privacy in an IoT environment Inparticular we show how to differentiate nearby IoT camerasthat are streaming data from other devices To achieve thatwe leverage our experience on traffic patterns as discussedin previous sections It may be tempting to consider abso-lute traffic volume per device for the classification as any IPcamera produces a lot of traffic compared to other devices(Figure 6) Unfortunately there are a number of poten-tial issues with that approach The traffic volume can varysignificantly depending on the observation window size Inaddition as different wireless channels can be used to carrytraffic and our scanner performs channel hopping it may notbe able to capture all traffic for each and every device Thecamera can also produce varying amount of traffic dependingon its vendor (see Figure 8) Finally the identification maybecome dependent on system parameters such as dwell time

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

5

10

15

20

25

sent

rece

ive

A High Load

Bytes Frames

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1

2

3

4

5

6

7

8

sent

rece

ive

B Low Load

Bytes Frames

Figure 10 Variation of the ratio of sent and receivedtraffic per device basis in both high- and low-loadsettings

Table 2 Confusion matrix to identify streamingcamera ldquoothersrdquo = devices other than cameras

n = 95 classified as camera classified as otherscamera 10 2others 3 80

and hops Therefore we consider ratio on different types oftraffic volume as it looks promising (see Figure 10)

We perform this analysis only on data traffic as it domi-nates control or management traffic in high-load settings forall the devices (Figure 6)

We use two parameters here

bull Rsr - the ratio of sent to received data traffic ieRsr = TrsTrr where Trs and Trr are the amount ofdata traffic (in Bytes) sent from and received respec-tively by a device

bull Rbf - the ratio of the traffic volume in bytes and inframes for a device ie Rbf = BytesFrames whereBytes and Frames are the amount of traffic in bytesand the frames respectively as defined earlier

Our experimental setup consists of the three IP cameras asbefore and some additional WiFi enabled devices like smart-phones laptops tablets and a printer We run eight exper-iments in total having a varying number of active deviceswith at least one active camera in each experiment We havea total number of 95 devices spread over all the experiments

The goal is to classify the cameras that are actively stream-ing The status (active or non-active) of a camera is notchanged during a single experiment though it may changeacross different experiments

Results from the previous experiments give us an Rsr

range of 12plusmn8 and an Rbf range of 1000plusmn500 bytesframeThus a device is identified as an actively streaming cam-era in an experiment only if it satisfies the conditions 40 leRsr le 20 and 500 le Rbf le 1500 In each of the experi-ments we calculate the Rsr and Rbf for every device andcheck if they can be identified as a streaming camera oth-erwise it is identified as a non-camera device (denoted asldquoothersrdquo) The results of these experiments are shown in aconfusion matrix in Table 2 We see that out of 95 deviceidentifications there were 3 false positives and 2 false nega-tives This gives a false acceptance rate (FAR) of asymp 361and a false rejection rate (FRR) of asymp 1667

False positive identification of one device occurs due to thepresence of one Withings IP camera in our test settings Thecamera is kept switched on and configured but no remoteaccess of live video is performed during the experimentsHence it is considered as a non-camera device Howeverthe camera starts streaming to its associated cloud serveras soon as it detects some movement in the area of focuscausing it to be detected as an IP camera Similarly a cou-ple of false negative cases are reported due to the Netatmocamera in our settings This is because our scanner fails tosniff sufficient traffic for the device as it performs channelhopping making a false prediction case

As the aim of our study is to defend against an ldquohonestbut curiousrdquo attacker that makes use of existing networkinginfrastructure to obtain insights about not only the IoT in-frastructure itself but also human users associated with iteg by accessing a surveillance camera we use only MAC

layer un-decrypted traffic for this purpose Preliminary re-sults of our analysis on identifying such streaming camerasin an IoT environment are promising and can lead to futurestudies for identifying other devices from MAC layer traf-fic obtained by passive sniffing Thus our IoTScanner canplay an important role for initiating the process of address-ing the problem of identifying potential privacy breaches inany personalized IoT environment

6 BLUETOOTH LE EXPERIMENTSFor the Bluetooth Low Energy (BLE) experiments we

consider six devices - a OnePlus smartphone an Augustsmart lock two Fitbits and two Lenovo tablets The smart-phone operates the smart lock via an Android app Eachtablet is associated with a Fitbit and operates it via an An-droid app In each experiment one of the Fitbit is pairedallowed to sync its data and unpaired from the associatedtablet the smart lock is also paired locked and unlocked(3-4 times) via commands from the app and unpaired fromthe smartphone Similar to the WiFi experiments we con-duct 10 experiments in each case and compute an averageof each of the measures We do not attempt to decrypt theframes in these experiments as well

We initiate experiments to probe our network settings bydetecting BLE nodes and links Then we attempt to clas-sify the devices via traffic categorization It is seen thatout IoTScanner is able to detect all three pairs of devicesand their links Surprisingly we observe that the smart lockadvertising frames do not follow BLE MAC address random-ization (ie a feature expected to be used by BLE devicesfor privacy reason where the device MAC is replaced withsome random MAC in the BLE frames) In the Fitbit casewe do not detect advertising frames (refer to Section 8)hence no information regarding MAC randomization is re-vealed During the data exchange phase the access addressis seen to change every time the smart lock is paired TheFitbit pairs use a single access address across all pairingevents Hence the access address can be used to identifythe Fitbit-tablet communication

In the smart lock case we observe three types of con-trol frames in addition to the advertising and data frames(BTLE DATA) Those are scan request (SCAN REQ) scanresponse (SCAN RESP) and connection request (CONN REQ)frames No such control frames are seen in the Fitbit caseIn both cases we observe that the data frames (observedon non-advertising channels) are further classified into datacontrol and reserved sub-types We denote the control sub-type frames as data-control (see Figure 11)

We observe traffic on all data channels in the case of theFitbit except for a few experiments where only one channelis seen to be carrying traffic However for the smart lockonly about 4 channels on average carry traffic

We present the results on the data and control traffic perBLE pair in Figure 11

Both the Fitbit pairs generate significantly higher datatraffic when compared to the smart lock (the inset figureshows a magnified version that displays data-control frames)This is expected as Fitbits perform a number of actions likemovement detection quality of sleep estimation and loca-tion information collection during every syncing with thephone whereas the smart lock exchanges only lockunlockcommands The variation in data traffic for the Fitbit canbe explained by the differences in user activity for each ex-

Pair-

1

Pair-

2

Pair-

30

20000

40000

60000

80000

100000

120000

count(

x)

data data-control Control

Pair-

1

Pair-

2

Pair-

30

50100150200250300

Figure 11 Variation of data and control frames (in-dicated by x in count(x)) Pair-1 and Pair-2 are Fit-bit devices and Pair-3 is smart lock device (insetplot shows data-control frames)

Table 3 Label-device mapping for Zigbee experi-ments

Label Device Name

Zig-1 Bulb - switched on and off onceZig-2 Hue BridgeZig-3 Bulb - changed colorZig-4 Bulb - switched on and off multiple times

periment (relation between traffic and activity are describedin [12]) Our experiments show that BLE pairs can also beclassified using traffic volume analysis though this is notdone here due to insufficient number of devices at the timeof experiments

7 ZIGBEE EXPERIMENTSFor the Zigbee experiments we employ the Philips Hue

lighting system that consists of one Hue bridge controllingthree light bulbs We intercept the traffic among the fourdevices and find the number of links nodes and amount oftraffic on each link We conduct 10 experiments in totalIn each experiment we execute different commands on thethree bulbsmdashone bulb is switched on and off once duringthe experiment one bulb is switched on and off 6 timesand one bulb is made to change its color 6 times Eachexperiment lasts 120 seconds The devices are labeled asshown in Table 3

In all the experiments our traffic interceptor detects allfour devices (results are not presented here) We concentrateon the identification of devices using traffic analysis

Figure 12 shows the amount of data sent and received bythe four devices (each indicated by Zig-i) We note that theHue bridge (Zig-2) sends and receives a higher amount ofdata (in size and number of frames) when compared to thelight bulbs Among the light bulbs the bulb with the lowestamount of activity (switching on and off once) ie Zig-1has a smaller number of sent and received frames

The results also show that the controller receives about40 more data than it sends whereas the bulbs have about50 less data received compared to sent These initial tests

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0100000200000300000400000500000600000700000800000

A Bytes

total mframes cframes dframes

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1000

2000

3000

4000

B Frames

total mframes cframes dframes

Figure 7 Variation of amount of traffic per device(subplot (A) in Bytes and (B) in Frames) in low-load setting

in the network along with the type (management controland data) in the high-load setting We determine the trafficin terms of bytes (Figure 6A) and frames (Figure 6B) Aframe is associated with a device if its MAC address is foundin the frame either as the source or destination address

Interestingly it can be seen that the traffic amount andits type can classify the devices at a high level For exam-ple the highest amount of traffic in terms of both bytesand frames is associated with Dev-4 which is the accesspoint (see Table 1) that connects to all other devices presentDev-5 which has no control and management frames is thegateway device connected through Ethernet to the accesspoint The lowest amount of traffic is seen in Dev-1 thedesktop and it is used for occasional browsing during theexperiments The rest of the devices (Dev-2 Dev-3 Dev-6and Dev-7) are associated with high traffic as they are ei-ther IP cameras or the Amazon Echo performing continuousstreaming In each of the devices it can be seen that thedata traffic (in bytes) dominates the control or managementtraffic and is almost equal to the total amount of traffic ofthe corresponding devices However the difference betweenthe number of control and data frames is not as high es-pecially in the case of the cameras We observe that theacknowledgement frames contribute to the large number ofcontrol frames in this case

We explore the traffic volume in low-load settings (resultsshown in Figure 7) It can be seen that almost all the deviceshave control traffic comparable to data traffic (in bytes) asopposed to high-load settings where data traffic dominatesthe control traffic In fact standard deviation of traffic vol-ume is quite significant in this setting in all the devicesperhaps because the devices send their status informationmore at times Thus an analysis of the traffic amount andits composition can potentially be used to learn if an IoTsetting generates a high volume of data traffic

Sent and Received Volume Since the overall traffic

mainly consists of data frames we investigate the amountof data traffic (in terms of bytes and number of frames) sentand received by each device (Figure 8 shows results in high-load settings) The highest amount of traffic (either sentor received) is observed in Dev-4 which is the access pointDev-5 (the gateway) has about three times higher receivedtraffic (in Bytes) as compared to sent Note that the traffictowards the Internet is the received traffic for the gatewayand traffic coming into the local network accounts for sentfor it Thus the result is consistent with the ground truthas there are three cameras sending video traffic We also no-tice that the cameras (Dev-2 Dev-3 and Dev-7 ) have a highamount of sent traffic as expected However the amount ofsent traffic varies significantly among the cameras The re-ceived traffic is higher than the sent traffic for Dev-6 whichis the Amazon Echo continuously streaming and playing au-dio songs from its server Our experiments indicate thatactive IoT devices such as IP cameras or music streamingdevices can be identified by analysis of sent and receivedtraffic volumes in high-load settings

We also investigate traffic flow in the low-load settings(results shown in Figure 9) Surprisingly it can be seen thatcameras do not necessarily produce a higher amount of senttraffic compared to receive traffic (eg Dev-2) The AmazonEcho sends and receives almost equal amount of data in thissetting As expected the gateway still receives more datathan it sends probably because these IoT devices continueto update their status to their associated cloud servers

Sent-to-Received Ratio We explore the possibility ofidentifying the devices by computing the ratio of sent toreceived traffic (in terms of both bytes and frames) Weconsider only data traffic for this analysis and ignore man-agement and control frames Figures 10A and 10B show thesent-to-received ratios in high-load and low-load settings re-spectively In the high-load setting the IP cameras (Dev-2Dev-3 and Dev-7 ) have a ratio greater than 4 for traffic inbytes and greater than 15 for traffic in number of framesThis indicates that an IP camera that actively streams videotraffic may potentially be identified when the ratio is greaterthan 10 Also the ratio in bytes is greater than the ratio inframes for the cameras implying that per frame a largeramount of data is originated from the cameras The desk-top with adapter (Dev-1 ) has a lower ratio (gt10) than thecameras but higher than the access point (asymp 10) and gate-way (lt10) The ratio of frames is much higher than theratio in bytes which indicates that the desktop sends morenumber of frames of smaller size The access point can beclearly identified as it has a ratio close to 10 for both bytesand frames The gateway (Dev-5 ) has a ratio less than 10which indicates higher received traffic Finally the AmazonEcho (Dev-6 ) shows a ratio less than 10 as it continuouslydownloads audio traffic from the Internet

In the low load setting the sent-to-receive ratio does notlook promising as a metric to classify the devices The ratiodoes not behave in the same manner for all the IP cameras- Dev-2 has a ratio less than 10 while Dev-3 and Dev-7have a higher amount of sent traffic The Amazon Echo hasa ratio higher than 10 in this setting Our experiments showthat an analysis of the ratio alone in low-load settings maynot be good enough to identify IoT devices

55 Classifying Streaming CameraFinally we present a use case of our IoTScanner system

Figure 8 Variation of the number of frames andits types for each participating device in high-loadsetting

Figure 9 Variation of the number of frames andits types for each participating device in low-loadsetting

that addresses the issue of privacy in an IoT environment Inparticular we show how to differentiate nearby IoT camerasthat are streaming data from other devices To achieve thatwe leverage our experience on traffic patterns as discussedin previous sections It may be tempting to consider abso-lute traffic volume per device for the classification as any IPcamera produces a lot of traffic compared to other devices(Figure 6) Unfortunately there are a number of poten-tial issues with that approach The traffic volume can varysignificantly depending on the observation window size Inaddition as different wireless channels can be used to carrytraffic and our scanner performs channel hopping it may notbe able to capture all traffic for each and every device Thecamera can also produce varying amount of traffic dependingon its vendor (see Figure 8) Finally the identification maybecome dependent on system parameters such as dwell time

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

5

10

15

20

25

sent

rece

ive

A High Load

Bytes Frames

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1

2

3

4

5

6

7

8

sent

rece

ive

B Low Load

Bytes Frames

Figure 10 Variation of the ratio of sent and receivedtraffic per device basis in both high- and low-loadsettings

Table 2 Confusion matrix to identify streamingcamera ldquoothersrdquo = devices other than cameras

n = 95 classified as camera classified as otherscamera 10 2others 3 80

and hops Therefore we consider ratio on different types oftraffic volume as it looks promising (see Figure 10)

We perform this analysis only on data traffic as it domi-nates control or management traffic in high-load settings forall the devices (Figure 6)

We use two parameters here

bull Rsr - the ratio of sent to received data traffic ieRsr = TrsTrr where Trs and Trr are the amount ofdata traffic (in Bytes) sent from and received respec-tively by a device

bull Rbf - the ratio of the traffic volume in bytes and inframes for a device ie Rbf = BytesFrames whereBytes and Frames are the amount of traffic in bytesand the frames respectively as defined earlier

Our experimental setup consists of the three IP cameras asbefore and some additional WiFi enabled devices like smart-phones laptops tablets and a printer We run eight exper-iments in total having a varying number of active deviceswith at least one active camera in each experiment We havea total number of 95 devices spread over all the experiments

The goal is to classify the cameras that are actively stream-ing The status (active or non-active) of a camera is notchanged during a single experiment though it may changeacross different experiments

Results from the previous experiments give us an Rsr

range of 12plusmn8 and an Rbf range of 1000plusmn500 bytesframeThus a device is identified as an actively streaming cam-era in an experiment only if it satisfies the conditions 40 leRsr le 20 and 500 le Rbf le 1500 In each of the experi-ments we calculate the Rsr and Rbf for every device andcheck if they can be identified as a streaming camera oth-erwise it is identified as a non-camera device (denoted asldquoothersrdquo) The results of these experiments are shown in aconfusion matrix in Table 2 We see that out of 95 deviceidentifications there were 3 false positives and 2 false nega-tives This gives a false acceptance rate (FAR) of asymp 361and a false rejection rate (FRR) of asymp 1667

False positive identification of one device occurs due to thepresence of one Withings IP camera in our test settings Thecamera is kept switched on and configured but no remoteaccess of live video is performed during the experimentsHence it is considered as a non-camera device Howeverthe camera starts streaming to its associated cloud serveras soon as it detects some movement in the area of focuscausing it to be detected as an IP camera Similarly a cou-ple of false negative cases are reported due to the Netatmocamera in our settings This is because our scanner fails tosniff sufficient traffic for the device as it performs channelhopping making a false prediction case

As the aim of our study is to defend against an ldquohonestbut curiousrdquo attacker that makes use of existing networkinginfrastructure to obtain insights about not only the IoT in-frastructure itself but also human users associated with iteg by accessing a surveillance camera we use only MAC

layer un-decrypted traffic for this purpose Preliminary re-sults of our analysis on identifying such streaming camerasin an IoT environment are promising and can lead to futurestudies for identifying other devices from MAC layer traf-fic obtained by passive sniffing Thus our IoTScanner canplay an important role for initiating the process of address-ing the problem of identifying potential privacy breaches inany personalized IoT environment

6 BLUETOOTH LE EXPERIMENTSFor the Bluetooth Low Energy (BLE) experiments we

consider six devices - a OnePlus smartphone an Augustsmart lock two Fitbits and two Lenovo tablets The smart-phone operates the smart lock via an Android app Eachtablet is associated with a Fitbit and operates it via an An-droid app In each experiment one of the Fitbit is pairedallowed to sync its data and unpaired from the associatedtablet the smart lock is also paired locked and unlocked(3-4 times) via commands from the app and unpaired fromthe smartphone Similar to the WiFi experiments we con-duct 10 experiments in each case and compute an averageof each of the measures We do not attempt to decrypt theframes in these experiments as well

We initiate experiments to probe our network settings bydetecting BLE nodes and links Then we attempt to clas-sify the devices via traffic categorization It is seen thatout IoTScanner is able to detect all three pairs of devicesand their links Surprisingly we observe that the smart lockadvertising frames do not follow BLE MAC address random-ization (ie a feature expected to be used by BLE devicesfor privacy reason where the device MAC is replaced withsome random MAC in the BLE frames) In the Fitbit casewe do not detect advertising frames (refer to Section 8)hence no information regarding MAC randomization is re-vealed During the data exchange phase the access addressis seen to change every time the smart lock is paired TheFitbit pairs use a single access address across all pairingevents Hence the access address can be used to identifythe Fitbit-tablet communication

In the smart lock case we observe three types of con-trol frames in addition to the advertising and data frames(BTLE DATA) Those are scan request (SCAN REQ) scanresponse (SCAN RESP) and connection request (CONN REQ)frames No such control frames are seen in the Fitbit caseIn both cases we observe that the data frames (observedon non-advertising channels) are further classified into datacontrol and reserved sub-types We denote the control sub-type frames as data-control (see Figure 11)

We observe traffic on all data channels in the case of theFitbit except for a few experiments where only one channelis seen to be carrying traffic However for the smart lockonly about 4 channels on average carry traffic

We present the results on the data and control traffic perBLE pair in Figure 11

Both the Fitbit pairs generate significantly higher datatraffic when compared to the smart lock (the inset figureshows a magnified version that displays data-control frames)This is expected as Fitbits perform a number of actions likemovement detection quality of sleep estimation and loca-tion information collection during every syncing with thephone whereas the smart lock exchanges only lockunlockcommands The variation in data traffic for the Fitbit canbe explained by the differences in user activity for each ex-

Pair-

1

Pair-

2

Pair-

30

20000

40000

60000

80000

100000

120000

count(

x)

data data-control Control

Pair-

1

Pair-

2

Pair-

30

50100150200250300

Figure 11 Variation of data and control frames (in-dicated by x in count(x)) Pair-1 and Pair-2 are Fit-bit devices and Pair-3 is smart lock device (insetplot shows data-control frames)

Table 3 Label-device mapping for Zigbee experi-ments

Label Device Name

Zig-1 Bulb - switched on and off onceZig-2 Hue BridgeZig-3 Bulb - changed colorZig-4 Bulb - switched on and off multiple times

periment (relation between traffic and activity are describedin [12]) Our experiments show that BLE pairs can also beclassified using traffic volume analysis though this is notdone here due to insufficient number of devices at the timeof experiments

7 ZIGBEE EXPERIMENTSFor the Zigbee experiments we employ the Philips Hue

lighting system that consists of one Hue bridge controllingthree light bulbs We intercept the traffic among the fourdevices and find the number of links nodes and amount oftraffic on each link We conduct 10 experiments in totalIn each experiment we execute different commands on thethree bulbsmdashone bulb is switched on and off once duringthe experiment one bulb is switched on and off 6 timesand one bulb is made to change its color 6 times Eachexperiment lasts 120 seconds The devices are labeled asshown in Table 3

In all the experiments our traffic interceptor detects allfour devices (results are not presented here) We concentrateon the identification of devices using traffic analysis

Figure 12 shows the amount of data sent and received bythe four devices (each indicated by Zig-i) We note that theHue bridge (Zig-2) sends and receives a higher amount ofdata (in size and number of frames) when compared to thelight bulbs Among the light bulbs the bulb with the lowestamount of activity (switching on and off once) ie Zig-1has a smaller number of sent and received frames

The results also show that the controller receives about40 more data than it sends whereas the bulbs have about50 less data received compared to sent These initial tests

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

Figure 8 Variation of the number of frames andits types for each participating device in high-loadsetting

Figure 9 Variation of the number of frames andits types for each participating device in low-loadsetting

that addresses the issue of privacy in an IoT environment Inparticular we show how to differentiate nearby IoT camerasthat are streaming data from other devices To achieve thatwe leverage our experience on traffic patterns as discussedin previous sections It may be tempting to consider abso-lute traffic volume per device for the classification as any IPcamera produces a lot of traffic compared to other devices(Figure 6) Unfortunately there are a number of poten-tial issues with that approach The traffic volume can varysignificantly depending on the observation window size Inaddition as different wireless channels can be used to carrytraffic and our scanner performs channel hopping it may notbe able to capture all traffic for each and every device Thecamera can also produce varying amount of traffic dependingon its vendor (see Figure 8) Finally the identification maybecome dependent on system parameters such as dwell time

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

5

10

15

20

25

sent

rece

ive

A High Load

Bytes Frames

Dev-1

Dev-2

Dev-3

Dev-4

Dev-5

Dev-6

Dev-7

0

1

2

3

4

5

6

7

8

sent

rece

ive

B Low Load

Bytes Frames

Figure 10 Variation of the ratio of sent and receivedtraffic per device basis in both high- and low-loadsettings

Table 2 Confusion matrix to identify streamingcamera ldquoothersrdquo = devices other than cameras

n = 95 classified as camera classified as otherscamera 10 2others 3 80

and hops Therefore we consider ratio on different types oftraffic volume as it looks promising (see Figure 10)

We perform this analysis only on data traffic as it domi-nates control or management traffic in high-load settings forall the devices (Figure 6)

We use two parameters here

bull Rsr - the ratio of sent to received data traffic ieRsr = TrsTrr where Trs and Trr are the amount ofdata traffic (in Bytes) sent from and received respec-tively by a device

bull Rbf - the ratio of the traffic volume in bytes and inframes for a device ie Rbf = BytesFrames whereBytes and Frames are the amount of traffic in bytesand the frames respectively as defined earlier

Our experimental setup consists of the three IP cameras asbefore and some additional WiFi enabled devices like smart-phones laptops tablets and a printer We run eight exper-iments in total having a varying number of active deviceswith at least one active camera in each experiment We havea total number of 95 devices spread over all the experiments

The goal is to classify the cameras that are actively stream-ing The status (active or non-active) of a camera is notchanged during a single experiment though it may changeacross different experiments

Results from the previous experiments give us an Rsr

range of 12plusmn8 and an Rbf range of 1000plusmn500 bytesframeThus a device is identified as an actively streaming cam-era in an experiment only if it satisfies the conditions 40 leRsr le 20 and 500 le Rbf le 1500 In each of the experi-ments we calculate the Rsr and Rbf for every device andcheck if they can be identified as a streaming camera oth-erwise it is identified as a non-camera device (denoted asldquoothersrdquo) The results of these experiments are shown in aconfusion matrix in Table 2 We see that out of 95 deviceidentifications there were 3 false positives and 2 false nega-tives This gives a false acceptance rate (FAR) of asymp 361and a false rejection rate (FRR) of asymp 1667

False positive identification of one device occurs due to thepresence of one Withings IP camera in our test settings Thecamera is kept switched on and configured but no remoteaccess of live video is performed during the experimentsHence it is considered as a non-camera device Howeverthe camera starts streaming to its associated cloud serveras soon as it detects some movement in the area of focuscausing it to be detected as an IP camera Similarly a cou-ple of false negative cases are reported due to the Netatmocamera in our settings This is because our scanner fails tosniff sufficient traffic for the device as it performs channelhopping making a false prediction case

As the aim of our study is to defend against an ldquohonestbut curiousrdquo attacker that makes use of existing networkinginfrastructure to obtain insights about not only the IoT in-frastructure itself but also human users associated with iteg by accessing a surveillance camera we use only MAC

layer un-decrypted traffic for this purpose Preliminary re-sults of our analysis on identifying such streaming camerasin an IoT environment are promising and can lead to futurestudies for identifying other devices from MAC layer traf-fic obtained by passive sniffing Thus our IoTScanner canplay an important role for initiating the process of address-ing the problem of identifying potential privacy breaches inany personalized IoT environment

6 BLUETOOTH LE EXPERIMENTSFor the Bluetooth Low Energy (BLE) experiments we

consider six devices - a OnePlus smartphone an Augustsmart lock two Fitbits and two Lenovo tablets The smart-phone operates the smart lock via an Android app Eachtablet is associated with a Fitbit and operates it via an An-droid app In each experiment one of the Fitbit is pairedallowed to sync its data and unpaired from the associatedtablet the smart lock is also paired locked and unlocked(3-4 times) via commands from the app and unpaired fromthe smartphone Similar to the WiFi experiments we con-duct 10 experiments in each case and compute an averageof each of the measures We do not attempt to decrypt theframes in these experiments as well

We initiate experiments to probe our network settings bydetecting BLE nodes and links Then we attempt to clas-sify the devices via traffic categorization It is seen thatout IoTScanner is able to detect all three pairs of devicesand their links Surprisingly we observe that the smart lockadvertising frames do not follow BLE MAC address random-ization (ie a feature expected to be used by BLE devicesfor privacy reason where the device MAC is replaced withsome random MAC in the BLE frames) In the Fitbit casewe do not detect advertising frames (refer to Section 8)hence no information regarding MAC randomization is re-vealed During the data exchange phase the access addressis seen to change every time the smart lock is paired TheFitbit pairs use a single access address across all pairingevents Hence the access address can be used to identifythe Fitbit-tablet communication

In the smart lock case we observe three types of con-trol frames in addition to the advertising and data frames(BTLE DATA) Those are scan request (SCAN REQ) scanresponse (SCAN RESP) and connection request (CONN REQ)frames No such control frames are seen in the Fitbit caseIn both cases we observe that the data frames (observedon non-advertising channels) are further classified into datacontrol and reserved sub-types We denote the control sub-type frames as data-control (see Figure 11)

We observe traffic on all data channels in the case of theFitbit except for a few experiments where only one channelis seen to be carrying traffic However for the smart lockonly about 4 channels on average carry traffic

We present the results on the data and control traffic perBLE pair in Figure 11

Both the Fitbit pairs generate significantly higher datatraffic when compared to the smart lock (the inset figureshows a magnified version that displays data-control frames)This is expected as Fitbits perform a number of actions likemovement detection quality of sleep estimation and loca-tion information collection during every syncing with thephone whereas the smart lock exchanges only lockunlockcommands The variation in data traffic for the Fitbit canbe explained by the differences in user activity for each ex-

Pair-

1

Pair-

2

Pair-

30

20000

40000

60000

80000

100000

120000

count(

x)

data data-control Control

Pair-

1

Pair-

2

Pair-

30

50100150200250300

Figure 11 Variation of data and control frames (in-dicated by x in count(x)) Pair-1 and Pair-2 are Fit-bit devices and Pair-3 is smart lock device (insetplot shows data-control frames)

Table 3 Label-device mapping for Zigbee experi-ments

Label Device Name

Zig-1 Bulb - switched on and off onceZig-2 Hue BridgeZig-3 Bulb - changed colorZig-4 Bulb - switched on and off multiple times

periment (relation between traffic and activity are describedin [12]) Our experiments show that BLE pairs can also beclassified using traffic volume analysis though this is notdone here due to insufficient number of devices at the timeof experiments

7 ZIGBEE EXPERIMENTSFor the Zigbee experiments we employ the Philips Hue

lighting system that consists of one Hue bridge controllingthree light bulbs We intercept the traffic among the fourdevices and find the number of links nodes and amount oftraffic on each link We conduct 10 experiments in totalIn each experiment we execute different commands on thethree bulbsmdashone bulb is switched on and off once duringthe experiment one bulb is switched on and off 6 timesand one bulb is made to change its color 6 times Eachexperiment lasts 120 seconds The devices are labeled asshown in Table 3

In all the experiments our traffic interceptor detects allfour devices (results are not presented here) We concentrateon the identification of devices using traffic analysis

Figure 12 shows the amount of data sent and received bythe four devices (each indicated by Zig-i) We note that theHue bridge (Zig-2) sends and receives a higher amount ofdata (in size and number of frames) when compared to thelight bulbs Among the light bulbs the bulb with the lowestamount of activity (switching on and off once) ie Zig-1has a smaller number of sent and received frames

The results also show that the controller receives about40 more data than it sends whereas the bulbs have about50 less data received compared to sent These initial tests

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

layer un-decrypted traffic for this purpose Preliminary re-sults of our analysis on identifying such streaming camerasin an IoT environment are promising and can lead to futurestudies for identifying other devices from MAC layer traf-fic obtained by passive sniffing Thus our IoTScanner canplay an important role for initiating the process of address-ing the problem of identifying potential privacy breaches inany personalized IoT environment

6 BLUETOOTH LE EXPERIMENTSFor the Bluetooth Low Energy (BLE) experiments we

consider six devices - a OnePlus smartphone an Augustsmart lock two Fitbits and two Lenovo tablets The smart-phone operates the smart lock via an Android app Eachtablet is associated with a Fitbit and operates it via an An-droid app In each experiment one of the Fitbit is pairedallowed to sync its data and unpaired from the associatedtablet the smart lock is also paired locked and unlocked(3-4 times) via commands from the app and unpaired fromthe smartphone Similar to the WiFi experiments we con-duct 10 experiments in each case and compute an averageof each of the measures We do not attempt to decrypt theframes in these experiments as well

We initiate experiments to probe our network settings bydetecting BLE nodes and links Then we attempt to clas-sify the devices via traffic categorization It is seen thatout IoTScanner is able to detect all three pairs of devicesand their links Surprisingly we observe that the smart lockadvertising frames do not follow BLE MAC address random-ization (ie a feature expected to be used by BLE devicesfor privacy reason where the device MAC is replaced withsome random MAC in the BLE frames) In the Fitbit casewe do not detect advertising frames (refer to Section 8)hence no information regarding MAC randomization is re-vealed During the data exchange phase the access addressis seen to change every time the smart lock is paired TheFitbit pairs use a single access address across all pairingevents Hence the access address can be used to identifythe Fitbit-tablet communication

In the smart lock case we observe three types of con-trol frames in addition to the advertising and data frames(BTLE DATA) Those are scan request (SCAN REQ) scanresponse (SCAN RESP) and connection request (CONN REQ)frames No such control frames are seen in the Fitbit caseIn both cases we observe that the data frames (observedon non-advertising channels) are further classified into datacontrol and reserved sub-types We denote the control sub-type frames as data-control (see Figure 11)

We observe traffic on all data channels in the case of theFitbit except for a few experiments where only one channelis seen to be carrying traffic However for the smart lockonly about 4 channels on average carry traffic

We present the results on the data and control traffic perBLE pair in Figure 11

Both the Fitbit pairs generate significantly higher datatraffic when compared to the smart lock (the inset figureshows a magnified version that displays data-control frames)This is expected as Fitbits perform a number of actions likemovement detection quality of sleep estimation and loca-tion information collection during every syncing with thephone whereas the smart lock exchanges only lockunlockcommands The variation in data traffic for the Fitbit canbe explained by the differences in user activity for each ex-

Pair-

1

Pair-

2

Pair-

30

20000

40000

60000

80000

100000

120000

count(

x)

data data-control Control

Pair-

1

Pair-

2

Pair-

30

50100150200250300

Figure 11 Variation of data and control frames (in-dicated by x in count(x)) Pair-1 and Pair-2 are Fit-bit devices and Pair-3 is smart lock device (insetplot shows data-control frames)

Table 3 Label-device mapping for Zigbee experi-ments

Label Device Name

Zig-1 Bulb - switched on and off onceZig-2 Hue BridgeZig-3 Bulb - changed colorZig-4 Bulb - switched on and off multiple times

periment (relation between traffic and activity are describedin [12]) Our experiments show that BLE pairs can also beclassified using traffic volume analysis though this is notdone here due to insufficient number of devices at the timeof experiments

7 ZIGBEE EXPERIMENTSFor the Zigbee experiments we employ the Philips Hue

lighting system that consists of one Hue bridge controllingthree light bulbs We intercept the traffic among the fourdevices and find the number of links nodes and amount oftraffic on each link We conduct 10 experiments in totalIn each experiment we execute different commands on thethree bulbsmdashone bulb is switched on and off once duringthe experiment one bulb is switched on and off 6 timesand one bulb is made to change its color 6 times Eachexperiment lasts 120 seconds The devices are labeled asshown in Table 3

In all the experiments our traffic interceptor detects allfour devices (results are not presented here) We concentrateon the identification of devices using traffic analysis

Figure 12 shows the amount of data sent and received bythe four devices (each indicated by Zig-i) We note that theHue bridge (Zig-2) sends and receives a higher amount ofdata (in size and number of frames) when compared to thelight bulbs Among the light bulbs the bulb with the lowestamount of activity (switching on and off once) ie Zig-1has a smaller number of sent and received frames

The results also show that the controller receives about40 more data than it sends whereas the bulbs have about50 less data received compared to sent These initial tests

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

Zig-1

Zig-2

Zig-3

Zig-4

0

5000

10000

15000

20000

25000

30000co

unt(

x)

A Bytes

sent received

Zig-1

Zig-2

Zig-3

Zig-4

0

100

200

300

400

500

600

700

800

count(

x)

B Frames

sent received

Figure 12 Variation of sent and received data (A)bytes and (B) frames of four Zigbee devices onePhilips Hue controlling three associated light bulbs

show that an analysis of data sent and received can becomea potential metric for device classification It can be used todistinguish a light controller from its associated lights andmight even help detect the amount of activity on the lights

8 DISCUSSIONIn this section we discuss some of such challenges here

that we have faced during our experimentsWe observe that our wireless access point (LinkSys E1200)

exposes two MAC addresses through the WiFi interface oncertain occasions (for example during our low-load exper-iments) On scrutiny we discover that these are the ad-dresses of the WiFi and Ethernet interfaces Our traffic an-alyzer module does not currently have a mechanism to cor-relate multiple MACs to the same access point In additionwhen we use the OnePlus smartphone to interact with theIP cameras we observe that the IoTScanner detects multi-ple MAC addresses communicating with the camera despitethe absence of other devices in the environment Further in-vestigation reveals that the Marshmallow Android OS usedby the smartphone creates random MAC addresses to inter-act with the access point Thus it is important to devise amechanism to detect multiple MAC addresses as belongingto a single device

During our BLE experiments we observe that the smartlock uses standard advertising BLE channels 37 38 and 39to send control frames Out of these the connection requestframe reveals the channel hopping sequence that is to beused during the data exchange phase Therefore the de-fault ldquofollow connectionrdquo mode of Ubertooth which uses theconnection request frame to follow connections can be usedto detect this BLE pair However we do not observe com-munication initiation on the usual advertising channels forthe Fitbit Hence we had to use the ldquopromiscuousrdquo modeof the sniffer which estimates the hopping sequence fromframes on the data channels This indicates the need tointroduce pair specific sniffing policy in the case of BLE

In addition we notice that the Android applications ofthe BLE devices do not exhibit the same behavior Thesmart lock application does not connect to the lock when theBluetooth pairing is performed manually instead of throughthe application probably indicating some security measuresat the application level However the Fitbit applicationworks even if the pairingunpairing is performed manuallyduring any Fitbit operation (such as syncing) We do notobserve similar issues while working with Zigbee devices

9 RELATED WORKIn this section we present work that is related to the

problem of monitoring complex wireless networks includingpassive and active sniffing systems

WiFi monitoring In [21] Kotz and Essien used syslogmessages SNMP polling and tcpdump packet captures tocharacterize WLAN usage on a college campus over a periodof 77 days Henderson et al [19] built upon the work of [21]by capturing traces including VoIP traces from a larger setof access points and users In these works the packets werecaptured by associating with access points and the traceanalysis was done offline

Davis developed a passive monitoring framework in [13] tomeasure resource usage on 80211b networks and used it toanalyze various setups involving video streaming Furtherwork on resource usage during streaming was done in [27]and [26] Yeo et al implemented a wireless monitoring sys-tem in [38] using multiple sniffers that produced a mergedsynchronized trace which could be used for Link layer trafficcharacterization and network diagnosis They also discussedthe possibility of using anomalies in Link layer traffic for se-curity monitoring The challenges posed by analyzing tracesfrom multiple sniffers was further explored in [23] and [9]In [23] the authors introduced a finite state machine to infermissing packets from a distributed system of sniffers In [9]the authors focused on large scale monitoring by utilizing150 monitors to capture 80211 frames LiveNet [8] usedmultiple sniffers to monitor sensor network deployments byreconstructing routing behavior and network load from cap-tured traces In [8] the authors proposed algorithms forroute inference and topology reconstruction among nodes ina network and provided visualization of the network topol-ogy and data transfer Chhetri and Zheng introduced theWiserAnalyzer in [10]mdasha passive monitoring tool to capturewireless traces and infer relationships among nodes in thenetwork Our proposed IoTScanner aims to provide simi-lar visualization but in real-time and for a larger numberof protocols In comparison to these papers where analysisof the collected data was done offline our work focuses onreal-time passive analysis

A real-time passive monitoring framework was developedby Benmoshe et al [5] and deployed on a university cam-pus Details such as number of clients channel error rateetc were stored in a database and a map of active deviceswas built They provided some visualization in the form of amap of active devices In contrast to [5] our work does nothave prior knowledge of the network setup SNAMP [37] wasa multi-sniffer and multi-visualization platform for wirelesssensor networks that could perform capture and visualiza-tion in real-time Our work aims to enhance some of thefeatures mentioned in these systems with the introductionof APIs for easy access to data more visualization featuresand monitoring of other protocols (Bluetooth and Zigbee)

Kismet [20] is one of the most widely used real-time pas-sive sniffing tools It is targeted at monitoring 80211 net-works but offers plugins for Bluetooth and Zigbee trafficcapturing Though it provides some analysis in terms of enu-merating the wireless networks hosts and amount of data itsees higher level analysis has to be done manually In ad-dition to this Kismet does not have a detailed visualizationtool Some tools have been built on top of Kismet mainlyfor the purpose of visualizing the node locations (using GPSplugins) but several of them are no longer maintained and

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

use outdated libraries Wireshark [11] is also a well knowntool for passive analysis Like Kismet it has plugins to han-dle Bluetooth and Zigbee captures However it does nothave the provision for automated detailed analysis or visu-alization of the observed network The IotScanner sharesmany features with Kismet and Wireshark but hopes to en-hance the user experience with more analysis and visualiza-tion tools We compare a number of features of our systemwith related existing tools mentioned above An overviewof the features present in the IoTScanner and other tools isshown in Table 4

Fingerprinting Franklin et al [16] performed passive fin-gerprinting of 80211 drivers by analyzing the durations be-tween probe request frames sent by different drivers Thisapproach was fine-tuned in [14] to distinguish different op-erating systems using the same driver Pang et al [30] iden-tified four metrics that would help identify users from a net-work trace out of which three could be used even with linklayer encryption These works use different metrics fromours for classification Frame size is one of the factors in [30]but they investigate this only for broadcast frames while ourwork focuses on size and directionality of data frames

BLE monitoring Spill and Bittau [35] developed an open-source single channel Bluetooth sniffer BlueSniff that coulddiscover the MAC addresses of Bluetooth devices The Uber-tooth has a larger set of features at lower cost when com-pared to BlueSniff Ryan [32] built a tool to sniff Blue-tooth Low Energy (BTLE) communication on the Uber-tooth platform This tool is also able to follow connectionsthat were already established at the time of sniffing He im-plemented a traffic injector to demonstrate passive attacksagainst BTLE The BTLE sniffing is now part of the Uber-tooth project and we utilize it for the IoTScanner platformAlbazrqaoe et al [1] presented the BlueEar system a snifferthat is also based on Ubertooth but tries to identify and im-prove the factors that degrade sniffing performance Theyalso discuss the implications of privacy leakage in BLE de-vices and the importance of developing tools for BLE sniff-ing While the focus of the BlueEar system is on sniffingClassic Bluetooth our work deals with BLE communica-tion Privacy in BLE communication of fitness trackers wasexplored in [12] They used the local name parameters inBLE advertising packets to detect fitness trackers They alsodiscovered that fitness trackers send a large number of adver-tising packets and do not randomize their MAC addressesmaking them vulnerable to tracking They analyzed datapackets from Fitbits and concluded that the volume of datasent can be correlated to the level of user activity

Zigbee monitoring There are a number of works thatdiscuss attacks on the the Zigbee Light Link standard Afew examples are [25] [28] and [24] However the fo-cus of these is more on active attacks Dos and Lauradox[15] explored a passive approach where they used the killer-bee framework and Wireshark to sniff communication in aZigbee mesh network Their motivation is similar to theIoTScanner since they also aim to construct the topology ofthe Zigbee network and find privacy leaks However theirwork was conducted on a platform of motes they developedwhile we focused on analyzing commercial IoT devices

10 CONCLUSIONIn this paper we proposed the IoTScanner a system that

Table 4 Proposed IoTScanner Features vs RelatedWorks = supported

Related Work Pass

ive

Rea

l-ti

me

Auto

m

Analy

s

WiF

i

Blu

etooth

Zig

bee

AP

I

Vis

ualiza

tion

Proposed work Wireshark [11] Kismet [20] Benmoshe et al [5] Chhetri et al [10] Yang et al [9] Chen et al [8]

can passively scan and analyze an IoT environment We de-scribed the architecture and implementation details of oursystem The IoTScanner currently scans WiFi BluetoothLow Energy and Zigbee traffic It can analyze the traf-fic to provide an overview of the devices that are active inthe environment and the communication among them Weconducted experiments to evaluate the performance of theIoTScanner in WiFi BLE and Zigbee environments

We introduced a simple ratio analysis of sent-to-receivetraffic that can classify WiFi enabled devices in an activeIoT environment which can potentially contribute to theprivacy related issues of a personalized IoT environmentIn our experiments we showed that we were able to iden-tify actively streaming cameras in our environment Outof 95 device classifications our system had 3 false positives(FAR=361) and 2 false negatives (FRR=1667)

In future work we aim to incorporate more types of IoTdevices into our experiments and introduce advanced analyt-ics to classify the devices based on link layer traffic We arealso interested in enhancing the BLE and Zigbee capabilitiesof the IoTScanner

11 REFERENCES[1] W Albazrqaoe J Huang and G Xing Practical

bluetooth traffic sniffing Systems and privacyimplications In Proc of the ACM Conference onMobile Systems Applications and Services(MobiSys)pages 333ndash345 2016

[2] Amazon Amazon Echo httpswwwamazoncomgpproductB00X4WHP5E

[3] Atmel Corporation RZUSBstickhttpwwwatmelcomtoolsRZUSBSTICKaspx

[4] L Atzori A Iera and G Morabito The internet ofthings A survey Computer networks54(15)2787ndash2805 2010

[5] B Benmoshe E Berliner A Dvir andA Gorodischer A joint framework of passivemonitoring system for complex wireless networks InProc of IEEE Consumer Communications andNetworking Conference (CCNC) pages 55ndash59 2011

[6] Biondi Philippe Scapyhttpwwwsecdevorgprojectsscapy

[7] Bostock Michael and Ogievetsky Vadim and HeerJeffrey D3 Javscript Library httpsd3jsorg

[8] B-R Chen G Peterson G Mainland and M WelshLivenet Using passive monitoring to reconstructsensor network dynamics In Proc of IEEEInternational Conference on Distributed Computing inSensor Systems pages 79ndash98 2008

[9] Y-C Cheng J Bellardo P Benko A C SnoerenG M Voelker and S Savage Jigsaw Solving thepuzzle of enterprise 80211 analysis In Proc ofConference on Applications TechnologiesArchitectures and Protocols for ComputerCommunications (SIGCOMM) pages 39ndash50 2006

[10] A Chhetri and R Zheng WiserAnalyzer A passivemonitoring framework for WLANs In Proc of IEEEInternational Conference on Mobile Ad-hoc andSensor Networks (MSN) pages 495ndash502 2009

[11] G Combs et al Wiresharkhttpwwwwiresharkorg

[12] A K Das P H Pathak C-N Chuah andP Mohapatra Uncovering privacy leakage in blenetwork traffic of wearable fitness trackers In Proc ofthe International Workshop on Mobile ComputingSystems and Applications ACM 2016

[13] M Davis A wireless traffic probe for radio resourcemanagement and qos provisioning in ieee 80211wlans In Proc of the ACM symposium on Modelinganalysis and simulation of wireless and mobilesystems pages 234ndash243 2004

[14] L C C Desmond C C Yuan T C Pheng andR S Lee Identifying unique devices through wirelessfingerprinting In Proc ACM Conference on WirelessSecurity (WiSeC) pages 46ndash55 2008

[15] J Dos Santos C Hennebert and C LauradouxPreserving privacy in secured zigbee wireless sensornetworks In IEEE World Forum on Internet ofThings (WF-IoT) pages 715ndash720 2015

[16] J Franklin D McCoy P Tabriz V NeagoeJ Van Randwyk and D Sicker Passive data linklayer 80211 wireless device driver fingerprinting InProc of the USENIX Security Symposium BerkeleyCA USA 2006

[17] Gartnerhttpwwwgartnercomnewsroomid283971 2015

[18] J Gubbi R Buyya S Marusic and M PalaniswamiInternet of Things (IoT) A vision architecturalelements and future directions Future GenerationComputer Systems 29(7)1645ndash1660 2013

[19] T Henderson D Kotz and I Abyzov The changingusage of a mature campus-wide wireless networkComputer Networks 52(14)2690ndash2712 2008

[20] M Kershaw Kismet httpwwwkismetwirelessnet

[21] D Kotz and K Essien Analysis of a campus-widewireless network Wireless Networks 11(1-2)115ndash1332005

[22] LCottrell Passive vs Active Monitoringhttpswwwslacstanfordeducompnetwan-monpassive-vs-activehtml

[23] R Mahajan M Rodrig D Wetherall and

J Zahorjan Analyzing the mac-level behavior ofwireless networks in the wild SIGCOMM ComputCommun Rev pages 75ndash86 2006

[24] P Morgner S Mattejat and Z Benenson All yourbulbs are belong to us Investigating the current stateof security in connected lighting systems arXivpreprint arXiv160803732 2016

[25] C Muller F Armknecht Z Benenson andP Morgner On the security of the zigbee light linktouchlink commissioning procedure In Sicherheit2016

[26] M Narbutt and M Davis Experimental investigationon voip performance and the resource utilization in80211 b wlans In Proc of IEEE Conference on LocalComputer Networks pages 397ndash403 2006

[27] M Narbutt and M Davis Gauging voip call qualityfrom 80211 wlan resource usage In Proc of IEEESymposium on on World of Wireless Mobile andMultimedia Networks pages 315ndash324 2006

[28] NDhanjani Hacking lightbulbs Security evaluationof the Philips Hue personal wireless lighting systemhttpwwwdhanjanicomblog201308hacking-lightbulbshtml

[29] Ossmann Michael Project Ubertoothhttpsgithubcomgreatscottgadgetsubertooth

[30] J Pang B Greenstein R Gummadi S Seshan andD Wetherall 80211 user fingerprinting In Proc ofthe Conference on Mobile Computing and Networking(MobiCom) pages 99ndash110 2007

[31] Raspberry Pi Foundation Rapsberry Pi 3 Model Bhttpswwwraspberrypiorgproductsraspberry-pi-3-model-b

[32] M Ryan Bluetooth With low energy comes lowsecurity In Proc of USENIX Workshop on OffensiveTechnologies (WOOT) 2013

[33] S Siboni A Shabtai Y Elovici N O Tippenhauerand J Lee Advanced Security Testbed Framework forWearable IoT Devices In Internet of Things (IoT)Secure Service Delivery ACM Transactions onInternet Technology (TOIT) 2016

[34] S Sicari A Rizzardi L A Grieco andA Coen-Porisini Security privacy and trust inInternet of Things The road ahead ComputerNetworks 76146ndash164 2015

[35] D Spill and A Bittau Bluesniff Eve meets alice andbluetooth In Proc of USENIX Workshop onOffensive Technologies (WOOT) USENIX 2007

[36] TP-Link TP-Link TL-WN722N httpwwwtp-linkcomenproductsdetailscat-11 TL-WN722Nhtml

[37] Y Yang P Xia L Huang Q Zhou Y Xu andX Li SNAMP A multi-sniffer and multi-viewvisualization platform for wireless sensor networks InProc of IEEE Conference on Industrial Electronicsand Applications pages 1ndash4 2006

[38] J Yeo M Youssef and A Agrawala A framework forwireless lan monitoring and its applications In Procof the ACM Workshop on Wireless Security (WiSe)pages 70ndash79 2004