Computer Networks 148 (2019) 318–327

Contents lists available at ScienceDirect

Computer Networks

journal homepage: www.elsevier.com/locate/comnet

Towards automatic fingerprinting of IoT devices in the cyberspace

Kai Yang

a , c , Qiang Li b , ∗, Limin Sun

a , c

a Institute of Information Engineering, Chinese Academy of Sciences, China b School of Computer and Information Technology, Beijing Jiaotong University, China c School of Cyber Security, University of Chinese Academy of Sciences, China

a r t i c l e i n f o

Article history:

Received 5 August 2018

Revised 7 November 2018

Accepted 12 November 2018

Available online 14 November 2018

a b s t r a c t

Nowadays, the cyberspace consists of an increasing number of IoT devices, such as net-printers, webcams,

and routers. Illuminating the nature of online devices would provide insights into detecting potentially

vulnerable devices on the Internet. However, there is a lack of device discovery in large-scale due to the

massive number of device models (i.e., types, vendors, and products). In this paper, we propose an effi-

cient approach to generate fingerprints of IoT devices. We observe that device manufacturers have differ-

ent network system implementations on their products. We explore features spaces of IoT devices in three

network layers, including the network-layer, transport-layer, and application-layer. Utilizing the feature of

network protocols, we generate IoT device fingerprints based on neural network algorithms. Furthermore,

we implement the prototype system and conduct real experiments to validate the performance of device

fingerprints. Results show that our classification can generate device class labels with a 94% precision

and 95% recall. We use those device fingerprints to discover 15.3 million network-connected devices and

analyze their distribution characteristics in cyberspace.

© 2018 Elsevier B.V. All rights reserved.

r

n

e

v

b

o

t

t

g

p

o

m

s

p

f

t

a

b

t

I

i

1. Introduction

People connect Internet of Thing (IoT) devices to the Internet

for management and remote access. Typically, devices would either

use a public IP address or reside in a local network (e.g., enter-

prise and home networks). To our best knowledge, the cyberspace

is growing with 5.5 million new devices every day since 2016 and

will have reached nearly 20 billion by 2020 in the Gartner report

[1] . Meanwhile, online devices would bring security and manage-

ment problems, such as vulnerabilities and misconfiguration. For

instance, the Mirai [2] virus had infected nearly one million web-

cam devices that conducted an attack on the crucial infrastructure,

leading to Internet service disruption across the US and Europe [3] .

The device detection is a prerequisite step for protecting those on-

line devices in a proactive manner.

On the Internet, device detection requires pairs of input (re-

quest, response) and the classification method. We send query pack-

ets to a remote host, collect their response packets and use the

classification model to determine its device model. Prior works

focused on fingerprinting the OS of remote hosts. OS detection

depends on the differences among implementations of transport-

layer and network-layer, i.e., Nmap [4] uses 16 pairs of (request,

∗ corresponding author.

E-mail address: liqiang@bjtu.edu.cn (Q. Li).

v

s

I

https://doi.org/10.1016/j.comnet.2018.11.013

1389-1286/© 2018 Elsevier B.V. All rights reserved.

esponse) to detect OS versions. In contrast, device detection can-

ot utilize those features because the same OS may run on differ-

nt devices. Another challenge is that devices have different de-

ice types, vendors, and product models, leading to a large num-

er of class labels. Prior works used manual rules to discover

nline devices on the Internet, such as industrial control sys-

ems [5] , webcam devices [2] and other devices [6,7] . However,

he manual approach depends on researchers’ professional back-

round/experience, which is a long-term process. In this paper, we

ropose an efficient approach to generate device fingerprints based

n neural network algorithms.

To find device features, we leverage the observation that device

anufacturers have differences among the implementations of the

ame network software specification on their products. For exam-

le, products of the vendor “D-Link” are different from the ones

rom “Cisco” in the web-server implementation. We explore fea-

ures from three network layers: network layer, transport layer, and

pplication layer. Specifically, we analyze 20 typical protocols to

uild the feature space for IoT devices. Those features would iden-

ify both consumer IoT and cross-industry IoT devices. Consumer

oT devices refer to the context of consumer applications, i.e., res-

dential routers, network printers, and webcams. Industrial IoT de-

ices are used in industries such as manufacturing and industrial

ystems. We use 4 industrial control protocols for cross-industry

oT devices, including S7, Modbus, MOXA, and BACnet.

K. Yang, Q. Li and L. Sun / Computer Networks 148 (2019) 318–327 319

e

t

d

c

w

l

d

a

p

p

l

l

i

u

(

v

i

w

R

9

s

i

d

t

S

v

a

fi

a

S

2

d

i

2

m

s

m

i

i

c

t

w

v

s

Fig. 1. Examples of online device discovery.

p

a

q

i

e

p

T

o

e

i

t

f

f

o

v

t

o

2

d

p

f

f

T

c

i

l

w

e

f

g

3

t

3

v

l

a

f

n

t

p

a

d

v

Utilizing these features, we leverage neural networks to gen-

rate device fingerprints. One practical issue is that we lack the

raining data for neural networks. We utilize the observation that

evice manufacturers would list their product information on their

ommercial websites for distributing their products across the

orld. To collect the dataset, we use the regex to extract a class

abel of a packet and calibrate it by manual effort s. A three-level

evice label is proposed, including the device type, the vendors

nd the product. In the device-type layer, we obtain 41 labels for

resenting device types. In vendor layer, there are 1664 labels for

resenting device vendors. In the product layer, we obtain 12,880

abels for presenting device products. For instance, a device has a

abel “DVR Dahua X21A2E”, where “DVR” (Digital video recorder)

s device type, “Dahua” is a vendor name, and “X21A2E” is a prod-

ct name. Neural networks would learn the device fingerprints as

type, vendor, product) , which is a fine granularity label for IoT de-

ices.

Furthermore, we implement the prototype of the fingerprint-

ng system based on open source libraries. We conduct the real-

orld experiments evaluate the performance of device fingerprints.

esults show that our approach can achieve 94.7% precision and

5.0% recall in device classification. We also deploy the prototype

ystem in Amazon EC2 and discover over 15.3 million IoT devices

n the whole IPv4 space (nearly 4 billion). Furthermore, we provide

ata analysis about those IoT devices and illuminate their distribu-

ion in the cyberspace.

In brief, we make the following three contributions:

• We explore software implementation differences of the same

network specification among IoT devices and propose a finger-

print generation approach based on neural networks.

• We generate 12,880 device fingerprints in a fine granularity la-

