IOT SENTINEL: Automated Device-TypeIdentification for Security Enforcement in IoT

Markus MiettinenAhmad-Reza Sadeghi

Technische Universitat Darmstadt, GermanyEmail: {markus.miettinen,ahmad.sadeghi}

@trust.tu-darmstadt.de

Samuel MarchalN. Asokan

Aalto University, Espoo, FinlandEmail: samuel.marchal@aalto.fi

asokan@acm.org

Ibbad HafeezSasu Tarkoma

University of Helsinki, FinlandEmail: {ibbad.hafeez,sasu.tarkoma}

@cs.helsinki.fi

Abstract—With the rapid growth of the Internet-of-Things(IoT), concerns about the security of IoT devices have becomeprominent. Several vendors are producing IP-connected devicesfor home and small office networks that often suffer fromflawed security designs and implementations. They also tendto lack mechanisms for firmware updates or patches that canhelp eliminate security vulnerabilities. Securing networks wherethe presence of such vulnerable devices is given, requires abrownfield approach: applying necessary protection measureswithin the network so that potentially vulnerable devices cancoexist without endangering the security of other devices in thesame network. In this paper, we present IOT SENTINEL, a systemcapable of automatically identifying the types of devices beingconnected to an IoT network and enabling enforcement of rulesfor constraining the communications of vulnerable devices so asto minimize damage resulting from their compromise. We showthat IOT SENTINEL is effective in identifying device types andhas minimal performance overhead.

I. INTRODUCTION

The proliferation of the Internet-of-Things (IoT) is an ongo-ing megatrend in computing with recent forecasts suggestingthe number of IoT devices to reach 24 billion in 2020 [1].More and more people install IP-enabled devices and house-hold appliances in their homes in order to benefit from theimproved ability to be informed about and control relevantfeatures of their homes. Examples of emerging IoT systemsinclude automated heating and air conditioning, security sys-tems and home surveillance, lighting or traditional householdappliances with added WiFi-connectivity. Also entirely newdevice classes utilizing network connectivity are emerging.

Numerous device vendors are providing such connectedproducts to users. Many of these firms are traditional house-hold appliance manufacturers and do not necessarily haveexpertise in engineering systems with computer security inmind. As a result, there are many reports in the media aboutIoT devices being deployed in users’ homes with securityvulnerabilities that can be exploited by attackers (e.g., [2], [3]).There have been reports of a single software flaw affecting afull range of different products, as software components arereused for different device models, thereby placing thousandsof Internet-connected IoT devices susceptible for attack [4].Recent reports also suggest that a considerable number ofdeployed devices use publicly known private keys [5], thus

making them vulnerable to unauthorized access by externaladversaries.

Using vulnerabilities in insecure devices, adversaries canmount attacks against the user’s home network. The preferredsolution for dealing with device vulnerabilities would be topatch them in order to eliminate weaknesses. However, all toooften device vendors are either unable (many users do notregister their devices with the device vendor) or unwilling toprovide such patches in a timely manner. Most IoT users donot have the skills or willingness to perform such tasks orthey even forget unattended IoT devices previously installedin their network leaving them with outdated software versions.

Future security solutions for IoT will need to take intoaccount that IoT devices with unpatched vulnerabilities mayoften be present in the user’s network and co-exist withother devices during their whole device lifetime. The pres-ence of insecure, unpatched legacy IoT devices mandates toaccommodate a brownfield development approach for securitydesigns: the security mechanisms must be able to co-exist withpotentially insecure devices and software that users alreadyhave deployed or will deploy in their home networks.

Goals and Contributions. In this paper, we tackle thisproblem by presenting IOT SENTINEL, a system capable ofidentifying the types of devices introduced to a networkand enforcing mitigation measures for device-types that havepotential security vulnerabilities. IOT SENTINEL does so bycontrolling the traffic flows of vulnerable devices in order toprotect other devices in the network from threats and preventdata leakage.

The contributions of this paper are the following:• We present the design of IOT SENTINEL, a security

system (Sect. III) for managing the security and privacyrisks posed by inherently insecure IoT devices deployedin users’ networks.

• We introduce a device-type identification technique tai-lored for IP-enabled IoT devices (Sect. IV). Device-type identification, in conjunction with information fromvulnerability databases can pinpoint vulnerable devices ina network.

• We demonstrate the accuracy and scalability of IOTSENTINEL device-type identification using a large set ofdifferent real-world off-the-shelf IoT devices (Sect. VI).

arX

iv:1

611.

0488

0v2

[cs

.CR

] 1

3 D

ec 2

016

• We present a framework for confining traffic flows ofdevices identified as vulnerable. The framework usessoftware-defined networking to implement network iso-lation and traffic filtering. We also show that the en-forcement framework can be efficiently implemented withmoderate impact on traffic latency (Sect. V).

II. ADVERSARY MODEL

IOT SENTINEL is targeted at a typical network setup foundin homes and small offices, where devices are connected toa gateway router offering wireless and wired interfaces forconnecting IP-enabled devices to the network. We assume thatwhen IoT devices are initially connected to the target networkthey possibly have security vulnerabilities but are initiallybenign, i.e., uncompromised by the adversary. The adversary’sgoal is to exploit IoT devices to either a) exfiltrate data,security credentials or encryption keys, b) compromise otherIoT devices in the network with the help of a compromiseddevice, or, c) inject false or tampered information into theuser’s network.

It has been demonstrated [6] that also remote attacks againstIoT devices are feasible, if devices like smartphones thatare infected with malware are used to locate vulnerable IoTdevices inside the user’s WiFi network and to open an attackpath for the remote attacker through “NAT hole punching”,allowing the attacker to connect to the target device remotelyfor executing the attack. This emphasizes the importance of thegateway router for upholding the security of the IoT network.

The goal of IOT SENTINEL is to restrict communications inthe network so that the adversary is either not able to connectto the vulnerable device to exploit vulnerabilities, unable to usea compromised device to attack other devices in the network,or, unable to exfiltrate data from compromised devices, therebyeffectively mitigating attacks or limiting their impact.

III. SYSTEM DESIGN

To protect the network against adversaries, IOT SENTINELwill 1) identify the device-types of new IoT devices introducedinto the network, 2) make a vulnerability assessment of adevice using its device-type, and, 3) constrain communicationcapabilities of the device accordingly. In this paper we focuson #1 and #3. The term device-type in this work is definedto denote the combination of make, model and softwareversion of a particular device. Device-type identification inIOT SENTINEL is based on monitoring the communication be-haviour of devices during the setup process to generate device-specific fingerprints which are mapped to device-types with thehelp of a machine learning-based classification model. For agiven device-type, its potential vulnerability can be assessedby consulting an external information source as we brieflydescribe in Sect. III-B. Based on the vulnerability assessment,IOT SENTINEL protects the target network by limiting networkcommunications of the vulnerable device accordingly. Thedesign of our solution, shown in Fig. 1, consists of two majorcomponents: a Security Gateway located in the user’s local

WiFi interface eth0 interface

Device monitoring

Fingerprinting

Device type Identification

Vulnerability assessment

Enforcement

IoT Security Service

Security Gateway

Open vSwitch

SDN Controller

CPU

Cache

Wired IoTdevices

Wireless IoTdevices

Adversary

Remote attacks

Local attacks

Fig. 1. IOT SENTINEL system design