bel, including device type, vendor, and product. Device finger-

prints would arrive a precision 94.7% and recall 95.0% at the

real-world experiment.

• We find more than 15.3 million IoT devices based on device fin-

gerprints and illuminate the distribution characteristics of IoT

devices.

The remainder of this paper is organized as follows.

ection 2 provides the background of fingerprinting IoT de-

ices. Section 3 describes the investigation of device features

nd Section 4 details the design of the classification model for

ngerprinting devices. Section 5 presents the experimental evalu-

tion of device fingerprints and the data analysis over IoT devices.

ection 6 surveys related work, and finally, Section 7 concludes.

. Background

In this section, we first describe the technical background of IoT

evice detection. Then, we present two challenges for fingerprint-

ng IoT devices.

.1. Device detection

The purpose of device detection is to determine whether a re-

ote host belongs to an IoT device. The device detection can bring

everal benefits to the research and industrial community, in both

anagement and security perspectives. First, device owners can

nventory the running devices in the network for finding leaked

nformation due to misconfiguration. Second, network researchers

an find running devices in the wild and quantify characteris-

ics of those devices in cyberspace. Third, network administrators

ould check for the existence of devices with vulnerabilities. De-

ices vulnerabilities are usually associated with the firmware ver-

ion provided by device vendors. Detecting devices (type, vendor,

roduct) would help build the link between compromised devices

nd known vulnerabilities.

Device detection contains three components, including (1) a

uery process, (2) a feature extraction process, and (3) a match-

ng process. Fig. 1 presents the example of online device discov-

ry based on fingerprinting. In the query process, a server sends a

acket to a remote host via an IP address and collects its response.

he host (101.231. ∗. ∗) would provide a set of response packets to

ur request packets, denoting as (request, response) . In the feature

xtraction process, the server would convert query/response pairs

nto feature sets as the input of the matching process. Specifically,

he query/response pair can be represented as the vector in the

eature space. In matching processing, the server is to classify a

eature vector into one of the k classes. Once matched, we can

btain the device label of the remote hosts, including their types,

endors, and products. Note that the interaction process between

he server and the remote host is a communication process with-

ut the help of the remote hosts.

.2. Challenges

As shown in Fig. 1 , there are two practical challenges about IoT

evice detection. In contrast to OS detection, IoT devices lack ex-

loration of the query process, i.e., which packet fits to find the

eature of device fingerprints. To address this issue, we explore

eatures of IoT devices from three network layers: Network layer,

ransport layer, and Application layer (seen Section 3 ). Another

hallenge is that machine learning algorithms need a lot of train-

ng data, particularly considering bias-variance tradeoff. We uti-

ize web crawler to obtain labels of devices from their commercial

ebsites, including type, vendor, and product. We use the regex to

xtract a class label of a packet and calibrate it by manual effort s

or collecting the dataset. Furthermore, we use neural networks to

enerate device fingerprints (seen Section 4 ).

. Investigating device features

In this section, we would explore what features could be ex-

racted from IoT devices.

.1. Overview

Fig. 3 describes the network software specification of IoT de-

ices, including the network layer, transport layer, and application

ayer. Features from the data link layer and physical layer are only

vailable in the local network. We explore features of IoT devices

or the device discovery at the Internet scale rather than the local

etwork. In the network layer, we investigate whether devices have

he differences among field values in IP packet header. In the trans-

ort layer, we analyze field values in the TCP/UDP packet header

mong different IoT devices. In the application layer, device ven-

ors usually write the different implementation of application ser-

ices into their products. We further explore 20 typical protocols

320 K. Yang, Q. Li and L. Sun / Computer Networks 148 (2019) 318–327

Table 1

Examples of field values of packet header among 5 IoT devices (Network and

Transport Layer).

Device name TOS(new) TTL DF MSS WIN OPT RTO

PLC SIEMENS 0 30 0 1460 64240 M 0.99

Printer Lexmark 0 254 1 1452 14600 M 3.10

Camera Linksys 192 65 0 – – – –

PLC Schneider 0 64 0 1380 5840 M 3.48

DVR Dahua 28 64 1 – – – –

Router Cisco 0 255 0 536 4128 M 1.97

Table 2

Protocols.

Category IOT devices Protocols

TCP-based HTTP, S7, SSH, TELNET, MODBUS,

FTP, ETHERNER/IP, FINS, RTSP

MELSEC-Q, PCWORK, GE_SRTP

UDP-based ONVIF, ECOM, MOXA NPORT, FINS,

HART-IP, BACNET, SNMP, UPNP

h

T

s

g

c

O