network and an IoT Security Service operated by an IoTSecurity Service Provider (IoTSSP).

A. Security Gateway

The Security Gateway is a software-defined networking(SDN) based traffic monitoring and control component actingas a gateway router of a home or small office. Devices in thelocal network connect to the Security Gateway either throughWiFi or an Ethernet connection. We envisage that SecurityGateway will be deployed either as a dedicated hardwaredevice, or, as a software module or firmware update for legacyWiFi access points having sufficient computational resourcesfor running the Security Gateway functionality.

Wireless devices use WiFi Protected Setup (WPS) to obtaindevice-specific credentials in the form of WPA2 Pre-SharedKeys (PSK) for authenticating with the wireless interface ofthe Security Gateway. This limits a local adversary’s ability toimpersonate other devices and eavesdrop on encrypted WiFitraffic in case the adversary can successfully compromise adevice, as each device has a unique, device-specific PSK.For devices that do not support WPS, Security Gateway willprovide a device-specific WPA2-PSK to be used in the setupprocess for WiFi authentication.

The Security Gateway monitors and profiles the behaviourof individual devices and sends device fingerprints to the IoTSecurity Service for identification (Sect. IV-B) and vulnerabil-ity assessment of individual devices. Based on this assessment,the IoT Security Service returns an isolation level (Sect. V) tobe enforced by the Security Gateway on the device.

B. IoT Security Service

Based on device fingerprints provided by Security Gate-ways, the IoTSSP uses machine learning-based classificationmodels to classify devices according to their device-type. Ini-tially, ground truth information about device-types for trainingthe models needs to be gathered manually by dedicated labora-tory experiments with IoT devices. Crowdsourcing approachescould also be considered, in a similar way as anti-virus ven-dors mutually share malware signatures to improve detection

accuracy. Contrary to traditional fingerprinting approachesutilising distinctive characteristics of particular data fields inprotocol messages, our approach focuses on the behaviouralcharacteristics of devices as discussed in detail in Sect. IV.This allows us to profile and classify devices without priorknowledge about the syntax of messages or data field valuesused by individual devices.

For each device-type in the training data, the IoTSSPperforms a vulnerability assessment. This assessment is basedon querying repositories like the CVE database [7] for vul-nerability reports related to the device-type. The vulnerabilityassessment can be augmented with automated penetration testsor recently developped automated bug searches techniques forIoT devices [8]. Crowdsourced information can also be usedby cross-correlating security incidents and related device-typesas reported by Security Gateways of affected networks. In casevulnerabilities exist, isolation level restricted (cf. Sect V) isassigned. If no vulnerabilities for the device-type are reported,it is assigned the level trusted. Unknown devices will beassigned the level strict.

Using the trained classifiers, the IoTSSP identifies thedevice-types of any new devices by feeding their devicefingerprints to the classifier. Based on each device-type’s vul-nerability assessment, the IoTSSP determines the appropriateisolation level required for the device and notifies the SecurityGateway along with possible auxiliary information dependingon the prescribed isolation level. IoT Security Service does notstore any information about its Security Gateway clients, it justreceives fingerprints and returns an isolation level accordingly.Security Gateway can anonymously request the IoT SecurityService through anonymization networks such as Tor [9] toensure privacy preservation.

C. Mitigation Strategies

To manage vulnerable devices, we apply the following miti-gation strategies that aim at maintaining as much functionalityas possible while minimizing the risk of harm. The technicalimplementation of mitigation measures is discussed in Sect. V.

1) Network Isolation: The target of network isolation is toblock a potentially vulnerable IoT device from communicatingwith other devices so that it cannot mount attacks againstthem. To this end, the Security Gateway divides the user’snetwork into two virtual network overlays: an untrusted and atrusted network. Vulnerable devices are placed in the untrustednetwork and strictly isolated from other devices.

2) Traffic Filtering: The target of traffic filtering is to hinderadversaries from communicating with vulnerable devices andexploiting vulnerabilities or exfiltrating data. Traffic filteringis performed by the Security Gateway and can be targeted atparticular protocols or endpoints so that the functionality ofthe vulnerable device is affected as little as possible.

3) User Notification: In some cases, network isolationand traffic filtering are not sufficient to provide adequateprotection, e.g., if a vulnerable IoT device is equipped withan external communication channel like Bluetooth or an LTEdata connection that cannot be controlled by the Security

Gateway. Since a compromised device could use this channelfor exfiltrating sensitive data, the only effective measure forsecuring the user’s network is to manually remove devices atrisk. We therefore envisage a mechanism by which the systemnotifies the user about devices with insurmountable securityflaws, helps her to identify the device in question and makesure that it really is removed from the user’s network.

IV. IOT DEVICE IDENTIFICATION

As we discuss in more detail in Sect. VII-B, existing deviceidentification approaches based on wireless communicationfingerprinting have drawbacks that limit their usability in ourscenario. Some approaches focus on identifying particularhardware or driver-specific characteristics (e.g., [10]–[13]),which is not sufficiently distinctive, as the same hardwarecomponents and drivers may be deployed in a wide varietyof different device types. Other approaches utilize uniquehardware-specific characteristics like clock skew to identifyunique network interface cards (e.g., [14]–[18]). This is,however, too specific for our use, as we do not wish to identifyindividual device instances, but rather identify the device-type,i.e., the combination of make, model and software version ofeach new device introduced into the target network. The fewtechniques [19], [20] addressing device-type identification aredesigned for high-end devices generating a large amount ofnetwork traffic over a long period of time. However, smarthome IoT devices generate few network traffic in a discon-tinuous manner, which makes these techniques inapplicable inour scenario.

In this section we therefore introduce fingerprints specif-ically designed to discriminate smart home device-types. Atwo-fold classification system fed with these fingerprints deter-mines the type of unknown devices. The system is tailored forIoT scenarios being able to scale and adapt with minimal costto a large and variable set of device-types. It is primarily aimedat devices communicating over WiFi but is also applicable toany communications channel supporting TCP/IP.

A. Device Fingerprint

Our fingerprint is based on passively observed networktraffic. It leverages the specificity of smart home devices thatneed to be inducted into the home network and associated tothe gateway by following a device/vendor specific procedure.This procedure is characterized by a distinguishable sequenceof communications initiated by the inducted device, which ourfingerprint attempts to capture. When a new device identifiedby a newly observed MAC address starts communicating withthe gateway, the latter records n packets {p1, p2, p3, . . . , pn}received from it during its setup phase. The end of the setupphase can be automatically identified by a decrease in therate of packets sent. We extract 23 features, giving a vectorrepresentation for each packet pi = {f1,i, f2,i, f3,i, . . . , f23,i}where i ∈ {1, . . . , n}. Hence, a device fingerprint is a 23× nmatrix F with each column representing a packet receivedwith order i ∈ {1, . . . , n} and each row representing a packet

TABLE IDESCRIPTION OF THE 23 PACKET FEATURES. FEATURES ARE BINARY

EXCEPT THOSE MARKED WITH “(INT)”, WHICH ARE INTEGER.

Type FeaturesLink layer protocol (2) ARP / LLCNetwork layer protocol (4) IP / ICMP / ICMPv6 / EAPoLTransport layer protocol (2) TCP / UDP

Application layer protocol (8) HTTP / HTTPS / DHCP / BOOTP /SSDP / DNS / MDNS / NTP