(

c

d

i

p

B

n

i

m

p

a

v

t

4

v

d

4

g

a

s

d

d

i

t

D

n

f

h

t

(

e

4

l

fi

i

v

g

v

d

e

o

including consumer IoT and cross-industry IoT devices. Below we

expand on the details of feature extraction in three layers.

3.1.1. Network layer analysis

Several tools (Nmap [4] and P0f [8] ) use the field of IP packet

header to extract features for OS fingerprints. Here, we conduct

real-world experiments to validate whether those fields work over

IoT device detection. We chose five typical IoT devices, including

“PLC SIEMENS”, “Printer Lexmark”, “Camera Linksys”, “DVR Dahua”,

and “Router Cisco”. The first device belongs to cross-industry IoT

device, and the last four devices belong to consumer IoT devices.

Table 1 lists the difference in 7 fields among those IoT devices.

The first three fields are extracted from IP packet header, including

the type of service field (TOS), time to live field (TTL) and don’t

segment fields (DF). We observe that devices have different values

across those fields, i.e.,“Camera Linksys” is 192 in TOS but “DVR

Dahua” is 28 in TOS. We add three fields into feature spaces for

fingerprinting IoT devices.

3.1.2. Transport layer analysis

We explore the fields of packets in the transport layer. We use

the same 5 IoT devices ( Table 1 ) to validate whether the field value

of packer header work as device features. There are two protocols

in the transport layer: TCP and UDP. They both contain a port field

of a packet header, which is used to present a specific applica-

tion protocol of the remote host. The port range is 1 − 2 16 , where

well-known ports are from 0 through 1023, registered ports are

from 1024 through 49,151 and dynamical ports are from 49,152

through 65535. We assume that the application protocol use the

default port, such as HTTP with 80, and FTP with 21. The last four

fields ( Table 1 ) are extracted from TCP packet header, including Re-

ceiver window field (WIN), RTO sequence (RTO), Max segment size

field (MSS) and TCP options field (OPT). We observe that IoT de-

vices have different values across those fields, i.e.,“PLC Schneider”

is 1380 in MSS but “PLC SIEMENS” is 1460 in MSS. We add three

fields into feature spaces for fingerprinting IoT devices.

3.1.3. Application layer analysis

OS detection does not use any feature from application proto-

cols because OS features rely on the different implementation of

the same TCP/IP specification. Device manufacturers would hard-

code their information into application services for their products.

Application protocols play a vital role in generating IoT device fin-

gerprints. Fig. 2 depicts three examples of IoT devices from two

application protocols. Fig. 2 (a) is a packet of HTTP from device “

Hikivision AR314-4”, where the device vendor is “Hikivision” and

its product model is “AR314-4”. Fig. 2 (b) is a device “ TP-Link

TLSC3230”, as the “TP-Link” vendor and “TLSC3230” product label.

Fig. 2 (c) is a packet of RTSP from the device “ TP-Link TLSC3230”.

In total, we analyze 20 application protocols for extracting de-

vice features, as listed in Table 2 . Based on TCP, we build a three-

way handshake and extract the header and payload of a response

packet. Based on UDP, we directly send a request packet and ex-

tract the header and payload of a response packet. When IoT de-

vices belong to consumer-oriented devices, those devices usually

ave a built-in Web, FTP, SSH, Real-time Media, Network Video,

ELNET user interfaces. When IoT devices belong to cross-industry

ystem devices, we choose typical ICS protocols for generating fin-

erprints, including Siemens (S7 protocol), Phoenix (PCWorx proto-

ol), MEL SEC (MEL SEC-Q protocol), Schneider (MODBUS protocol),

mron (FINS protocol), General Electric (GE_SRTP protocol), Moxa

MOXA NPORT), Tridium (FOX protocol). For general network-

onnected devices, we choose ETHERNET/IP (one of the leading in-

ustrial protocols which is widely used in a range of industries

ncluding factory, hybrid, and process), HART-IP (widely used in

rocess and instrumentation systems), and BACnet (widely used in

uilding Automation and Control networks), SNMP (widely used in

etwork management for network monitoring), UPnP (widely used

n network devices data sharing, communications, and entertain-

ent). We add the header and payload of every application-layer

acket into features of device fingerprints. The words, word orders

nd semantic would be extracted from those packets, acting as de-

ice features. We further use neural networks to identify those fea-

ures and learn device fingerprints (details in Section 4 ).

. Fingerprinting IoT devices

In this section, we first describe the overview of generating de-

ice fingerprints based on neural networks. Then we present the

etails of every component of the fingerprint generation.

.1. Architecture

Fig. 4 depicts the overview of the architecture about device fin-

erprints, including data annotation (DA), data preprocessing (DP)

nd neural network training (NNT). The DA utilizes web crawler to

crape vendor and product labels from commercial websites of IoT

evices. When a packet matches with the regex from lists of ven-

or and product labels, we would add it into the dataset and cal-

brate it by manual effort s. The DP would convert features of pro-

ocols into feature vectors as the input of the NNT. Specifically, the

P transforms fields of the header of TCP/UDP/IP packets into bi-

ary values. For application-layer data of the packets, the DP trans-

orms both the header and payload into binary values because they

ave the linguistic and semantic interpretation for IoT device fea-

ures. The NNT generates devices fingerprints within three levels:

type), (type, vendor) and (type, vendor, product). Below we would

xplicate on the details of three components.

.1.1. Data annotation

As mentioned earlier, the neural network algorithm requires a

arge amount of training data to learn device fingerprints. The DA

rst utilizes web crawler to obtain device annotations from exist-

ng commercial websites. Then, DA uses the regex to provide de-

ice labels to packets for collecting the dataset of the NNT.

Web crawler. We define the device fingerprint in three-level

ranularity: the device type, vendor, and product. Device types and

endors will keep fixed during a relative period. We use stable 67

evice types and 2228 vendors from Wikipedia. For product mod-

ls, we use web crawler to obtain them from commercial websites

f device vendors.

K. Yang, Q. Li and L. Sun / Computer Networks 148 (2019) 318–327 321

Fig. 2. Three examples of application-layer packets from IOT devices, including (a) Hikivision AR314-4 with HTTP, (b) TP-Link TLSC3230 with HTTP, and (c) TP-Link TLSC3230

with RTSP.

Fig. 3. The network protocols for exploring features of IoT devices.

Algorithm 1 The algorithm of accessing every URL in the com-

mercial websites.

Input: url _ list , t ype _ list

Output: database

1: function t ra v erse _ t ype ( url _ list , t ype _ list )

2: for each ur l ∈ ur l _ list do

3: T ype = find_type (url, type _ list)

4: F lag = devices_crawl (url, type )

5: end for

6: end function

b

d

o

t

A

l

W

p

f

r

w

v

Algorithm 2 The Algorithm of product label collection.

Input: url, type

Output: database

1: function de v ices _ crawl ( url , type )

2: response = send (url)

3: Pattern _ brand = “ di v [ id = “ J _ BrandAl l ”] ”

4: brand _ list = find_brand (Pattern _ brand)

5: Pat tern _ product s = “ di v [ class = “ pro − intro ”] ”

6: product _ crawl s = find_products (Pattern _ model )

7: for each item _ crawl ∈ product _ crawls do

8: Pattern _ product = “[ h 3] [ a hre f ] ”

9: product = find (item _ crawl, Pattern _ product)

10: brand = match (product, brand _ list)

11: product _ model = split (product , brand _ list )

12: insert_into_database (type )

13: insert_into_database (brand)

14: insert_into_database (product _ model)

15: end for

16: Patter n _ ur l = “ class : [ next] ”

17: next _ urls = url (Pattern _ url , response )

18: de v ices _ crawl (url )

19: end function

b

t

d

t

c

c

i

e

F

]

a

t

Algorithms 1 and 2 depict the web crawler obtains product la-

els from vendor websites. We store the list of URLs of device ven-

ors, and resolve webpages for the product description. The inputs

f Algorithm 1 are “url_list” and “type_list”. The web crawler ob-

ain every webpage URL in the function devices_crawl , as listed in

lgorithm 2 . The function devices_crawl is used to extract product

abel information from webpages. We add them into the database.

e use “Pattern_brand” to extract vendor information from web-

ages. We use “Pattern_products” to extract product information

rom webpages, and provide “product” labels if it matches the

egex of vendor strings. We add labels into the database. In totally,

e use the web crawler to gather 67 device types, 2228 device

endors, and 64,532 product labels.