IP options (2) Padding / RouterAlertPacket content (2) Size (int) / Raw dataIP address (1) Destination IP counter (int)Port class (2) Source (int) / Destination (int)

feature, see Eq. (1). Consecutive identical packets from ourfeature set perspective (i.e. pi = pi+1) are discarded from F.

F =

p1 p2 p3 . . . pn

f1,1 f1,2 f1,3 . . . f1,nf2,1 f2,2 f2,2 . . . f2,nf3,1 f3,2 f3,3 . . . f3,n

......

.... . .

...f23,1 f23,2 f23,3 . . . f23,n

(1)

Features used for packet representation are presented inTable I, none of them rely on packet payload, ensuringthat fingerprints can be extracted from encrypted traffic. Afirst set is composed of binary features set to 1 if someselected communication protocols are used. These 16 protocolswere chosen because they are typically used during deviceassociation over WiFi. Two binary features represent the useof IP header options padding and router alert. The size of thepacket (in Bytes) and the presence of raw data is captured.The destination IP address, if any, is mapped to a counterstarting from 1 and incremented each time a new destinationIP address is observed. This feature denotes the count andorder in which a device communicates with different entitiesduring its setup procedure. The two last features represent thesource and destination ports used, if any, mapped to networkport class:• no port ⇒ f = 0• well-known port [0, 1023]⇒ f = 1• registered port [1024, 49151]⇒ f = 2• dynamic port [49152, 65535]⇒ f = 3

Our fingerprints consider the temporal dimension of com-munication by capturing and keeping in its representationthe sequential order in which packets are sent by a devicep1 → pn. In contrast to techniques aggregating network trafficstatistics over a period of time [12], [21], this extractionmethod raises some issues for comparison, since fingerprintshave variable size n. To cope with this limitations we builda second fixed-size fingerprint F′. F′ is composed of the 12first unique vector packets p from F concatenated to producea 276-dimensional feature vector (12 packets × 23 features):F′ = {f1,1, f2,1, . . . , f23,1, f1,2, f2,2, . . . , f22,i, f23,i}

Preliminary analysis concluded that 12 packets was a goodtrade-off for F′ length: long enough to distinguish device-types

and short enough to be fully filled with unique packets fromF. However, if F does not contain enough unique packets tofill F′, a padding with 0 values is used to reach the size of276 features. This produces a fixed size feature vector F′ thatcan be used with standard machine learning techniques.

B. Device-Type Identification

In order to be scalable and applicable for an evolvingnumber of devices, we propose an identification techniquethat is two-fold. A first operation consists of building a singleclassifier for each device-type we have fingerprints for. Eachclassifier provides a binary decision whether the input finger-print matches the device-type or not. An unknown fingerprintcan be accepted by several classifiers and thus match severaldevice-types. In such cases, a second step discriminates themultiple matches using an edit distance based metric. Whileedit distance could be used alone to identify device-types, thisprocedure is far more time consuming than classification aswe will see in Sect VI-B. The classification step can easilyapply to thousands of device-types, providing a limited setof device-types to discriminate via edit distance, ensuring thespeed and scalability of the approach.

1) Fingerprint Classification: The device classification isoperated using the fixed length fingerprints F′. Let’s as-sume we have a set of fingerprints S for several device-types. We select the subset of n fingerprints SDi

={F′1,i,F′2,i, . . . ,F′n,i} for the device-type Di. The remainingfingerprints of the set are for device-types Dx 6= Di. Thesefingerprints belong to the complement of SDi

in S: ScDi

. Aclassifier Ci is trained for identifying the device-type Di, usingall samples from SDi as one class and a subset of samples fromScDi

as the other class. Only a subset from ScDi

is selected forclassifier training in order to avoid imbalanced class learningissues [22]. Ci is then able to identify an unknown fingerprintas belonging to the type Di or not. This process is repeatedfor each device-type in S in order to build one classifier perdevice-type. We use Random Forest classification algorithm[23] to build these models.

Using this approach, every time the fingerprint of a newdevice-type is captured, a new classifier is trained withoutmaking any modification to the existing classifiers, avoiding acostly relearning process. This “one classifier per device-type”approach also enables the discovery of new devices since itdoes not force any fingerprint to belong to one learned classof a multi-class classifier. A fingerprint can be rejected by allclassifiers and thus be identified as a new device-type.

2) Edit Distance Discrimination: If an unknown fingerprintF′ matches several device-types during the classification pro-cess, the corresponding full fingerprint F is compared to asubset of fingerprints from each device-type it got a match for.The fingerprint comparison is done by computing Damerau-Levenshtein edit distance [24] considering the insertion, dele-tion, substitution and immediate transposition of characters.We consider the matrix F as a word with each character beinga column of the matrix, i.e. a packet pi. Character equality foredit distance computation is considered if all features f from a

Fig. 2. Sample enforcement rule. Rules are specified for single devicesusing their MAC addresses. If the device isolation level is Restricted, a list ofpermitted IP addresses is given through which the device can communicatewith its cloud service. The hash value is used for enforcement rule storage incache.

Internet

Untrusted network Trusted network

Access withinuntrusted network

Access withintrusted network

strict restricted trusted

Vendor Cloud Service

Full Internet access

Fingerprinting and Device type

identification

New device

Fig. 3. After fingerprinting and device-type identification, new devices areassigned to isolation level strict, restricted or trusted.

packet pi are equal to those of another packet pj . The obtainedabsolute distance between two fingerprints is divided by thelength of the longest one to provide a normalized distancevalue bounded on [0, 1].

The distance is computed between the fingerprint to identifyF and a subset of five fingerprints from each device-type Di itgot a match for. Distances are summed up per device-type toget a global dissimilarity score si ∈ [0, 5] of F with the typeDi. The lowest dissimilarity score si gives the final predicteddevice-type for F.

V. ENFORCEMENT

Security Gateway uses Software-defined Networking (SDN)to enable enforcement. We wrote a custom module for Flood-light SDN controller [25] to perform network monitoring tasks,fingerprint generation and to manage communications withIoT Security Service. This module is also responsible forgeneration and enforcement of restricted network access forconnected devices.

When a new device connects to the network, SecurityGateway generates a fingerprint from its network activity. Thisfingerprint is sent to IoT Security Service, which identifiesthe device-type, determines its required network isolation leveland returns it to the Security Gateway. There are three differentisolation levels for any device as shown in Fig. 3:• Strict isolation level only allows the device to communi-

cate with other devices in the untrusted network overlaywith no Internet access for the device.

• Restricted isolation level allows the device to communi-cate with other devices in the untrusted network overlayas well as with a limited set of remote destinations onthe Internet (e.g., the vendor’s cloud service).

• Trusted isolation level allows the device to communicatewith any other device in the trusted network overlay andunrestricted Internet access.

For the Restricted isolation level, the IoT Security Serviceprovides to Security Gateway an additional set of IP addresses(or DNS names) with which communications are allowed.Security Gateway stores the received information in localcache. This information can be updated by regular updatequeries to the IoT Security Service. Security Gateway uses thisinformation to generate enforcement rules to enforce device-specific isolation level required in the network. We identifytraffic to/from any device using device MAC addresses, assum-ing that IoT devices use static MAC addresses. Fig. 2 shows asample enforcement rule generated for a Device X identifiedwith MAC address 13-73-74-7E-A9-C2. The isolation levelfor this device is Restricted. Therefore, the enforcement rulecontains a set of permitted IP addresses through which thedevice can access its cloud services. These rules are enforcedin the network using Open vSwitch (OVS) [26] managed byour customized SDN controller.

Network isolation at device level granularity ensures that novulnerable device, when compromised, is able to infect otherdevices in the trusted network. Our custom module in the SDNcontroller intercepts all traffic flows in the network and ensuresthat they are filtered according to the required isolation levelassigned to the device by IoT Security Service.

Our implementation allows us to extend the traffic filteringmechanism in Security Gateway to make network isolationeven more specific, up to the level of individual flows. SecurityGateway may require a large set of enforcement rules tosetup device specific security preferences in the network.However, for any given flow, there is only one matchingenforcement rule. In order to minimize the latency experiencedduring traffic filtering (i.e., time required to find matchingenforcement rule for a given flow), enforcement rules arestored in a hash table structure to minimize the lookup timeas the enforcement rule cache grows.

Typically, the traffic between two wireless clients connectedto same AP is bridged between the clients and does not go tothe routing plane. Due to this limitation, the traffic cannotbe controlled using OVS. Some managed networks usingproprietary solutions, e.g., Cisco hardware and services, allownetwork administrators to choose the way traffic is managedon these wireless bridges. However, such functionality isnot available in typical consumer wireless APs deployed inexisting networks. To enable traffic filtering between wirelessdevices on typical APs, we leverage Wireless isolation featureavailable on modern wireless APs [27]. We use OpenWRTand Linux drivers to redirect traffic between wireless clientsthrough OVS for identifying the devices connected to thewireless interface. This allows us to manage device-to-devicecommunications and maintain required isolation between wire-

Security Gateway

Wired IoT devices

User Smartphone / Laptop

IoT Security Service

Wireless IoT devices

𝑆𝑟𝑒𝑚𝑜𝑡𝑒

𝑆𝑙𝑜𝑐𝑎𝑙

𝐷2D1D1𝐷𝑛

Testing devices 𝐷1 − 𝐷𝑛

WiFi interface eth0 interface

Fig. 4. Lab setup for IoT device monitoring and mitigation enforcement.

less devices.

VI. EVALUATION

To evaluate the IoT device identification and enforcementof mitigation measures, we developed a prototype system inan IoT laboratory environment shown in Fig. 4 in order tobe able to simulate the IoT device setup process in typicalhome and small office settings and test the performance ofthe enforcement of mitigation measures. We collected trafficmeasurements about the packets sent by each device duringthe setup process and used the measurements in building theclassification model for IoT device identification as describedin Sect. IV.

A. Device Fingerprint Collection

Measurement collection for device fingerprinting was imple-mented with a Linux Laptop running Kali Linux. The softwarepackage hostapd was used to set up a WiFi access pointon the laptop emulating the WiFi interface on a WiFi AP.Similarly, an external Ethernet interface was connected to thelaptop for emulating the Ethernet ports typically present onAPs. The packet capture module was implemented by usingtcpdump on the monitored WiFi and Ethernet interfaces sothat all network traffic visible to the Security Gateway on bothwireless and wired network interfaces could be recorded andforwarded to the fingerprinting module. Data collection wascontrolled by a scripted UI showing the test person performingthe device setup process the necessary step-by-step instructionsrequired to complete the connection of each device to thenetwork. The test scripts were manually compiled followingthe printed or on-line user manual of each device. The setupprocess of most of the examined IoT devices was facilitatedwith a smartphone app or in a few cases a PC application. Forsuch devices, the corresponding app was installed on a testingsmartphone or laptop and used in the setup process accordingto the provided instructions.

1) Tested devices: A representative set of IoT devicestargeted for regular consumers that were available in theEuropean market during Q1 2016 was selected for our exper-iments. These covered most common device classes related tosmart lighting, home automation, security cameras, householdappliances and health monitoring devices. Most of the testeddevices were connected to the user’s network via WiFi or

0

0.2

0.4

0.6

0.8

1

Aria

Hom

eMaticPlug

Withings

MA

XG

ateway

HueB

ridge

HueSw

itch

EdnetGatew

ay

EdnetCam

EdimaxC

am

Lightify

WeM

oInsightSwitch

WeM

oLink

WeM

oSwitch

D-LinkH

omeH

ub

D-LinkD

oorSensor

D-LinkD

ayCam

D-LinkC

am

D-LinkSw

itch(1)

D-LinkW

aterSensor (2)

D-LinkSiren (3)

D-LinkSensor (4)

TP-LinkPlugHS110 (5)

TP-LinkPlugHS100 (6)

EdimaxPlug1101W

(7)

EdimaxPlug2101W

(8)

SmarterC

offee (9)

iKettle2 (10)

Acc

ura

cy

Fig. 5. Ratio of correct identification for 27 device-types

Ethernet, but some devices used other IoT protocols likeZigBee or Z-Wave to connect to the network indirectly throughan Ethernet or WiFi hub device. For such devices, we focusedon monitoring the indirect traffic generated by the hub deviceacting as a gateway towards the user’s network. An overviewof the tested devices is shown in Tab. II.

For each tested device, the typical device setup processwas repeated n = 20 times in order to generate sufficientfingerprints for classification model training. After each testinground, a hard reset of the tested device was performed to returnit to its default factory settings. Typically, a setup procedurefor a device involved activating the device, connecting to thedevice directly over WiFi (the device sets up an ad-hoc WiFiaccess point) or Ethernet with the help of a vendor-providedapp and transmitting WiFi credentials to the user’s networkover this connection to the device. After this, the device wouldtypically reset and connect to the user’s network using theprovided credentials. During this setup procedure, all networktraffic visible to the Security Gateway was recorded and pro-vided to the fingerprinting module for further processing. Thefingerprints generated were then transferred to the IoT SecurityService for off-line training of the classification model. Thedataset collected from our evaluation setup is available onrequest for research use.

B. IoT Device Identification

The fingerprints F and F′ were extracted from the trafficcaptures following the technique introduced in Sect. IV-A toobtain a dataset of 540 fingerprints representing 27 device-types. The IoT device identification method was evaluatedthrough a stratified 10-fold cross-validation process using thisdataset. At each fold, we used the training data to learnone classification model per device-type taking all the nfingerprints F′ of the targeted type as one class and 10*nrandomly selected fingerprints F′ from the rest to represent theother class. The testing data were subjected to the 27 learnedmodels to get a prediction from each. In case of positivedecision from several classifiers, edit distance discriminationwas performed using fingerprints F randomly selected fromthe training data as described in Section IV-B. The cross-validation was repeated 10 times to generalize the results.

The ratio of correct identification for each device-type is

TABLE IILIST OF IOT DEVICES USED IN THE EVALUATION AND THEIR SUPPORTED CONNECTIVITY TECHNOLOGIES

Identifier Device Model WiF

iZi

gBee

Ethe

rnet

Z-W

ave

Oth

er