Fig. 4. The overview of the architect

Data labeling. We utilize a two-stage approach to provide a la-

el to a packet based on the collection data. First, we use the regex

o extract a class label of a packet and add it into the training

ataset. Second, we manually remove the unqualified packets in

he dataset.

The matching process of the regex is elaborated below. We first

onvert the packet payload into lower case characters without the

ase-sensitive. For device type and vendor labels, the string match-

ng is strict. For instance, a packet contains “dahua” and “cam-

ra”, and we provide the tuple (camera, Dahua) to this packet.

or product labels, we use the regex “[a–z]+[–]?[a–z!] ∗[0–9]+[-]?[-

?[a–z0–9]” to identify whether the packet contains product char-

cters. We extract these matching strings and check them against

he list of collective product labels. Once matched, we provide a

ure about device fingerprints.

322 K. Yang, Q. Li and L. Sun / Computer Networks 148 (2019) 318–327

Fig. 5. Multi-port of IoT devices for collecting device labels.

c

t

C

fi

3

t

s

s

t

z

i

a

4

p

e

l

l

t

G

s

s

β

w

h

t

t

t

m

q

a

(

t

ω

w

s

t

t

a

t

Z

w

v

o

a

a

c

C

w

p

v

a

w

n

Q

label (type, vendor, product) to a packet. We conduct the matching

process over 11 million packets, including 20 application protocols

in Table 2 . Totally, we obtain 814,582 packets within the regex, in-

cluding 41 device types, 1664 vendor labels, and 12,880 product

labels.

We further manually remove the wrong labels of packets. The

rule is simple: we directly remove packets that come from device-

sale/advertising/aggregation websites; we remove the packets that

obviously not belong to IoT devices by human observation. The

first filtering step (device-sale/advertising/aggregation websites)

and the manual filtering step are conducted together. When pack-

ets come from commercial websites, the packet header contains

a heavyweight web framework, e.g., Apache or Tomcat. IoT de-

vices do not contain that heavyweight built-in server due to the

limitation of resources. We remove unqualified packets within the

heavyweight server. For remaining packets, we leverage an obser-

vation: many IoT devices use login scripts or the configuration pa-

rameters for user authorization. We remove unqualified packets

when they only contain the textual description. After the manual

filtering, we remove 124,156 packets and keep 690,426 packets for

the training data of neural networks.

Note that the labeling process only provides a small part of the

dataset, compared with the whole IoT devices. Neural networks

would generate device fingerprints, which can be seamlessly used

to discover IoT devices in the large-scale. The number of packets

with labels is much smaller than the number of packets without

labels. If we directly use the regex to identify devices, we will

miss most packets from devices. Neural networks would extract

distinct characters, more than characters in the regex ( Section 5.4

finds 15.3 million IoT devices). Furthermore, we leverage the fact

that devices usually open multi-ports for simultaneously hosting

several services. For example, ( Fig. 5 ) port2 of an devices indicate

it’s “TP-LINK/TLSC3230” and “TP-LINK/TLSC3230” is an IP camera

in our Devices classes database, so we set “Label A” as “IP camera

TP-LINK TLSC3230” and annotate port1, port2, and port3 with it.

We provide the same label to the packet pair from the other ports

of the same IP host.

4.1.2. Data preprocessing

In this module, we convert raw response packets into the fea-

ture vector as the input of neural networks.

TCP/UDP/IP fields. We extract TOS fields, TTL fields, DF fields

from Internet layer and Port field, Win-field, RTO, MSS field, OPT

field from Transport layer. As for UDP-based protocols, we only

leverage port fields and set the other value zero. We provide the

port field a float number from 0 to 1 corresponding to the proto-

col ID and transform the other field value from a decimal number

to binary. For example, if the TTL value is 64, we change it into

binary with 010 0 0 0 0 0. The size of the feature vector (TCP/UDP/IP)

is 400, as the input of neural networks.

Application-layer packets. The values in application-layer pack-

ets have two formats, including plaintexts and binary values. We

hange binary values to plaintexts by reading the field’s value of

he corresponding protocol. For example, If we send the “Read SZL

omponent” request to Siemens s7, it would return a packet with a

eld indicating its system name in hexadecimal which starts from

9 bytes of the application-layer data. Hence, we contextualized

hese messages into plain text based on the value of the corre-

ponding field. For plain text, we would extract their words and

ort all words by frequency. We tokenize [9] each word to give

hem an integer id starting from zero. We pad each sequence with

ero to align them. We just choose the top 30,0 0 0 words as the

nput of the neural network, which would identify their semantic

nd sequence relationships.

.1.3. Neural network classification

The neural network generates device fingerprints which would

rovide the class label of the IoT device. In the neural network,

ach neuron would extract the fine-grained features from three

ayers, including network-layer, transport-layer, and application-

ayer. Every layer has a different dimension vector with different

ypes of neuron.

To extract the semantic relationship of words, we would use the

love [10] to represent the words in feature vector. In Glove, the

ynonyms would be closed in the vector space. Our Glove vector is

hown as follows:

= α[x 1 , x 2 , x 3 , · · · , x i , · · · , x n

](1)

here α is the matrix derived from Glove, x i is the i th word’s one-

ot encoding of the digital the header and the payload of applica-

ion layer data. β is application layer data vectors.

Furthermore, we utilize Long Short-Term Memory (LSTM) to ex-

ract semantic meaning from the Glove vector, which would iden-

ify sequential relationship among words. For example, “equip-

ent” are behind “original” and “Siemens”. To obtain backward se-

uential relationship among words, we would use LSTM to conduct

bi-directional scan of the sequence. After the bi-directional LSTM

Bi-LSTM) process, we obtain a high dimension feature vector from

he original Glove vector, as follows:

= θ[ −−−→

LST M ( β) , ←−−−LST M ( β)

] (2)

here the −−−→

LST M is a forward scan of words, ←−−−LST M is a backward

can of words, and θ is a concatenate function which concatenates

he Glove vector into a higher dimension vectors.

Then, we extract the features of vector ω and identify the dis-

inct feature. We split the vector matrix into a series of vectors,

dd their weights and offsets. We use function tanh to pick out

he maximum of them, as follows:

= max 1 ≤i ≤n

[ tanh ( κi ω i + b i ) ] (3)

here the tanh is a activation function to map the vector into the

alue space [ −1,1], κ i is the weight of the i th vector and b i is the

ffset of the i th vector.

We would merge the Z and other features from network-layer

nd transport-layer. We transform the TOS, TTL, DF, Win, RTO, MSS

nd OPT value into binary, and convert them into the vector. We

oncatenate the Z with those features, as follows

= θ(Z, M tos , M t t l , M df , M win , M rto , M mss , M opt

)(4)

here the θ is a concatenate function which concatenates the in-

ut value into new vectors, M tos , M ttl , M df represent the binary

alue of the TOS field, TTL field, df field, Win field, RTO, MSS field

nd OPT field.

Protocol represents the open service of the device. Feature C

ould be practicable only if their service is running. We use the

ew dimension of vector to represent the protocol, as follows:

= σ(C, M protocol

)(5)

K. Yang, Q. Li and L. Sun / Computer Networks 148 (2019) 318–327 323

w

i

p

f

t

f

P

T

w

t

p

o

i

Y

T

r

p

g

e

i

s

4

t

d

s

a

f

M

t

h

p

W

t

c

t

o

d

t

d

[

v

u

l

r

p

h

2

t

w

d

Fig. 6. The distribution for port usage for obtaining response packets from 20 pro-

tocols.

5

p

t

v

v

5

[

o

U

w

(

p

t

p

2

p

a

s

o

m

(

5

c

w

d

p

g

fi

i

a

p

e

3

a

W

d

here σ is an increasing dimension function which merges input

nto different dimensions, and M protocol represent the float id of the

rotocols from 0 to 1.

Finally, we leverage multiple convolutional layers to screen each

eature vector to extract the fine-grained features. Each convolu-

ional neuron processes data for its receptive field. We use the tanh

unction to activate each layer.

(k ) =

n ∑

i =0

h (k − i ) Q(i ) (6)

= tanh (P ) (7)

here the k stands for the k th filter, h stands for the weight of fil-

er. To derive the final classifier from the features, we would max-

ool the features and flatten them. We put the weight and offset

n each feature and use softmax function to generate the possibil-

ty of the vector on each class.

= W ∗ �maxpool ing& f l atten (T ) + B (8)

p k =

exp(y k ) ∑ n i =0 exp(y i )

(9)

he W stands for weight and B stand for offset, �maxpool ing& f l atten

epresent the max-pooling and flattening operations. p k is the final

ossibility of the corresponding class.

Device fingerprints. The neural network generates device fin-

erprints in a three-level classifier: type, vendor, and product. For

xample, we can leverage the type classifier to classify a device

nto its type (eg., IP camera). If we want to know its vendor we

hould retrain the sample in its vendor (eg., IP camera) classifier.

.1.4. Discussion

Here, we describe the limitation of fingerprinting IoT devices in

he cyberspace.

Device ports. As aforementioned, we send request packets to

efault ports of remote hosts for collecting response packets. In-

tead of default ports, device users may use a different port to host

n application-layer service. For instance, the port 502 is the de-

ault port of Modbus, but devices may use the port 65,530 to host

odbus service. It is an ethical issue that we use port scanning

o collect response packets of devices, which is an adversarial be-

avior. Particularly, Moving Target Defense (MTD) would defeat the

ort scanning through creating the different hosting environment.

e would miss some services during response packet collection if

he default port is not used.

Dynamic labels. We utilize the features from the network spe-

ific implementation of IoT devices and derive the classifier for

he device label. Those features are embedded in the firmware

f devices. An inevitable fact is that device vendors would up-

ate their product firmware because they may fix bugs, add fea-

ures, or improve performance [11] . Furthermore, new device ven-

ors and products would also affect the classifier performance. ARE

12] would automatically update labels of network-connected de-

ices through searching their banners in the search engine. We can

tilize the ARE to collect the newest labels and training dataset for

earning device fingerprints through neural networks.

Limited view. Many devices are residing in the local network

ather than the Internet. Our data annotation would lack those

ackets if those devices only reside in the local network. We

ave crawled device annotations from websites, including 67 types,

228 vendors, and 64,532 products. However, we only provided 41

ypes, 1664 vendor, and 12,880 product labels for our neural net-

ork algorithms. Our classification cannot generate the remaining

evice fingerprints due to the lack of a training dataset.

. Evaluation

In this section, we first present the data collection for finger-

rinting IoT devices. Then, we describe the prototype system and

he real-world experiment to validate the performance of the de-

ice fingerprint. Finally, we provide the data analysis about IoT de-

ices on the Internet.

.1. Data collection

To collect packets on the Internet, we have re-used Zmap tool

13] to scan IPv4 space. We have deployed data collection servers

n multiple cloud computing servers, Amazon EC2, which are

buntu 16.04 with 2 vCPU and 8GB of memory, 240Mbps band-

idth, 500GB hard disk. There are nearly 4 billion IPv4 addresses

2 32 ), where many of them are researchable and visible for the

ublic. For 20 application-layer protocols, we used the default port

o send request packets. Specifically, we totally use 39 ports for 20

rotocols, where HTTP uses 15 ports, RTSP uses 3 ports, Telnet uses

ports, CODESYS uses 2 ports, HART-IP uses 2 ports, and other

rotocols use one port. Fig. 6 presents the distribution of port us-

ge for obtaining response data of 20 protocols. It is an ethical is-

ue that we use the port scanning (2 16 ) to collect response packets

f devices, which is an adversarial behavior. In total, we collect 96

illion packets from the IPv4 space and store them in the format

IP, protocol, port, packet) .

.2. System implementation

We pull the dataset from Amazon and store the dataset in lo-

al clusters with 27 TB a hard disk. We use the Scrapy frame-

ork to scrape webpages from commercial websites of device ven-

ors. Totally, we obtain 41 device types, 1664 vendors, and 12,880

roducts. We use Keras [9] to implement neural network layer for

enerating device fingerprints. Neural networks learn the device

ngerprints on two NVIDIA Tesla K80 graphics cards. The graph-

cs cards are on the server with two Intel Xeon CPU E5-2650 v4

nd 256GB 2400Mhz memory chips. The dataset contains 690,426

ackets within 41 types, 1664 vendors, and 12,880 products. Ev-

ry packet would be converted into the feature vector with the

0,40 0 sizes (40 0 in TCP/UDP/IP packet headers and 30,0 0 0 in the

pplication-layer packet header) as the input of neural networks.

e use the tuple as (IP, label) to present the annotation of the IoT

evice.

324 K. Yang, Q. Li and L. Sun / Computer Networks 148 (2019) 318–327

Table 3

Precision and coverage of device fingerprints.

Granularity Precision Recall

(type, – , –) 94.7% 95.0%

(type, vendor, –) 93.3% 93.8%

(type, vendor, product) 91.4% 92.0%

Fig. 7. The performance of the device type.

Fig. 8. The performance of the device vendor in the (webcam, –, –).

Fig. 9. The performance of the device product in the (router, TP-Link, –).

Table 4

The number of IoT devices from the Internet-wide

measurement.

Granularity Number of IoT devices

(type, – , –) 15.3 million

(type, vendor, –) 13 million

(type, vendor, product) 1.8 million

5

5

A

1

o

–

1

c

i

5

I

v

t

2

s

i

r

5.3. Experimental results

We split the dataset by 8:1:1, including the training set, validat-

ing set and testing set, respectively. We evaluate the performance

of device fingerprints through using two metrics: precision and re-

call. The precision is equal to TP / ( FP + TP ), and the coverage (recall)

is TP / ( TP + FN ). The TP is the true positive number, FP is the false

positive number, and FN is the false negative number. Table 3 lists

the precision and recall of three-level granularity of device finger-

prints. On average, the precision achieves at 94.7% at device type

level, 93.3% at the vendor level, and 91.4% at the product level. For

the coverage of device fingerprints, the product recognition also

reaches 92%. Below we show the details of the performance in

three granularity classifiers.

Fig. 7 show the performance of the fingerprint of the device

type, where the red point represents an IoT device type. The X-axis

is the precision, and Y-axis indicates the recall. We observe that

two device types (“printer” and “scanner”) have lowest precision

and recall. The reason is that many IoT devices have both print-

ing and scanning capabilities, leading the overlap between packets

from “printer” and those from “scanner”. For example, the device

“Fuji Xerox CM305” can be divided into “printer” type and “scan-

ner” type. The overlap function may lead to the performance de-

crease of device fingerprints.

Fig. 8 depicts the performance of the fingerprint of the device

vendor, where the red point represents a webcam vendor. “Hikivi-

sion”, “Sony” and “Dahua” have highest precision and recall values,

compared with others. “ACTI” has the lowest precision and recall

values. It is because the information embedded by device vendors

overlaps with others, leading to the decreased performance. Fig. 9

presents the performance of the product fingerprint in the (router,

TP-Link, –). Each point represents the performance of one prod-

ucts model, where X-axis is the precision, and Y-axis is the recall.

When the device type is the router and the vendor is the corpora-

tion “TP-Link”, the highest precision is 99% and the highest recall

is 99.6%. Some product fingerprints decrease quickly because of the

high overlap degree of similar device products. In brief, our device

fingerprints would detect IoT devices in the cyberspace.

.4. Understanding IoT devices

.4.1. Landscape

We provide characteristics of IoT devices on the Internet.

mong 96 million packets from the IPv4 space, we find more than

5.3 million IoT devices. Table 4 lists the overview of the number

f IoT devices with labels. 15.3 million IoT devices have the (type,

, –) label, 13 million devices have the (type, vendor, –) label, and

.8 million devices have the (type, vendor, product) label. In the se-

urity perspective, it is necessary to provide a better security pol-

cy for those devices.

.4.2. Composition

We would analyze the device composition in the 15.3 million

oT devices. Table 5 lists the top 10 device types and top 10 de-

ice vendors. The router is the most popular device type, more

han 10 million. The switch is the second largest device type with

.13 million. Residential/corporation users would deploy routers or

witches to join the Internet, where most of the devices are hid-

ng behind the router, switch or gateway. However, digital video

ecorder and IP camera devices should not be exposed to the pub-

K. Yang, Q. Li and L. Sun / Computer Networks 148 (2019) 318–327 325

Table 5

The distribution of device type and vendor.

Device type Number Vendor Number

Router 10,678,946 Cisco 1,543,614

Switch 2,137,142 Mikrotik 1,432,576

Digital video 1,101,455 TP-Link 1,340,466

Recorder

IP Camera 529,658 FAST 611,990

Printer 395,460 ZTE 607,171

Gateway 109,456 Hikivision 581,751

Programmable 79,538 Ubiquoss 454,228

Logic Controller

Firewall 75,771 D-Link 406,933

Modem 58,367 Netgear 388,360

IP Television 21,492 Xiongmai 295,576

Table 6

Geographic distribution of IoT devices.

Country Number Country Number

United States 3,899,306 Japan 393,748

China 1,407,553 Italy 295,424

Great Britain 1,024,317 Mexico 295,424

Germany 753,771 Canada 261,446

Russia 578,704 Argentina 254,841

Korea 557,697 Netherlands 233,178

Brazil 439,219 Taiwan 232,337

Australia 432,273 Hong Kong 212,349

France 399,487 India 203,878

l

a

l

t

g

t

w

v

t

a

o

o

v

t

s

m

5

v

m

c

1

t

C

o

5

p

c

l

w

p

o

l

d

Fig. 10. The CDF of the number of device labels.

Fig. 11. The distribution of device types with multi-labels.

a

w

n

,

W

v

(

b

T

p

I

p

6

p

c

W

o

6

i

d

fi

d

[

w

m

H

(

f

ic, more than 1.6 million. Mirai [3] targeted this device type and

ttacked the network infrastructure in Oct. 2016. A programmable

ogic controller (PLC) is usually used in an industrial control sys-

em, which are infrastructure-critical systems such as smart grid,

as pipelines, and water distribution. These devices should be bet-

er protected by the security mechanism. Directly exposing PLC

ould cause much attention from malicious users and hackers.

We observe that there is a typical long tail distribution of de-

ice vendors, listed by Table 5 . Compared with the uniform dis-

ribution, a well-known vendor dominates the market, leading to

long tail distribution. The Cisco vendor has the largest number

f visible IoT devices, more than 1.5 million. Mikrotik has the sec-

nd largest number of IoT device with 1.4 million. Note that de-

ice vendors may manufacture multiple device types for expanding

he market. For instance, Cisco is distributing and selling routers,

witches, gateways, and modems. The long-tail distribution is com-

on for IoT devices, including device types, vendors, and products.

.4.3. Geographical distribution

We want to characterize the geographical distribution of IoT de-

ices across the world. We use the MaxMind GeoIP database to

ap between IP address and their locations, which obtains the

ountry/city level information of IoT devices. Table 6 lists the top

8 countries ranking by the number of IoT devices. The U.S. con-

ains the largest number of IoT devices, more than 3.8 million.

hina is the second largest number of devices with 1.4 million. We

bserve that the device location still has a long-tail distribution.

.4.4. Multi-labels

Furthermore, we observe that many IP addresses have multi-

le labels of IoT devices, indicating that one IP address is asso-

iated with more than one device label. Among those 15.3 mil-

ion IoT devices, there are nearly 75,052 IP addresses are binding

ith 169,460 device labels, which we called the multi-label. Fig. 10

resents the cumulative distribution function (CDF) of the number

f device labels per IP address. Note that the number of the device

abel ranges from 2 to 10. 79.9% IP addresses have more than two

evice labels. When the number of the device label is 6, the cover-

ge is up to 99.9%. We further plot the distribution of device types

ith multi-labels, as shown in Fig. 11 . The router has the largest

umber at 75,052, which every IP address has the label (router, –

–). The DVR has the second largest number, nearly 18,024, and

ebcam device has the third number. We suppose that those de-

ices with multi-labels may belong to Network address translation

NAT), which is a method of mapping one IP address into another

y revising the IP header of packets when packets pass the router.

he reason is that every device has a label (router, –, –), com-

anying with other labels (i.e., DVR, webcam, and printer). One

nternet-roundtable address of a NAT router can present an entire

rivate network.

. Related work

The pervasiveness of IoT devices, ranging from camera, router,

rinter to various home automation, industrial control, and medi-

al systems, stimulates much interest to the research community.

e present the related work in two categories: fingerprinting and

nline detection.

.1. Fingerprinting

Fingerprinting technology has been used for more than 20 years

n network security, which identifies a remote host based on the

ifferent im plementations of the same software specification. OS

ngerprinting utilize features from the header of TCP/IP packets to

etect OS versions of remote hosts. Several tools (Nmap [4] , P0f

8] , and Xprobe [14] ) extract features from packet header (e.g., TCP

indow size, MMS, options) for OS fingerprints, which perform a

atching (either approximate or strict) with existing OS classes.

ershel [15] was the first work to utilize different time latency

TCP retransmission timeout) between online hosts and the server

or fingerprinting OS. However, the RTOs would suffer network

326 K. Yang, Q. Li and L. Sun / Computer Networks 148 (2019) 318–327

7

t

p

d

o

p

c

p

W

v

c

I

a

d

v

t

a

n

v

w

v

A

m

p

a

R

volatility, such as network jitter, packet loss, and network topology.

In contrast, our work is to detect IoT devices rather than identify-

ing OS versions. We cannot utilize an OS fingerprinting technique

to identify IoT devices because the same OS may run on different

devices.

Shamsi et al. [16] collected 67.6 million response packets from

2.8 billion IPv4 hosts and provided OS labels to 93% hosts. They

manually built the mapping relationship between OS labels and

device types. However, the fingerprinting granularity is the level of

device type. Differing from their work, we can generate IoT device

fingerprints at a fine-grained granularity, including the device type,

vendor, and product. Feng et al. [12] proposed the generation for

fingerprinting IoT devices. They extracted the banners from packets

and searched them in commercial search engine. If the search re-

sults contain the device label, they provided it to the packet. How-

ever, they assumed that the payload of packets would contain the

hardcoded information of device products, which is currently un-

clear for all application-layer protocols. In contrast, our work lever-

ages neural networks to extract non-obvious features to generating

device fingerprints. Although the training data collection requires

some human involvements, our device fingerprints would detect

IoT devices consisting of most popular application-layer protocols.

6.2. Online detection

Online detection is a host-independent approach which we can

find hosts without their help. Online discovery can be divided into

two categories: passive and active. The passive discovery method

is to collect the traffic without sending any request packet. Active

discovery is to send request packets to remote hosts and collect

their response packets. Prior active discovery mainly focused on re-

ducing the reconnaissance time due to the whole IP space having

nearly 4 billion addresses. Heidemann et al. [17] first utilized active

discovery to collect live hosts across the whole IP space, which cost

nearly 1 month, and Leonard et al. [18] implemented IRLscanner

which reduced the time to 1 day. Durumeric et al. [13] proposed

one stateless packet and implemented Zmap which can detect 4

billion addresses within 1h. Active discovery is a prerequisite step

to detect online IoT devices in the network. Our work re-utilizes

active discovery to collect packets of live host and uses the device

fingerprint to detect IoT devices.

For local networks, several prior works [19–22] proposed to de-

tect IoT devices. Kohno et al. [19] utilized clock skew to generate

individual device fingerprints because of hardware implementation

differences. Miettinen et al. [20] proposed to discover device types

for identifying ones with potential security vulnerabilities. Meidan

et al. [21] used random forest to extract features of device types

from network traffic data, including 9 device types and 17 indi-

vidual devices. Differing from these previous works, we focus on

detecting remote devices at the Internet-scale and find 15.3 million

IoT devices. If hardcoded information remains stable with time, our

approach can be directly applied in local networks without any

modification.

At Internet-wide scale, Shodan [6] and Censys [7] are well-

known search engines for detecting network-connected devices.

Shodan [6] is a commercial search engine and used Nmap to detect

online devices. Users can find Internet-connected devices through

a keyword query on Shodan. Censys [7] is an open-source search

engine that collects application-layer responses and users can di-

rectly access its dataset. Censys identifies online devices based on

Ztag [23] , similar to the Nmap tool, which requires developers to

write matching rules for IoT devices. Shodan and Censys are both

manual processes for fingerprinting IoT devices, often arduous and

incomplete, making it difficult to keep up-to-date with new device

models. In contrast, our work generates device fingerprints based

on neural networks.

. Conclusion and future work

The number of IoT devices is rapidly increasing and many of

hem are visible and reachable by public IP addresses. In this pa-

er, we propose a fingerprint generation approach for detecting IoT

evices in cyberspace. We first explored different implementations

f the same system specification among IoT devices in three-layer

rotocols, including the network layer, transport layer, and appli-

ation layer. We used neural networks to generate device finger-

rints, covering 41 types, 1664 vendors, and 12,880 product labels.

e conducted real experiments to evaluate the performance of de-

ice fingerprints, and results show that device fingerprints are ac-

epted in practice. Furthermore, we analyze those characteristics of

oT devices identified by fingerprints: over 15.3 million devices and

typical long-tail distribution.

In future work, we would consider some applications to

emonstrate the effects of device fingerprints. For instance, IoT de-

ices are compromised to conduct an attack in cyberspace. Our

echnique can detect the device label and provide a comprehensive

nalysis of the composition of those compromised devices. Vul-

erabilities on devices are usually associated with their firmware

ersion which is provided by device vendors. Device fingerprints

ould build the relationships between vulnerabilities and IoT de-

ices.

cknowledgments

We are grateful to our shepherd Samuel Marchal and anony-

ous reviewers for their insightful feedback. This work was sup-

orted by National Key R&D Program of China (2017YFB0802804),

nd National Natural Science Foundation of China ( 61602029 ).

eferences

[1] 20.8 Billion IoT Devices by 2020, https://www.gartner.com/newsroom/id/

3598917 . [2] M. Antonakakis , T. April , M. Bailey , M. Bernhard , E. Bursztein , J. Cochran , Z. Du-

rumeric , J.A. Halderman , L. Invernizzi , M. Kallitsis , Understanding the Miraibotnet, in: USENIX Security Symposium, 2017, pp. 1092–1110 .

[3] Major Cyber Attack Disrupts Internet Service Across Europe and US,2016. [Online], Available: https://www.theguardian.com/technology/2016/oct/

21/ddos- attack- dyn- internet- denial- service .

[4] Nmap, Network Secursity Scanner Tool., 2012. [online]. Available: https://nmap.org/ .

[5] C. Fachkha , E. Bou-Harb , A. Keliris , N. Memon , M. Ahamad , Internet-scale prob-ing of cps: inference, characterization and orchestration analysis, in: Proceed-

ings of NDSS, vol. 17, 2017 . [6] Shodan. the Search Engine for Internet-Connected Devices. [online]. Available:

https://www:shodan:io/ .

[7] Z. Durumeric , D. Adrian , A. Mirian , M. Bailey , J.A. Halderman , A search en-gine backed by internet-wide scanning, in: Proceedings of the 22nd ACM

SIGSAC Conference on Computer and Communications Security, ACM, 2015,pp. 542–553 .

[8] M. Zalewski, p0f v3: Passive Fingerprinter. [online], 2012 . Available: http://lcamtuf.coredump.cx/p0f3 .

[9] keras. A Netual Network Api. [online]. Available: https://keras.io/ .

[10] J. Pennington , R. Socher , C. Manning , Glove: global vectors for word represen-tation, in: Proceedings of the 2014 Conference on Empirical Methods in Natu-

ral Language Processing (EMNLP), 2014, pp. 1532–1543 . [11] Q. Li , X. Feng , H. Wang , Z. Li , L. Sun , Towards fine-grained fingerprinting of

firmware in online embedded devices, in: IEEE International Conference onComputer Communications, INFOCOM, 2018 .

[12] X. Feng , Q. Li , H. Wang , L. Sun , Acquisitional rule-based engine for discover-

ing internet-of-things devices, in: 27th USENIX Security Symposium (USENIXSecurity 18), USENIX Association, 2018, pp. 327–341 .

[13] Z. Durumeric , E. Wustrow , J.A. Halderman , Zmap: fast internet-wide scan-ning and its security applications, in: Usenix Conference on Security, 2013,

pp. 605–620 . [14] F.V. Yarochkin , O. Arkin , M. Kydyraliev , S.Y. Dai , Y. Huang , S.Y. Kuo , Xprobe2 ++ :

low volume remote network information gathering tool, in: Dependable Sys-tems & Networks, 2009. DSN’09. IEEE/IFIP International Conference on, IEEE,

2009, pp. 205–210 .

[15] Z. Shamsi , A. Nandwani , D. Leonard , D. Loguinov , Hershel: single-packet os fin-gerprinting, IEEE/ACM Trans. Netw. 24 (4) (2016) 2196–2209 .

[16] Z. Shamsi , D.B.H. Cline , D. Loguinov , Faulds: a non-parametric iterative clas-sifier for internet-wide os fingerprinting, in: ACM Sigsac Conference on Com-

puter and Communications Security, 2017, pp. 971–982 .

K. Yang, Q. Li and L. Sun / Computer Networks 148 (2019) 318–327 327

[

[

[

[17] J. Heidemann , Y. Pradkin , R. Govindan , C. Papadopoulos , G. Bartlett , J. Bannis-ter , Census and survey of the visible internet, in: Proceedings of the 8th ACM

SIGCOMM conference on Internet measurement, ACM, 2008, pp. 169–182 . [18] D. Leonard , D. Loguinov , Demystifying service discovery: implementing an in-

ternet-wide scanner, in: Proceedings of the 10th ACM SIGCOMM conference onInternet measurement, ACM, 2010, pp. 109–122 .

[19] T. Kohno , A. Broido , K.C. Claffy , Remote physical device fingerprinting, IEEETrans. Depend. Secure Comput. 2 (2) (2005) 93–108 .

20] M. Miettinen , S. Marchal , I. Hafeez , N. Asokan , A.R. Sadeghi , S. Tarkoma , Iot

sentinel: automated device-type identification for security enforcement in iot,in: Distributed Computing Systems (ICDCS), 2017 IEEE 37th International Con-

ference on, IEEE, 2017, pp. 2177–2184 . [21] Y. Meidan, M. Bohadana, A. Shabtai, M. Ochoa, N.O. Tippenhauer, J.D. Guarnizo,

Y. Elovici, Detection of unauthorized IoT devices using machine learning tech-niques, 2017. ArXiv preprint. arXiv: 1709.04647 .

22] T.D. Nguyen, S. Marchal, M. Miettinen, M.H. Dang, N. Asokan, A.R. Sadeghi, D \ ”iot: a crowdsourced self-learning approach for detecting compromised IoT de-vices, 2018. ArXiv preprint. arXiv: 1804.07474 .

23] ZTag, An Utility for Annotating Raw Scan Data with Additional Metadata. http://github.com/zmap/ztag .

Kai Yang recieved the B.E. in Shandong University, Chinain 2016, and is currently perusing the Ph.D. degree in In-

stitute of Information Engineering, Chinese Academy ofSciences, China. His researsh interests include the secu-

rity of Internet of Things, Network protocols and Internetmeasurement.

Qiang Li received the Ph.D. degree in computer science

from University of Chinese Academy of Sciences in 2015.Currently, he is an assistant professor in the School of

Computer and Information Technology, Beijing Jiaotong University, China. His research interests revolve around

Mobile computing and Internet of Things. He would like

to build prototype systems based on well-founded com-putational models.

Limin Sun is a professor in the Institute of InformationEngineering at Chinese Academy of Sciences (CAS). He

is an editor of Journal of Computer Science and Journalcomputer Applications. He is also a guest editor of special

issues in EURASIP, Journal of Wireless Communications

and Networking,and Journal of Networks, respectively. Hisresearch interests include mobile vehicle networks, delay-

tolerant networks, wireless sensor networks, mobile IP,and technologies for next generation of Internet.