Aria Fitbit Aria WiFi-enabled scale • ◦ ◦ ◦ ◦HomeMaticPlug Homematic pluggable switch HMIP-PS ◦ ◦ ◦ ◦ •Withings Withings Wireless Scale WS-30 • ◦ ◦ ◦ ◦MAXGateway MAX! Cube LAN Gateway for MAX! Home automation sensors ◦ ◦ • ◦ •HueBridge Philips Hue Bridge model 3241312018 ◦ • • ◦ ◦HueSwitch Philips Hue Light Switch PTM 215Z ◦ • ◦ ◦ ◦EdnetGateway Ednet.living Starter kit power Gateway • ◦ ◦ ◦ •EdnetCam Ednet Wireless indoor IP camera Cube • ◦ • ◦ ◦EdimaxCam Edimax IC-3115W Smart HD WiFi Network Camera • ◦ • ◦ ◦Lightify Osram Lightify Gateway • • ◦ ◦ ◦WeMoInsightSwitch WeMo Insight Switch model F7C029de • ◦ ◦ ◦ ◦WeMoLink WeMo Link Lighting Bridge model F7C031vf • • ◦ ◦ ◦WeMoSwitch WeMo Switch model F7C027de • ◦ ◦ ◦ ◦D-LinkHomeHub D-Link Connected Home Hub DCH-G020 • ◦ • • ◦D-LinkDoorSensor D-Link Door & Window sensor ◦ ◦ ◦ • ◦D-LinkDayCam D-Link WiFi Day Camera DCS-930L • ◦ • ◦ ◦D-LinkCam D-Link HD IP Camera DCH-935L • ◦ ◦ ◦ ◦D-LinkSwitch D-Link Smart plug DSP-W215 • ◦ ◦ ◦ ◦D-LinkWaterSensor D-Link Water sensor DCH-S160 • ◦ ◦ ◦ ◦D-LinkSiren D-Link Siren DCH-S220 • ◦ ◦ ◦ ◦D-LinkSensor D-Link WiFi Motion sensor DCH-S150 • ◦ ◦ ◦ ◦TP-LinkPlugHS110 TP-Link WiFi Smart plug HS110 • ◦ ◦ ◦ ◦TP-LinkPlugHS100 TP-Link WiFi Smart plug HS100 • ◦ ◦ ◦ ◦EdimaxPlug1101W Edimax SP-1101W Smart Plug Switch • ◦ ◦ ◦ ◦EdimaxPlug2101W Edimax SP-2101W Smart Plug Switch • ◦ ◦ ◦ ◦SmarterCoffee Smarter SmarterCoffee coffee machine SMC10-EU • ◦ ◦ ◦ ◦iKettle2 Smarter iKettle 2.0 water kettle SMK20-EU • ◦ ◦ ◦ ◦

reported in Fig. 5. The accuracy of identification is over 0.95for 17 devices, most of them reaching 1. However, we can seethat 10 devices are correctly identified with an accuracy around0.5, which is lower but still good considering a random typeassignment that would give 1/27 = 0.037 accuracy. The globalratio of correct identification over the 27 devices is 0.815.To better understand why the 10 aforementioned devices gotidentified with lower accuracy than others, Table III depictstheir confusion matrix. We can see that the misidentificationoccurs between similar devices from same vendors, i.e., a setof similar D-Link devices (1-4), two models of smart plugsfrom TP-Link (5-6) and Edimax (7-8) and a coffee machine (9)and water kettle (10) from the same vendor. In contrast, Fig. 5shows that our identification technique is able to distinguishdevices from same vendor with different purposes, e.g., D-Link camera, hub and sensors, WeMo devices, Edimax cameraand plug, etc. From a system point of view, the misidentifieddevices are very similar: D-Link water sensor (2), siren (3)and sensor (4) have identical hardware and firmware version,as TP-Link plugs (5-6) do. Hence, these devices are likelyto share vulnerabilities, if any. Moreover, SmarterCoffee (9)and iKettle2 (10) received a firmware update during the datacollection period that led to generate new fingerprints. Thesefingerprints were distinguishable from the one generated withtheir older firmware version. This suggests that our devicefingerprint is able to discriminate device-types as long as theyhave different hardware/firmware versions, and vulnerabilitypatching would change the fingerprint of a device. Hence, thisspecific misidentification issue is not a concern for our purpose

of identifying vulnerable devices.

TABLE IIICONFUSION MATRIX FOR 10 DEVICES WITH LOW IDENTIFICATION RATE

(DEVICE INDEX FIND CORRESPONDING NAMES IN FIG. 5)A= ACTUAL TYPE / P= PREDICTED TYPE

A\P 1 2 3 4 5 6 7 8 9 101 123 23 28 26 0 0 0 0 0 02 0 103 42 55 0 0 0 0 0 03 4 55 87 54 0 0 0 0 0 04 8 65 49 78 0 0 0 0 0 05 0 0 0 0 132 68 0 0 0 06 0 0 0 0 88 112 0 0 0 07 0 0 0 0 0 0 125 75 0 08 0 0 0 0 0 0 84 116 0 09 0 0 0 0 0 0 0 0 90 11010 0 0 0 0 0 0 0 0 117 83

From a performance perspective, Tab. IV reports the timetaken for device-type identification. We see that most ofthe time is spent on cases where discrimination using editdistance was required. During experiments, 55% of the ana-lyzed fingerprints matched more than one type and needed adiscrimination step that involved between two and five types.On average, seven edit distance computations were neededper device. The average time for device-type identification isaround 150 ms. For comparison, the time taken for devicesetup was between one and two minutes, the packet collectionwas performed in parallel of this operation. The classificationwith Random Forest takes very little time (<1 ms) and growslinearly with the number of types to identify. This showsthat IOT SENTINEL can easily scale to thousands of device-

types while keeping classification time below 100 ms and typeidentification likely below 1 second.

TABLE IVTIME CONSUMPTION FOR DEVICE-TYPE IDENTIFICATION. TIME FOR

SINGLE STEPS IS PRESENTED AT THE TOP AND TIME FOR AN AVERAGETYPE IDENTIFICATION IN OUR LAB SETUP IS PRESENTED BELOW.

Steps Mean (±StDev)1 Classification (Random Forest) 0.014 ms (±0.003)1 Discrimination (edit distance) 23.36 ms (±24.37)Fingerprint extraction 0.850 ms (±0.698)27 Classifications (Random Forest) 0.385 ms (±0.081)7 Discriminations (edit distance) 156.5 ms (±170.6)Type Identification 157.7 ms (±171.4)

C. Mitigation Measures Enforcement

Fig. 4 shows the lab setup used for testing enforcementmechanism employed by Security Gateway. In general, Secu-rity Gateway can be deployed in two setups.• A Raspberry PI 2 (R-Pi II) device running both the

OVS and custom SDN controller acts as standaloneSecurity Gateway in the network. An external USB WiFidongle, or integrated WiFi and hostapd used to emulatewireless interface on R-Pi II [28].

• An off-the-shelf router on which we setup OpenFlow en-abled Access Point (OF-AP) by installing OVS softwarepackage over the stock OpenWRT OS of the router [27].In that case, the OVS on OF-AP will be managed by ourcustom SDN controller running on a separate machine.

We selected the first setup for evaluation. For each exper-iment, we performed 15 iterations for each measured devicepair. We measured the latency experienced between devicesD1 − Dn connected to Security Gateway wireless interface,as well as between devices and servers, where Slocal is inthe local network and Sremote is a remote server deployed inAmazon EC2. Table V shows that the enforcement mechanismemployed for traffic filtering by Security Gateway does notimpact the latency experienced by the user. Fig. 6a shows theimpact on latency experienced by devices regarding the totalnumber of concurrent flows in the network. The results showthat the increase in latency for up to 150 concurrent flows isinsignificant to affect user experience or device operations.

TABLE VIOVERHEAD DUE TO FILTERING

MECHANISM.

Case OverheadMean (± StDev)

D1D2 Latency +5.84% (±4.76%)D1D3 Latency +0.71% (±5.88%)CPU utilization +0.63% (±1.8%)Memory usage +7.6% (±4.6%)

We also measured thememory and CPUoverhead of ourenforcement mechanism.Fig. 6b shows that thereis very little overheadin terms of CPUutilization due to trafficfiltering mechanism. Theoverall CPU utilizationmeasurements also shows that Security Gateway does notrequire high processing power to perform network operations.

Similarly, Fig. 6c shows the amount of memory utilized bySecurity Gateway with and without using filtering mechanismis almost similar. The amount of memory used for storing

TABLE VLATENCY (MS) EXPERIENCED BY USERS WHERE D1−D4 ARE USER

DEVICES CONNECTED TO SECURITY GATEWAY (SGW) AND Slocal ANDSremote ARE SERVERS.

Source Destination FilteringMean (± StDev)

No FilteringMean (± StDev)

D1 D4 24.8 (±1.4) 24.5 (±1.4)Slocal 18.4 (±1.3) 18.2 (±1.3)Sremote 20.6 (±3.3) 20.3 (±3.1)

D2 D4 28.5 (±1.7) 28.2 (±1.6)Slocal 17.2 (±1.2) 17.0 (±1.2)Sremote 20.0 (±2.9) 19.8 (±3.1)

D3 D4 27.6 (±1.6) 27.5 (±1.6)Slocal 15.5 (±1.2) 15.4 (±1.1)Sremote 20.6 (±3.2) 19.9 (±3.2)

enforcement rules can be controlled by limiting the size ofenforcement rule cache and removing unused enforcementrules (for the devices that are no longer connected to thenetwork) from the cache. The percentage increase in memory,CPU utilization as well as latency experienced by user due tofiltering mechanism is given in Table VI. These results showthat the overhead on memory and CPU utilization is low. Fig. 6also shows that a small form factor PC such as RaspberryPi II provides sufficient computational resources for a typicalenvironment hosting, e.g., a hundred IoT devices generatingthe same number of concurrent flows and requiring as manyenforcement rules.

VII. RELATED WORK

A. Securing IoT Device-to-Device Communications

Authentication schemes tailored for resource constraineddevices [29] are primarily used to control communicationsbetween IoT devices. Zenger et al. [30] proposed a vicinitybased pairing mechanism that delegates trust from one nodeto another based on physical proximity. Messaging betweendevices can be authenticated using multiple communicationchannels (e.g. Bluetooth + NFC) to ensure secure pairing [31].However, these schemes require some implementation on alldevices of the system to be applicable, failing to cope withthe IoT brownfield of legacy devices already deployed.

At run time, communications between IoT devices can berestricted based on high level user requirements that a system,namely SIFT [32], translates to low level access control poli-cies. Fully automated techniques to identify malicious commu-nications rely on intrusion detection systems tailored for IoTscenarios [33]. Verification of data sent from a given devicecan be based on measurement correlation with other devices toidentify malicious nodes attempting to pollute measurements[34]. Action can then be taken to discard communications fromthis device. The main difference between IOT SENTINEL andthese techniques is that the former is preventive, mitigatingthe threat of vulnerable devices when they are inducted in thesystem and before any malicious communication is initiated.

A recently announced commercial product that follows asimilar conceptual approach as IOT SENTINEL is F-SecureSENSE [35]. However, SENSE is focused on traditional pro-tection technologies like anti-virus capabilities and blocking

20 40 60 80 100 120 140

Number of concurrent flows

0

5

10

15

20

25

Lat

ency

(ms)

D1-D2 (wo Filtering)D1-D2 (w Filtering)D1-D3 (wo Filtering)D1-D3 (w Filtering)

(a) Latency increase relative to concurrent flows.

0 20 40 60 80 100 120 140

Number of Concurrent Flows

36

38

40

42

44

46

48

50

CP

Uut

iliza

tion

(%)

With FilteringWithout Filtering

(b) CPU utilization for Security Gateway.

0 5000 10000 15000 20000

Number of enforcement rules

0

20

40

60

80

100

Mem

ory

Con

sum

ptio

n(i

nM

Bs)

With FilteringWithout Filtering

(c) Memory utilization of Security Gateway.

Fig. 6. IOT SENTINEL Performance evaluation for Raspberry PI based deployment of Security Gateway. There is only minimal increase in CPUand memory utilization of Security Gateway with filtering mechanism enabled. Additionally, the increase in latency experienced relative to increasing number ofconcurrent flows in the network is insignificant in terms of user experience.

of botnet controllers and malicious websites [36]. Unlike IOTSENTINEL, it does not seem to provide means for automaticidentification of arbitrary IoT device-types.

B. Device Fingerprinting

Early work in 802.11 wireless communication fingerprintingtargeted the identification of hardware and driver specificcharacteristics, with active [10] or passive methods [11]–[13]. Cache [11] used 802.11 frames’ duration field that onlytakes few discrete values depending on driver implementationto identify WiFi drivers. Passively recording 802.11 probingframes inter-arrival time from a device, Franklin et al. [12]were able to classify 17 WiFi drivers with an accuracy rangingbetween 77% and 96% using a Bayesian classification method.While relying on passively captured network traffic as wedo, these techniques build hardware/driver specific fingerprintsthat are too coarse-grained for our purpose of identifyingdevice-types. Low cost IoT devices are likely to use identicalcheap WiFi interfaces and corresponding drivers leading toaggregate a wide range of device-types in the same class usingthese techniques.

On the other hand, network features such as packet desti-nation, SSID probes, broadcast packet size and MAC protocolfields were used to fingerprint specific users in [21]. Hardwarespecific characteristics such as clock skew [14]–[16] or radio-frequency signature [17], [18] can be used to identify a uniquenetwork interface card, mostly for rogue wireless Access Pointdetection purposes. IoT-specific techniques target mostly high-end devices, leveraging mobile device configuration [37], orsensor specific features [38]–[40] though similar techniquescan be applied to larger classes of IoT devices [41], [42]. How-ever, sensor data analysis only addresses the identification ofa limited class of devices actually reporting such information.All these methods build fingerprints able to uniquely identify adevice, which is too specific to identify an unknown device asbelonging to one type. Our technique is positioned between theformer and latter approaches, providing the right granularityto identify device-types from passive traffic captures.

Gao et al. [19] similarly introduced a passive technique to

identify device-types using the fact that a type of device mod-ifies a packet in a unique way, due to its internal architecture,while processing it. Capturing incoming and outgoing packetsand applying wavelet analysis, they were able to discriminatedevice-types. This technique only applies to devices processingand forwarding packets such as routing devices but is notapplicable to end point IoT devices that we target in our work.

GTID [20] addresses as well device-type identification.GTID builds a feature vector composed of inter-arrival timeof packets sent by a device for a specific type of traffic(e.g. Skype, ICMP, etc.). Feature vectors are used in a neuralnetwork predicting as many classes as there are device-typesto identify. The main difference with our work is that ourfingerprints are not specific to a type of traffic sent at highrate over a significant period of time. In contrast to devicesused for GTID evaluation, i.e., smartphones and tablets, mostIoT devices generate less traffic with less diversity limitingthis approach to high-end devices. Our technique has a widerscope, applying to wireless and wired traffic. In addition, usinga single multi-class neural network model in GTID requiresfull model relearning when one new type is identified whileour “one classifier per type approach” does not.

VIII. DISCUSSION AND FUTURE WORK

A. Support for Legacy Installations

In this work we considered a setting in which the userintroduces new devices to his or her network via the SecurityGateway and device fingerprinting and identification is basedon the characteristic traffic patterns of devices when they areinitially connected to the network. However, we envisage IOTSENTINEL also to support legacy network installations byupdating a compatible gateway router with Security Gatewayfunctionality with the necessary fingerprinting and traffic fil-tering components by means of a software update.

In such cases, fingerprinting and device-type identificationhappens after devices have already been connected to theuser’s network. The profiling of devices has therefore tohappen based on the communication behaviour that devices

exhibit during standby (e.g., heartbeat messages to the ven-dor’s cloud solution), or, during the normal operation of thedevice. Our working hypothesis is that similarly as with theinitial setup messages, message exchanges during standby andoperation cycles are likely to be characteristic for particulardevice-types and therefore form a good basis for device-typeidentification. In future work, we intend to investigate thisapproach further to verify its effectiveness.

Legacy network installations often use WPA2-Personal witha network-specific PSK to authenticate devices to the network.If there are devices with security vulnerabilities present, itis possible that the confidentiality of the PSK is breached,leaking the PSK to an adversary. In order to protect theuser’s IoT devices against a local adversary using a leakedPSK to infiltrate the user’s network, we need to establish avirtual network overlay consisting of an untrusted networkrepresenting the existing potentially vulnerable network setupand a new, trusted network. All devices in the legacy in-stallation will be initially in the untrusted network. Afterperforming device-type identification, such devices that do nothave known vulnerabilities will be transferred to the trustednetwork by using the re-keying functionality defined by WiFiProtected Setup (WPS) [43]. For devices supporting WPS re-keying, it can be triggered by deprecating the legacy network’sWPA2-Personal PSK, after which the device will trigger a re-keying exchange to obtain a new WPA2-Personal PSK for thetrusted network overlay. The new PSK provided during re-keying will be device-specific, in order to allow device-specificauthentication in the trusted network overlay.

For legacy devices that do not support WPS re-keying, thereare two options: 1) WPA2-Personal PSK remains in force: Thedevice continues to operate in the untrusted network, but isunable to communicate with devices in the trusted network.2) WPA2-Personal PSK is deprecated: The device will beunable to access the user’s network. Manual re-introductionof the device to the user’s network is required before it canre-join. The advantage of the former solution is that it doesnot impact user experience by disconnecting devices from theuser’s network. However, devices remaining in the untrustednetwork are likely more exposed to adversarial attacks. There-fore, the Security Gateway may optionally prompt the user(e.g., through its management interface) to re-authenticate suchdevices manually. Devices with known security vulnerabilitieswill remain in the untrusted network. The trusted and untrustednetworks, however, will be strictly separated from each other.

B. Impact of Software Updates

In this work, we defined a device-type to denote the combi-nation of a device’s make, model and software version. As inour set of test devices, however, only a few devices offered thepossibility for a software update during our experimentationperiod, we were not able to comprehensively investigate thiscapability. For three devices for which updates were applied,these updates led to generate distinguishable fingerprints be-tween software versions of these devices. In our future workwe expect to be able to investigate this further, as we expect

over time software updates to become available for a largerset of the analysed devices.

IX. CONCLUSION

In this paper, we presented IOT SENTINEL, a system for au-tomatic identification and security enforcement of IoT deviceswith potential security vulnerabilities. We propose a novelapproach in which identification is based on profiling of thedevice type-specific communication behaviour of individualdevices. Our system provides protection for the user’s networkby enforcing network isolation where communications ofpotentially vulnerable devices are strictly controlled, therebyeffectively mitigating security risks related to these devices.

REFERENCES

[1] J. Greenough. How the ’Internet of Things’ will impact consumers,businesses, and governments in 2016 and beyond. Business Insider. [Ac-cessed: 2016-07-18]. [Online]. Available: http://www.businessinsider.de/how-the-internet-of-things-market-will-grow-2014-10

[2] Core Security, “AVTECH DVR multiple vulnerabilities,” http://www.coresecurity.com/advisories/avtech-dvr-multiple-vulnerabilities,Aug. 2013, [Accessed: 2016-03-29].

[3] D. Lodge, “Hacking a Wi-Fi coffee machine – part 1,” https://www.pentestpartners.com/blog/hacking-a-wi-fi-coffee-machine-part-1/,2015, [Accessed: 2016-03-29].

[4] Senrio. 400,000 publicly available IoT devices vulnerable to singleflaw. [Accessed: 2016-07-07]. [Online]. Available: http://blog.senr.io/blog/400000-publicly-available-iot-devices-vulnerable-to-single-flaw

[5] SEC Consult. (2016, Sep.) House of keys: 9 months later. . . 40% worse.[Accessed: 2016-09-06]. [Online]. Available: http://blog.sec-consult.com/2016/09/house-of-keys-9-months-later-40-worse.html

[6] V. Sivaraman, D. Chan, D. Earl, and R. Boreli, “Smart-phones attackingsmart-homes,” in Proceedings of the 9th ACM Conference on Securityand Privacy in Wireless and Mobile Networks, ser. WiSec ’16. ACM,2016, pp. 195–200.

[7] MITRE Corporation. Common vulnerabilities and exposures. [Online].Available: https://cve.mitre.org/data/downloads/index.html

[8] Q. Feng, R. Zhou, C. Xu, Y. Cheng, B. Testa, and H. Yin, “Scalablegraph-based bug search for firmware images,” in Proceedings of the 2016ACM SIGSAC Conference on Computer and Communications Security,ser. CCS ’16. ACM, 2016, pp. 480–491.

[9] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The second-generation onion router,” DTIC Document, Tech. Rep., 2004.

[10] S. Bratus, C. Cornelius, D. Kotz, and D. Peebles, “Active behavioralfingerprinting of wireless devices,” in Proceedings of the First ACMConference on Wireless Network Security, ser. WiSec ’08. ACM, 2008,pp. 56–61.

[11] J. Cache, “Fingerprinting 802.11 implementations via statistical analysisof the duration field,” Uninformed, vol. 5, 2006.

[12] J. Franklin, D. McCoy, P. Tabriz, V. Neagoe, J. Van Randwyk, andD. Sicker, “Passive data link layer 802.11 wireless device driver finger-printing,” in Proceedings of the 15th Conference on USENIX SecuritySymposium - Volume 15, ser. USENIX-SS’06. Berkeley, CA, USA:USENIX Association, 2006.

[13] C. Maurice, S. Onno, C. Neumann, O. Heen, and A. Francillon,“Improving 802.11 fingerprinting of similar devices by cooperativefingerprinting,” in Proceedings of the 2013 International Conference onSecurity and Cryptography (SECRYPT), 2013, pp. 1–8.

[14] T. Kohno, A. Broido, and K. C. Claffy, “Remote physical device fin-gerprinting,” IEEE Transactions on Dependable and Secure Computing,vol. 2, no. 2, pp. 93–108, April 2005.

[15] S. Jana and S. K. Kasera, “On fast and accurate detection of unauthorizedwireless access points using clock skews,” in Proceedings of the 14thACM International Conference on Mobile Computing and Networking,ser. MobiCom ’08. ACM, 2008, pp. 104–115.

[16] C. Arackaparambil, S. Bratus, A. Shubina, and D. Kotz, “On thereliability of wireless fingerprinting using clock skews,” in Proceedingsof the Third ACM Conference on Wireless Network Security, ser. WiSec’10. ACM, 2010, pp. 169–174.

[17] O. Ureten and N. Serinken, “Wireless security through rf fingerprinting,”Canadian Journal of Electrical and Computer Engineering, vol. 32,no. 1, pp. 27–33, Winter 2007.

[18] V. Brik, S. Banerjee, M. Gruteser, and S. Oh, “Wireless device identi-fication with radiometric signatures,” in Proceedings of the 14th ACMInternational Conference on Mobile Computing and Networking, ser.MobiCom ’08. ACM, 2008, pp. 116–127.

[19] K. Gao, C. Corbett, and R. Beyah, “A passive approach to wireless de-vice fingerprinting,” in Proceedings of the 2010 IEEE/IFIP InternationalConference on Dependable Systems Networks (DSN). IEEE, 2010, pp.383–392.

[20] S. V. Radhakrishnan, A. S. Uluagac, and R. Beyah, “GTID: A techniquefor physical device and device type fingerprinting,” IEEE Transactionson Dependable and Secure Computing, vol. 12, no. 5, pp. 519–532,2015.

[21] J. Pang, B. Greenstein, R. Gummadi, S. Seshan, and D. Wetherall,“802.11 user fingerprinting,” in Proceedings of the 13th Annual ACMInternational Conference on Mobile Computing and Networking, ser.MobiCom ’07. ACM, 2007, pp. 99–110.

[22] H. He and E. A. Garcia, “Learning from imbalanced data,” IEEE Trans.on Knowl. and Data Eng., vol. 21, no. 9, pp. 1263–1284, Sep. 2009.

[23] L. Breiman, “Random forests,” Machine Learning, vol. 45, no. 1, pp.5–32, 2001.

[24] F. J. Damerau, “A technique for computer detection and correction ofspelling errors,” Commun. ACM, vol. 7, no. 3, pp. 171–176, Mar. 1964.

[25] Big Switch Networks, “Project floodlight - floodlight OpenFlow con-troller,” http://www.projectfloodlight.org/floodlight/, Oct. 2016, [Ac-cessed: 2016-09-17].

[26] B. Pfaff, J. Pettit, T. Koponen, E. J. Jackson, A. Zhou, J. Rajahalme,J. Gross, A. Wang, J. Stringer, P. Shelar, K. Amidon, and M. Casado,“The design and implementation of Open vSwitch,” in Proceedingsof the 12th USENIX Conference on Networked Systems Design andImplementation. USENIX Association, 2015, pp. 117–130.

[27] S. Hatonen, P. Savolainen, A. Rao, H. Flinck, and S. Tarkoma, “Off-the-shelf software-defined Wi-Fi networks,” in Proceedings of the 2016Conference on ACM SIGCOMM 2016 Conference, ser. SIGCOMM ’16.ACM, 2016, pp. 609–610.

[28] Lady ada, “Setting up a rasperry PI as a WiFi access point,” AdaFruit. [Online]. Available: https://cdn-learn.adafruit.com/downloads/pdf/setting-up-a-raspberry-pi-as-a-wifi-access-point.pdf

[29] J. L. Hernandez-Ramos, M. P. Pawlowski, A. J. Jara, A. F. Skarmeta,and L. Ladid, “Toward a lightweight authentication and authorizationframework for smart objects,” IEEE Journal on Selected Areas inCommunications, vol. 33, no. 4, pp. 690–702, 2015.

[30] C. T. Zenger, M. Pietersz, J. Zimmer, J.-F. Posielek, T. Lenze, andC. Paar, “Authenticated key establishment for low-resource devicesexploiting correlated random channels,” Computer Networks, pp. –,2016.

[31] V. Mora-Afonso, P. Caballero-Gil, and J. Molina-Gil, “Strong authenti-cation on smart wireless devices,” in Second International Conferenceon Future Generation Communication Technologies (FGCT), 2013, pp.137–142.

[32] C.-J. M. Liang, B. F. Karlsson, N. D. Lane, F. Zhao, J. Zhang,Z. Pan, Z. Li, and Y. Yu, “SIFT: Building an internet of safe things,”in Proceedings of the 14th International Conference on InformationProcessing in Sensor Networks. ACM, 2015, pp. 298–309.

[33] S. Raza, L. Wallgren, and T. Voigt, “SVELTE: Real-time intrusiondetection in the internet of things,” Ad Hoc Networks, vol. 11, no. 8,pp. 2661 – 2674, 2013.

[34] S. Gisdakis, T. Giannetsos, and P. Papadimitratos, “SHIELD: A dataverification framework for participatory sensing systems,” in Proceed-ings of the 8th ACM Conference on Security & Privacy in Wireless andMobile Networks, ser. WiSec ’15. ACM, 2015, pp. 16:1–16:12.

[35] F-Secure SENSE. [Online]. Available: https://sense.f-secure.com/[36] What are the current protection features for f-secure sense? [On-

line]. Available: https://community.f-secure.com/t5/F-Secure-SENSE/What-are-the-current-protection/ta-p/82972

[37] A. Kurtz, H. Gascon, T. Becker, K. Rieck, and F. Freiling, “Fingerprint-ing mobile devices using personalized configurations,” Proceedings onPrivacy Enhancing Technologies, vol. 1, pp. 4–19, 2016.

[38] H. Bojinov, Y. Michalevsky, G. Nakibly, and D. Boneh, “Mobile deviceidentification via sensor fingerprinting,” arXiv preprint:1408.1416, 2014.

[39] F. Bertini, R. Sharma, A. Iannı, and D. Montesi, “Profile resolutionacross multilayer networks through smartphone camera fingerprint,” in

Proceedings of the 19th International Database Engineering &#38;Applications Symposium, ser. IDEAS ’15. ACM, 2014, pp. 23–32.

[40] T. Van Goethem, W. Scheepers, D. Preuveneers, and W. Joosen,“Accelerometer-based device fingerprinting for multi-factor mobile au-thentication,” in Proceedings of the 8th International Symposium onEngineering Secure Software and Systems, ESSoS 2016. SpringerInternational Publishing, 2016, pp. 106–121.

[41] Y. Sharaf-Dabbagh and W. Saad, “On the authentication of devices inthe Internet of Things,” in Proceedinds of the 17th IEEE InternationalSymposium on A World of Wireless, Mobile and Multimedia Networks(WoWMoM). IEEE, 2016, pp. 1–3.

[42] I. Haider, M. Hoberl, and B. Rinner, “Trusted sensors for participatorysensing and iot applications based on physically unclonable functions,”in Proceedings of the 2Nd ACM International Workshop on IoT Privacy,Trust, and Security, ser. IoTPTS ’16. ACM, 2016, pp. 14–21.

[43] WiFi Alliance, WiFi Simple Configuration Technical Specification.