IoT and

 embedded  
systems   security
Abdelkader Lahmadi
Associate  professor,  Université de  Lorraine,  ENSEM,  Nancy
[email protected]
Course  outline
• First  day
• IoT and  embedded  systems  (1  hour)
• Consumer   and  industrial  IoT
• Hardware  and  software   architectures
• M2M  communication  protocols  (2  hour)
• Z-­‐Wave  protocol
• BLE   protocol
• 802.15.4  and  6LoWPAN  protocols
• Communication  protocols  analysis:  BLE  and  ZWave (2  hour)
• BLE   Packets   sniffing   using   uberthooth
• Z-­‐wave  Packets   sniffing   using   GNU  Radio   and   scapy
• Second  day
• IoT attacks  and  threats  (2  hour)
• Case   studies
• Lab  session  :  security  analysis  of  a  smart  plug  (3  hours)
• Ports  scanning  
• Extract   and  analyze a   device   firmware
 Internet
Internet   of  of Things
Things   (IoT)(IoT)
Internet
nternet of
ofthing
◆  The next big
Things
Things (IoT)
is small (IoT)
Internet
The– next
Low-power
is small …) (IoT)
of
Motes
big thing
e next STM32xx, Things
(TI MSP430, SensorTAG,
is small
big thing ARM-based,
–  Low-power Motes (TI MSP430, SensorTAG,
– 
Low-power
◆  The Arduino,
nextMotes
STM32xx, Raspberry PI,
(TI MSP430,
bigARM-based,
thing …)Intel
is small Quark SoC
SensorTAG,
STM32xx,
–  – – 
Arduino, ARM-based,
Motes withMotes
energy
Raspberry
Low-power …)
PI,
(TI harvesting
Intel Quark
MSP430, SoC
SensorTAG,
Source: extremeTech.c
Arduino,
◆ – IoT
Motes isRaspberry
STM32xx, PI,harvesting
with energy
one of the Intel
ARM-based,
hot …) Quark SoCtopics, IETF
research is Source: extremeTech.com
–  Arduino,
Motes Raspberry PI, Intel Quark SoC
IoT iswith
oneenergy
working onthe
of harvesting
IoThotprotocols
research topics, IETF is Source: extremeTech.com
–  Motes with energy harvesting
T◆ working
is IoE
one (Internet
ofontheIoT
hotofresearch
protocols topics,
Everything) is IETF
comingis soon for Source: extremeTech.com
◆  IoT is one of the hot research topics, IETF is
rking
IoE on IoT protocols
(Internet
connecting of Everything)
People, is coming
Process, soonThings
Data, and for
working on IoT protocols
E◆ connecting
(Internet ofPeople,
IoE (Internet
Process,
Everything) Data, andsoon
is coming
of Everything)
Things
is comingsoon for
for
nnecting People,
connecting Process,
People, Data,
Process, and
Data, andThings
Things
hed inThings.
ernet of 2012,In the International
this context, Telecommunication
“smart objects” Union
are devices that typically have (ITU) ITU–T Recommendation Y.2060,
significant
2 The Internet of Things Work
andin thethe
IETFFuture Internet
IoT:  There
Different   d efinitions,   s imilar   c oncepts
34
limited power, memory, and processing36
resources, or bandwidth. is
ew ofrequirements
pecific the Internet of things,
to achieve discusses
network interoperability the concept
between several typesof interconnectivity, but does not specifically tie
of smart
Despite
to the global buzz around the Internet of Things, there is no single, universally accepted definition for
the Internet:
are currently many terms flying around when trying to characterise the future
the term. Different definitions are used by various groups to describe or promote a particular view of what
development of the Internet: In addition to the Internet of Things, there is the Internet
he International Telecommunication Union (ITU) ITU–T Recommendation Y.2060,
IoT
ernet ofmeans
3.2.2
things, and itsofmost
36
Internet
discusses important
things
the (IoT):
concept attributes.
A global but
of interconnectivity, Some definitions
infrastructure
does not forspecify
specifically the concept society,
the information
tie of the Internet or theadvanced
enabling
of Services, 3D Internet, Internet of Content, and Next-Generation Networks, just to
et:Internet Protocol (IP), while others, perhaps surprisingly, do not. For example, consider the following
servicesname a few. It is important
by interconnecting (physicaltoand notevirtual)
that these thingstermsbased should not beand
on existing regarded
evolving as different
definitions.
net of things (IoT):
interoperable “Internets” that will
A global infrastructure
information for theexist
information
and communication in society,
parallel, enabling but rather as different aspects of a37common
advanced
technologies.
This definition in a call for papers for a
y interconnecting (physical and virtual) things based on existing and evolvingfeature topic issue of IEEE Communications Magazine links the IoT
bleback
information
Future Internet.
and communication
The European Commission
technologies.
has understood this and is therefore
to cloud services: Board 33
The Internet
Note 1—Through
Architecture
taking concerted (IAB)
action and
the exploitation
begins RFC 7452,
clustering the
of identification,
“Architectural
dataresearch
Considerations
capture,projectsprocessing
in funding
it isand Smart Objectin the 7 th
communication
Networking’’,
hrough Framework
the exploitation withof this Programmedata capture,into
description:
identification, whatanditcommunication
processing calls the Future Internet Assembly. Furthermore,
s, thecapabilities,
IoT makes The theof things
Internet
full use IoT of makes
toThings full
(IoT)
offer services use isof
to all things
a framework
kinds to offer
of applications, services
in whilst
which to allhave
all things kinds of applications,
a representation andwhilst
a
collaborations
hat security and privacy requirements are fulfilled.
are on-going and likely will be intensified with similar efforts in the
ensuring The
USA that
presence
term security the and
inJapan.
"Internet
and privacy
Internet.
of Things" More
(IoT)requirements
specifically,
denotes a trend arewhere
the fulfilled.
Internet of Things
a large number aims at offering devices
of embedded new applications
rom a broader employ
and From
perspective,communication
services bridging
anIoTenterprise
the services
theand
can be perceived asoffered
physicaleconomic
a vision andby virtual
with the Internet
worlds,
perspective,
technological protocols.
and in the
which Many ofInternet
these devices,
Machine-to-Machine
Future is theoften
(M2M)
basis for a
plications.
Note 2—From web-based
called "smart
communications a broader
service
objects,’’ perspective,
areeconomy
represents not directly the
[1].
the baseline IoT
There
operated can be
bywill perceived
be service
humans,
communication but asenables
exist
that aasvision
platforms thewith
components and technological
ina buildings
interactionsmultitude or and
between of
societal services
vehicles, or
implications.
Things and available
are spread out
applications over
in
in thethe the Internet, hence the term Internet of Services. The
environment.
cloud.
ral Considerationsgranularity of these
in Smart Object Networking” services
(March 2015), will be very different, ranging from high-level business
https://tools.ietf.org/html/rfc7452
Within
The Oxford
Tschofenig, theMary
and Internet
services Engineering
to low-level
Dictionaries
Barnes. 38
"Architectural offersTask
Considerations Force
asensor
inconcise (IETF),
Smart Objectservices
definitiontheIETF
Networking." term
provided
that “smart
invokes
92 Technical by object
the networking”
theInternet
Internet as of is Things.
an commonlyof
element used
The in of
therole
IoT:
6 Sept. 2015. Web. https://www.ietf.org/proceedings/92/slides/slides-92-iab-techplenary-2.pdf
referencethe to the Internet of
Internet ofThings.
Things In this is context,
to bridge “smart theobjects”
gap are devices the
between that typically
physical have significant
world and its
t-of-Things Directorate." IOTDirWiki. IETF, n.d. Web. 06 Sept. 2015.
34
constraints, representation
ea/int/trac/wiki/IOTDirWiki
452, Internet
“Architectural thingsin
suchConsiderations
asoflimited information
power,
(noun):
in Smartmemory,
TheObject systems.
and processing
interconnection
Networking” This leads
viaresources,
(March the ushttps://tools.ietf.org/html/rfc7452
Internet
2015), to our definition
or bandwidth.
of computing Work ofinthe
devices Internet
IETF is of
theembedded in
net of Things.” ITU, June 15, 2012. http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=Y.2060
organized
, Dave, Hannes Things:
around
everyday specific
Tschofenig,objects,
and requirements
enabling
Mary Barnes. to"Architectural
them achieve
to send network
and interoperability
receive
Considerations data.
in Smart between several types
Object Networking." IETFof 92
smart
Technical
35
objects.
IAB RFC 7452. 6 Sept. 2015. Web. https://www.ietf.org/proceedings/92/slides/slides-92-iab-techplenary-2.pdf
NETSOCIETY.ORG
eaAll of -the
Wiki definitions“A
Internet-of-Things world scenarios
describe where
Directorate." physical
IETF,objects
in which
IOTDirWiki. network are seamlessly
n.d. Web.connectivity
06 Sept. integratedcapability
and computing
2015. into extends to a
Published in 2012, the theInternational
information
c.tools.ietf.org/area/int/trac/wiki/IOTDirWiki
constellation of objects, network,
devices, sensors, andUnion
Telecommunication
and everyday where the
(ITU)
items that physical
ITU–T
are objects
Recommendation
not ordinarily can
Y.2060,
considered to be
36
Overview
iew of the of
of the Internet
“computers’’;
become
Internet
thisThings.”
allows ITU,
active
of things,
June 15,
the devices
participants
discusses
2012.
to
in business
the concept processes.
of interconnectivity, but Services are
does not specifically
http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=Y.2060
generate, exchange, and consume data, often with minimal human
tie
available
the IoT to the Internet: to interact with these „smart objects„ over the Internet,
intervention. The various definitions of IoT do not necessarily disagree – rather they emphasize different
query their state and any information associated with them,
aspects of the IoT phenomenon
taking
3.2.2 Internet fromA different
into(IoT):
of things account focaland
security
global points and
theuse
privacy
infrastructure for cases. society, enabling advanced
issues.”
information
WWW.INTERNETSOCIETY.ORG
surrounding the Internet of Things in light of the competing predictions about its promises and perils. The

IoT:  key  concepts

Internet of Things engages a broad set of ideas that are complex and intertwined from different perspectives.
Key concepts that serve as a foundation for exploring the opportunities and challenges of IoT include:

• IoT Definitions: The term Internet of Things generally refers to scenarios where network
connectivity and computing capability extends to objects, sensors and everyday items not normally
considered computers, allowing these devices to generate, exchange and consume data with
minimal human intervention. There is, however, no single, universal definition.

• Enabling Technologies: The concept of combining computers, sensors, and networks to monitor
and control devices has existed for decades. The recent confluence of several technology market
trends, however, is bringing the Internet of Things closer to widespread reality. These include
Ubiquitous Connectivity, Widespread Adoption of IP-based Networking, Computing Economics,
Miniaturization, Advances in Data Analytics, and the Rise of Cloud Computing.

• Connectivity Models: IoT implementations use different technical communications models, each
with its own characteristics. Four common communications models described by the Internet
Architecture Board include: Device-to-Device, Device-to-Cloud, Device-to-Gateway, and Back-End
Data-Sharing. These models highlight the flexibility in the ways that IoT devices can connect and
provide value to the user.

• Transformational Potential: If the projections and trends towards IoT become reality, it may force
a shift in thinking about the implications and issues in a world where the most common interaction
with the Internet comes from passive engagement with connected objects rather than active
engagement with content. The potential realization of this outcome – a “hyperconnected world” -- is
testament to the general-purpose nature of the Internet architecture itself, which does not place
inherent limitations on the applications or services that can make use of the technology.

1 WWW.INTERNETSOCIETY.ORG
Source:  The  Internet  of  Things:  an  overview  (ISOC)
Gartner  2013  Hype  cycle  of  emerging  technologies
 Trends:  IoT,  WSN  and  Ubiquitous  computing

Fig. 2. Gartner 2012 Hype Cycle of emerging technologies.

Source: Gartner Inc. [10].

Fig. 3. Google search trends since 2004 for terms Internet of Things, Wireless Sensor Networks, Ubiquitous Computing.

Frequency Identification (RFID) cost, low power miniature devices for use in remote
hnology is a major breakthrough in the embedded com- plications. The combination of these factors has impro
paradigm which enables design of microchips for wire- ability of utilizing a sensor network consisting of a la
mmunication. They help in the automatic identification of intelligent sensors, enabling the collection, processi
they are attached to acting as an electronic barcode and dissemination of valuable information, gathered
passive RFID tags are not battery powered and they use of environments [7]. Active RFID is nearly the same a
 Raise  and  growth  of  IoT
• 24  billion  Internet-­‐connected  objects  by  2019  (according  to  
Cisco)
• 75  billion  networked  devices  by  2020  according  to  Morgan  
Stanley
• 100  billion  of  IoT connections  by  2025  according  to  Huawei

Source:  http://www.cisco.com/c/en/us/about/security-­‐center/secure-­‐iot-­‐proposed-­‐framework.html
 AL-FUQAHA et al.: IOT: SURVEY ON ENABLING TECHNOLOGIES, PROTOCOLS, AND APPLICATIONS

Economic  impact  of  IoT applications  (2025)

etc. Standardized
the perception la
[18]. The percep
Object Abstractio
created by the Io

B. Object Abstra
Object Abstra
layer to the Servi
Data can be tran
RFID, 3G, GSM,
ZigBee, etc. Furt
and data manage

C. Service Mana
Service Mana
service with its r
layer enables the
 The  overall  picture  of  IoT integration
ernet of
rotocols,
develop-
ies, and
sors col-
ew class
ile, and
the first
o bridge
nnecting
making.
the IoT.
ertain to
s. Com-
provide
and ap-
opers to
together
through
an over-
ent liter-
oreover,
ng tech-
mputing.
n among
Internet  of  Things  applications

Smart Home
Environmental Wearable
Monitoring

Smart Grid Medical & Healthcare

Connected Vehicle
Industrial Automation

Smart City
 Consumer  IoT(BLE)
Bluetooth devices
Mesh
DUMB - SMART
rol’s

Sensibo
and
pad
#81255

• Bluetooth Smart Mesh networking

est – Faster speeds, longer • Makes
rangeIR air conditioners smart
announced
• Exhibitors • Hub + Pods
e and everywhere– Jasco at CES • Learns and adapts
#9005– No booth
Jasco Avi-on
n Bolt • Avi-on lighting ecosystem
Scent
Scent Diffusers
Diffusers
d Group
Bridge
• IFTTT
with Nest’ partners• Also a leader in Z-Wave & ZigBee w/ GE-branded lighting and
seway
ike Nest’ but …
appliance controls. ZigBee Flic
brand#80342
• Pod: 6LoWPAN is EZ ZigBee.
for control, BLE for beacons
Yale Linus Lock

Weave
– Ilumi #71334
• Pod
slide) sensors
le Linus lock
• Smart bulbs (next
– Gooee #70342 – Temperature
• Link a button press to functions on your mobile phone,
Naran – MicroBot, Prota O
nnovations • SensorWake
•– SensorWake
Relative
• IoT platform for lighting #80541#80541
humidity
mostat
e.g.,
– take
Alarm picture,
clock
– Alarm clock
ring
- Wake tophone,
- Wakescent place
of a call.
coffee,
to scent peaches,
of coffee, peaches,
– CEL #70957 – iBeacon presence
Cam beach, mint mint
beach, or money
or money
– Piezo-electric
• 802.15.4: ZigBee, Thread, disc (senses fan level of AC in room units)AromaCare
and Bluetooth AromaCare
ct
Who – Nodon
Named +Thermostat
That?
If your Nest
Silvair •#70544 P&G
•– Light P&G Febreze
LIGHTS
Febreze
(for
notices you’re away, it can tell Whirlpool to
IoT scent diffuser
IoTof scent
activation night diffuser
mode) #70560 (Thread
#70560 Group)Group)
(Thread
utions • keepBluetooth
your clothes freshecosystem And 6
and wrinkle-free.– IR
if Includes
– home,
you're emitters
it cantemperature and humidity sensor
Includes temperature and humidity sensor
Smart Lights
© 2016 EH Publishing automatically switch to Quiet Mode.
– IR receiver (pass-through for existing remotes)
martyPans (smart cooking pans) #80662 • Lumiere • Lumiere #81750#81750
Gooee
epro.com/ces
BeON
cepro.com/CES2016guide
– © 2016
[email protected]
“world’s
EH Publishing
– “world’s first smart essential
first smart oil diffuser”
essential with with
oil diffuser” “plug-and-
“plug-and- MicroBot Twist
oveHandle (Phone grips) #81131
#21000 (Z-Wave)
play capsules”
– New Modular smart bulbs cepro.com/ces play capsules”
Who Named That?
cepro.com/CES2016guide [email protected] © 2016 EH Publishing
cepro.com/ces cepro.com/CES2016guide [email protected] © 2016 EH Publishing
Go– Commando
Bluetooth Smart (marketing service) #81132 – “Analyses your profile to
– “Analyses your profile to perfectly perfectly match your
match schedule,
your schedule,
– Z-Wave
moodmood and pains. Tell itTell
how you feel, “Microbot
and itandwillitdoPush is
Legged Thing (Tripods) #12045
– Audio analytics and pains. it how you feel, willthe
do the
Lutron ZigBee Wireless Keypads
– Learning
rest!”rest!” a wireless robotic
mart
works MeCree
with
– Built-in Upand#80738
battery GE Bulbs
LoveHandle
finger that can
SmartyPans
–Bee
Real-time
Sengled (smart cooking pans)
face analysis
keypad#70531
#70960
• Aroma
• Aroma
#80662
Therapeutics
Therapeutics - AromaCare
- AromaCare #80941
push most
#80941
– –Powers Photomaton,
New Sengled Netatmo, Inovallee
Voice (microphone/speaker) – “First Diffuser
– “First of essential
Diffuser oils connected”
of essential ordinary buttons
oils connected”
• voice control of devices
LoveHandle (Phone grips) #81131• Beewi #31154
• Voice communications cepro.com/ces cepro.com/CES2016guide just like a ©human
[email protected] 2016 EH Publishing
system? #71125
20836
• Audio analytics - glass breaking and baby crying • Beewi #31154 Microbot Push finger does.”
Go Commando
– Snap (camera) – “First
(marketing service) #81132 Connected
– “First
SmartyPans
Oil diffuser
Connected with with
Oil diffuser temp,temp,
humidity , CO2
humidity , CO2
– BOOST (Wi-Fi extender)
sensors” Prota Hub (Bluetooth,
Industrial   IoT (IIoT)  devices
Industrial: machine monitoring

T/C Sensor

Level
Flow Pressure Sensor
Sensor Sensor

1
2
IIoT and  consumer  IoT integration

Source:  http://www.electronicdesign.com/iot/designing-­‐industrial-­‐internet-­‐things
mple
IoT deployment  example
range, Bouygues, KPN…)

Customer
SI server
Customer
SI server

Internet
owisio, réseaux LoRa par opérateurs TelCo (Orange, Bouygues, KPN…)

Internet

Ethernet
isio, réseaux LoRa par opérateurs TelCo (Orange, Bouygues, KPN…)

Co (Orange, Bouygues, KPN…)

Internet

Ethernet
Backend
Customer
Internet

Backend
Backend
SI server
Internet

3G
Internet

3G
Gateway LoRa
ateway privée (Kerlink, Multitech, Link Labs…)
Customer
Backend SI server

Gateway LoRa
way privée (Kerlink, Multitech, Link Labs…)
)
Public LoRa

mmunication –Internet
Recevoir & transporter
oT deployment example
(Bouygues,
provider
network

Orange…)

a
Public LoRa

(Bouygues,

3G
provider
network

Orange…)

abs…)
guer 2 grands types d’architecture:
Ethernet
ay LoRa Internet
3G
SigFox, Qowisio, réseaux LoRa par opérateurs TelCo&(Orange,
Wireless products solutionsBouygues, KPN…)

Ethernet Public LoRa

network
provider
Wireless
(Bouygues, products & solutions
Source:  http://www.cisco.com/c/en/us/about/security-­‐
Orange…)
Internet center/secure-­‐iot-­‐proposed-­‐
framework.html

Customer
Backend
 IoT elements
IEEE COMMUNICATION SURVEYS & TUTORIALS, VOL. 17, NO. 4, FOURTH QUARTER 2015

AL-FUQAHA et al.: IOT: SURVEY ON ENABLING TECHNOLOGIES, PROTOCOLS, AND APPLICATIONS 235

TABLE I TABLE II
C OMMON O PERATING S YSTEMS U SED IN I OT E NVIRONMENTS B UILDING B LOCKS AND T ECHNOLOGIES OF THE I OT

he•IoT Identification:  
elements. name  and  match  services.
• Sensing:   gathering   data  from  related  objects  within  
ction of the time and energy of the device to communi- and control thousands of smart devices and appliances inside
the  network  and  sending   it  back  to  a  data  buildings using their smartphones [24]–[26].
h other devices and integrate the required services.
warehouse,  database,  or  
five-layer model, the Application Layer cloud.  
is the interface Single Board Computers (SBCs) integrated with sensors and
• Communication:  
h end-users can interact withcaonnect  
device and heterogeneous  
query for inter- objects  
built-in TCP/IP and security functionalities are typically used
ata. Ittogether  to  deliver  specific  smart  
also provides an interface to the Businessservices.   Layer to realize IoT products (e.g., Arduino Yun, Raspberry PI, Bea-
igh-level analysis and P
• Computation:   reports can be
rocessing   produced.
units   (e.g.,  The gleBone Black, etc.). Such devices typically connect to a central
mechanisms of accessing data in the application layer management portal to provide the required data by customers.
handledmicrocontrollers,  
at thisLTE (Long-Term
layer. microprocessors,  
This layerEvolution)
is hosted is originallySOCs,  FPGAs)  
on powerful a standard wireless
due toand  software  
its complex andaenormous
communication pplications  represent  the  “brain”  
for high-speed data transfer
computational needs. between mobile
ring these
phones based on GSM/UMTS network technologies
and  the  
points c omputational  
on the one hand ability  of  the  
and sticking to I oT.  
the C. [34].
Communication
It
can cover fast-travelling devices and provide multicasting and
ty•of Services:  
the architecture on services.
the other
Identity-­‐related  
broadcasting hand,
LTE-A the Advanced)
five-layer[35] isThe
Services,  Information  
(LTE IoT communication technologies connect heterogeneous
an im-
ture is the most applicable
proved version model for IoT applications.
of LTECollaborative-­‐Aware  
including bandwidth extension objects together to deliver specific smart services. Typically, the
which
Aggregation   Services,   Services  
supports up to 100 MHz, downlink and uplink spatialIoT multiplex-
nodes should operate using low power in the presence of
and  Ubiquitous  
IV. extended
ing, Services.  
IoT E LEMENTS
coverage, higher throughput and lowerlossy latencies.
and noisy communication links. Examples of communica-
• Semantics:  
rstanding the D.
ability  to  extract  knowledge   smartly  by  
building blocks helps to gain a better tion protocols used for the IoT are WiFi, Bluetooth, IEEE
IoTComputation
nto thedifferent  
real meaning machines   to  provide  
and functionality of the  required  
the IoT. In 802.15.4, Z-wave, and LTE-Advanced. Some specific communi-
owingservices.  
sections Processing
we discussunits six (e.g.,
mainmicrocontrollers,
elements needed cation technologies are also in use like RFID, Near Field Com-
microprocessors,
SOCs, FPGAs) and software applications represent the “brain” (NFC) and ultra-wide bandwidth (UWB). RFID is
munication
er the functionality of the IoT as illustrated in Fig. 4.
and the computational ability of the IoT. Various hardware plat-
shows the categories of these elements and examples the first technology used to realize the M2M concept (RFID
IoT associated   technologies
Fig. 1. Number of IoT Journal articles by year in Web of Knowledge.

Fig. 2. Technologies associated with IoT.

 te
IoT architecture
Fig. 2. Projected market share of dominant IoT applications by 2025.
w
de
w

cu
pe
as
th
m
Fig. 3. The IoT architecture. (a) Three-layer. (b) Middle-ware based. (c) SOA ve
based. (d) Five-layer. ti

critical need for a flexible layered architecture. The ever increas-

AL-FUQAHA et al.: IOT: SURVEY ON ENABLING TECHNOLOGIES, PROTOCOLS, AND APPLICATIONS
E
 – Icontrol •OneIcontrol
for– Icontrol One for –
independent NEW announcem
#70753,
independent deVP
dealers
IoT cloud-­‐based  services  and  APIs
Advanced Listening
– PiperTech
DIY–camera/HA
Icontrol One for inde
– • Piper Samsung SmartThings hub
DIY camera/HA • ROC-Connect
hub
SHaaS (Smart
•– New
Whole-home
SmartThinQ House
learning
home
– Piper DIY
– for NEW
analytics?
automation
Kevin Meagcamera/HAhub
s Samsung
– Whole-home– –New:
• SmartThings
Alarm.com
6285, 74538 (Cerevo) Scout
– Used to be just
learning
–(Nasdaq:
now completeWhole-home
#11906
–home for
ALRM)
OZOM
control profess
major appliances
analytics?
in learning
Latin
system
ud-enabled listening device, “analyzes sound around Wi-Fi” A
w/ new
– Speaking, not exhibiting
– New: Scout – for
– professional
Bluetooth, Z-Wave,monitoring
–New Z-Wave, ZigBee
ZigBee
annT
e recognition + “Analyzes feelings from the voice of the infant” - Developed
– ROC-Master
• –Icontrol
• Westgate
Alarm.com
Alarm.com (Nasdaq: ALRM)
Panasonic
• Zonoff AllJoyn/AllSeen
New Z-Wave, ZigBee TV–dongle
suite
CES: Venetian a (Nasdaq:
d to Cerevo, voice-analysis engine developer, Jan. 2016
• Samsu
nds can be learned into #70753, VP
device, such as – Works
snapping, with Lowe’s
coughing, doorbell …Iris
– Staples
– Speaking, Connect
not exhibit
– •
IcontrolMiOS
tube video
One for independent – 3.5-inch
dealers – New LCD display
–– Piper
MiOS Speaking,
#21000 –
with Harman offsite ADT
– not • exhibiting
#21000
DIY from
Streams
DIY camera/HA hub SecureNet #21000
LG?
music
– New
her originally developed technology to isolate human voice from noise,
– NEW announcements sensors at CES to dumb appli
– Drives Orange,
– • Zonoff
Vera,
Drives
ecially for telephone communications
– Whole-home learning
– SmartThinQ
URC,
Orange,
– Elan,
Powers
Westgate others
Vera,
suite
analytics?
“state” U
Resolutio
connect
through vibration, temperature, and a
• MiOS
Zonoff
arning the nuances of voice, Cypher also isolated background noises,
• ROC-Connect EcoNet DIY Hom
umulating a database of very specific sounds opening/closing the fridge door.
– Staples Connect
#
• Greenwave Westgate
Alarm.com (Nasdaq:
Systems suite
ALRM)
– can
se specific sound characteristics now NEW Kevin
be used Murano
Meagher
for other 3303from Lowe’s Iris
audio-analytic – Driv
• New WebOS 3.0 for SmartTVs
– • Greenwave Systems
ing dog. –Advanced
Staples Listening
Connect– Tech
Speaking, –not OZOM ADT DIY from LG?M
poses, for example, warning a headphone-wearing jogger of a siren or
exhibiting in Latin
– Certified by ULAmerica
• Greenw for “compatibility with IoT de
• Many
ZonoffIoT-enabling
– ROC-Master platforms
– smart
– Control NEW
announced announcement
appliances through TV
– ADT
– – Arrayent, DIY
Westgate suite
– CES:
• Ayla, from LG?
Venetian
etc. and ULE Alliance• Many I
•
• Listnr
Listnr
Many IoT-enabling
Staples ConnectHomeChat
#36285, 74538 (Cerevo)

• ROC-Connect plat cepro.com/c

for communicating with LG–smart
– Cloud-enabled listening device, “analyzes sound around Wi-Fi”
– NEW announcements at CES
• – SecureNet
ADT
– Voice recognitionDIY from – Platform
LG?
+ “Analyzes feelings #21000
from the voice of the infant” - Developed
Arrm
Proprietary
cepro.com/ces cepro.com/CES2016guide
– Panasonic
with
– – Works
– NEW Kevin• Meagher
NEW announcements Proprie
– Powers atwith
Arrayent, Ayla, etc.
[email protected]
CES
ResolutionNest Products and new
© 2016 EH Publishing
 IoT cloud  platforms
PCA), pattern reduc- TABLE VIII
I OT C LOUD P LATFORMS AND T HEIR C HARACTERISTICS
election, and distri-
• Gateway:  bridging  
affic the  short  rin
analytics ange  
the
B. network  and  wide  
area  network

• Provision:  
nagement mechanism
discovery,  
delivery,  
dataconfiguration  
and the extrac- and  
activation  of  
easy task due to athe
applications   nd  
services
etween different cloud
Assurance:  
ide•real-time services
proactive  and  
ious cloud platforms.
reactive  assurance  
also presents a signif-
of  platforms
services due having
dors.
• Accounting  and  
en general
billingcloud ser-
ents presents another
 from every sensor, secures
IoT Security, Device it, gives control to owner
Discovery
IoT security  services
e with family members, insurance companies,
• BitCircle – BitBox
s, –healthcare
‘The first home providers,
(80632)
financial
based personal cloud system” institutions, etc.
– Privacy and security of user’s personal digital information
– Combines data from every sensor, secures it, gives control to owner
– Users can share with family members, insurance companies,
cted devices against malicious attacks.
• Cujo
service providers, healthcare providers, financial institutions, etc.
(80531)
NETWORK

e learning and
IoT Security
– Protects behavioral
connected analysis
devices against to bring
malicious attacks. peace
– Applies machine learning and behavioral analysis to bring peace of
of
me. mind to your home.
•• Daplie
Not exhibiting
- Cloud #80461
–– Encrypted,
Dojo Labs private, secure, and social cloud for the home.
– Luma
– Cloud retains encrypted data and access privileges to connected
– Krika
devices and puts the owner in full control.
• PFP #80246 cepro.com/ces cepro.com/CES2016guide [email protected] © 2016 EH Publishing

– IoT cybersecurity solutions detect cyber-attacks in IoT hardware

and software.
– Detects tiny anomalies in power patterns to catch attacks early.
– Allows external device to monitor internal execution status of a
processor and identify any deviations from authorized execution.
cepro.com/CES2016guide
– Can [email protected]
be implemented in a single-chip IoT solution. © 2016 EH Publishing
 Node Architecture
Node Architectur
IoT node  architecture

Figure 3.1 Architecture of a wireless sensor no

Figure 3.1 Architecture of a wireless sensor node

Fundamentals of Wireless Sensor Networks: Theory and Practice
Waltenegus Dargie and Christian Poellabauer © 2010
Fundamentals of Wireless Sensor Networks: Theory and Practice
Waltenegus Dargie and Christian Poellabauer © 2010 46
Microcontroller
Microcontroller

•  Main processing units of embedded devices

•  Special purpose and highly integrated
–  Integrated RAM, ROM, I/O, peripherals
–  Extremely good power to performance ratio
–  Cheap, typically 0.25 - 10.00 USD
•  Executes programs including embedded system control,
measurement & communications
–  Usually time-critical requiring guarantees
–  Real-time performance a common requirement
•  Pre-emptive scheduled tasks
•  Queues and semaphores

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 47

Example:  MSP430
Example: MSP430
•  Texas Instruments mixed-
signal uC
•  16-bit RISC
•  ROM: 1-60 kB
•  RAM: Up to 10 kB
•  Analogue
–  12 bit ADC & DAC
–  LCD driver
•  Digital
–  USART x 2
–  DMA controller
–  Timers

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 48

 Example:  ATMEL  AVR
Example: Atmel AVR

•  Atmel AVR family

•  8-bit RISC
•  RAM: Up to 4 kB
•  ROM: Up to 128 kB
•  Analogue
–  ADC
–  PWM
•  Digital
–  USARTs
–  Timers

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 49

Memory Memory
•  Random access memory (RAM)
–  Included on-board in microcontrollers
–  Often the most valuable resource
•  Read-only memory (ROM)
–  Usually actually implemented with NOR flash memory
•  Flash
–  Eraseable programmable memory
–  Can be read/written in blocks
–  Slow during the write process
–  Consumes power of course!
•  External memory
–  External memory supported by some microcontrollers
–  Serial flash always supported
Common  bCommon Bus Interfaces
us  interfaces
•  Digital and analogue I/O
–  Accessed by port and pin number (e.g. P1.3)
–  Some pins are also connected to interrupts
•  UART
–  Asynchronous serial bus
–  After level translation it is an RS232 bus
–  Usually kbps up to 1 mbps
•  SPI (serial peripheral interface)
–  Synchronous serial bus
–  Reliable with speeds of several Mbps
•  I2C (inter-integrated circuit) bus
–  2-wire bus with data and clock
•  Parallel bus
–  Implemented with X-bit width
–  X-bit address and clock signals

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 51

 IoT:  c ommon  
o perating  
TABLE Isystems
C OMMON O PERATING S YSTEMS U SED IN I OT E NVIRONMENTS

LTE (Long-Term Evolution) is originally a standard wireles

ommunication for high-speed data transfer between mobil
 Internet  of  Things  in  
industries

Li   Da   Xu,  Senior   Member,  IEEE,   Wu   He,   and  Shancang Li,   Internet   of  Things   in  Industries:   A  Survey,  IEEE  
TRANSACTIONS  ON  INDUSTRIAL  INFORMATICS,  V OL.  10,  NO.  4,  NOVEMBER  2014  
IoT layers   A F TABLE I
OUR-LAYERED ARCHITECTURE FOR IOT
IoT industrial  applications:  
TABLE II requirements
DESIGN CONSIDERATIONS FOR INDUSTRIAL IOT APPLICATIONS (ADAPTED FROM [48])

vehicular network [25]–[32]. Quite a few ideas have been

SoA architecture
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 4, NOVEMBER 2014
decentralization of existing business processes increases scalability and performance,
allows better decision making and could even lead to new revenue streams through
IoT:  business  process  decomposition
entitlement management of software products deployed on smart items. Software is
already the key innovation driver in many industries and many new business models
of the future will heavily rely on the use of such items [5].

Fig. 1. Traditional vs. decomposed and distributed business processes

Edge processing and business process decomposition allows applications to make

(part of their) decisions locally in a decentralized manner and act accordingly. It
thereby extends the real world visibility concept with real world interaction.
In addition to a (central) business application, data is processed locally in a
 Nursing  home  patient  monitoring
AL-FUQAHA et al.: IOT: SURVEY ON ENABLING TECHNOLOGIES, PROTOCOLS, AND APPLICATIONS 2371
 IoT and  Smart  Grid ISSN: 23

Figure 2. Basic Architecture of IoT in Applications of Smart Grid

erception layer is usually divided into perceived control layer and commu
layer. Mainly through the sensor, RFID, camera and other sensors, perceive
e predicted. The specific implementation process of power predicti
Example:  wind  power  prediction

Figure 3. Wind power prediction based on IoT

A Vol. 12, No. 2, February 2014: 940 – 946

Quizz
• Which  of  these  is  not  an  example  of  IoT device?
• Fitbit (a  wristband  that  track  steps  …)
• Apple  watch
• cash  register
• Raspberry  Pi
• The  “smart  grid”  applies  to  which  sector
• E-­‐Commerce
• Power
• Personal  fitness
• Defense
• What  end-­‐users  typically  forget  to  change  on  their  IoT devices  ?
• DNS  settings
• IP  address
• Default  password
• IoT devices  never  talk  to  each  other  ?
• True
• False
• All  IoT devices  require  human-­‐to-­‐machine  interaction  in  order  to  function  
properly
• True  
• False
IoT communication  
protocols
 IoT communication  
Device-to-Device Communications models  (RFC   7452)

• Device  to  device  communications

The device-to-device communication model represents two or more devices that directly connect and
communicate between one another, rather than through an intermediary application server. These device
• Built-­‐in  security  and  trust  mechanisms
communicate over many types of networks, including IP networks or the Internet. Often, however these
• Device-­‐
devices specific  
use protocols data  40mZ-Wave,
like Bluetooth, odels41 or ZigBee42 to establish direct device-to-device
• Compatibility  
communications, as shown pFigure
roblem  
1. for  the  users
Device&to&Device)Communica/on)Model)
in

Light) Wireless) Light)

Bulb) Network) Switch)

Manufacturer)A) Bluetooth,)Z+Wave,)ZigBee) Manufacturer)B)

Source:))Tschofenig,)H.,)et.)al.,)Architectural)Considera/ons)in)Smart)Object)Networking.)Tech.)no.)RFC)7452.)Internet)Architecture)Board,)Mar.)2015.)Web.)
<hRps://www.rfc&editor.org/rfc/rfc7452.txt>.)

Figure 1. Example of device-to-device communication model.

These device-to-device
Tschofenig,   networks
H.,  et.  al.,  Architectural   allow devices
Considerations   that
in  Smart   adhere
Object   to a particular
Networking.  Tech.  no.  Rcommunication
FC  7452.   protocol to
Internet  
Architecture  
communicate andBoard,  Mar.  
exchange2015.   Web.  https://www.rfc-­‐
messages to achieve their editor.org/rfc/rfc7452.txt  
function. This communication model is commonly
used in applications like home automation systems, which typically use small data packets of information
IoT communication  models  (RFC  7452)
benefits from knowing that products within a particular family tend to communicate well.

Device-to-Cloud Communications
• Device  to  Cloud  communications
• IoT device  connects  directly  to  Internet  cloud  service
In a device-to-cloud communication model, the IoT device connects directly to an Internet cloud service li
an application service provider to exchange data and control message traffic. This approach frequently ta
• Takes  advantage  of  existing  communications  mechanisms:  
advantage of existing communications mechanisms like traditional wired Ethernet or Wi-Fi connections to
wired  Ethernet,  Wi-­‐Fi
establish a connection between the device and the IP network, which ultimately connects to the cloud
• Interoperability  
service. issues:  device  and  cloud  service  from  the  
DeviceQtoQCloud(Communica9on(Model(
This is shown in Figure 2.
same  vendor

HTTP$ Applica9on(Service( CoAP$

TLS$ Provider( DTLS$
TCP$ UDP$
IP$ IP$
Device(with(
Device(with( Carbon(
Temperature( Monoxide(
Sensor( Sensor(

Source:((Tschofenig,(H.,(et.(al.,(Architectural(Considera9ons(in(Smart(Object(Networking.(Tech.(no.(RFC(7452.(Internet(Architecture(Board,(Mar.(2015.(Web.(
<hNps://www.rfcQeditor.org/rfc/rfc7452.txt>.(

Tschofenig,  
Figure H.,  et.  al.,  Architectural  
2. Device-to-cloud Considerations  
communication model in  Smart  Object  Networking.  Tech.  no.  RFC  
diagram.
7452.  
Internet  Architecture  Board,  Mar.  2015.  Web.  https://www.rfc-­‐editor.org/rfc/rfc7452.txt  
This communication model is employed by some popular consumer IoT devices like the Nest Labs Learn
 IoT communication  models  (RFC  7452)
such as ownership of and access to the data. At the same time, users can generally have confidence that
devices designed for the specific platform can be integrated.

• Device  to  Gateway  

Device-to-Gateway Modelmodel

• Device   connects  
In the device-to-gateway to  oramore
model, pplication   layer  gateway  
typically, the device-to-application-layer to  r(ALG)
gateway each  
model,a  the
cloud  
service
IoT device connects through an ALG service as a conduit to reach a cloud service. In simpler terms, this
means that there is application software operating on a local gateway device, which acts as an intermediary
• Local  
betweengateway  
the device andc ould  
the be  aand  sprovides
cloud service martphone   running  
security and other functionality an  aaspp  
such to  
data or

communicate   with  the  device  and  relay  data  to  a  cloud  service
protocol translation. The model is shown in Figure 3.

Applica9on(Service(
Provider(

IPv4/IPv6$

HTTP$ CoAP$
Protocol$ TLS$ DTLS$
Stack$ Local(Gateway(
TCP$ UDP$
IPv6$ IPv6$
Device(with(
Device(with( Layer$1$Protocol$ Carbon(
Temperature( Bluetooth$Smart$ Monoxide(
Sensor( IEEE$802.11$(WiDFi)$
Sensor(
IEEE$802.15.4$(LRDWPAN)$

Source:((Tschofenig,(H.,(et.(al.,(Architectural(Considera9ons(in(Smart(Object(Networking.(Tech.(no.(RFC(7452.(Internet(Architecture(Board,(Mar.(2015.(Web.(
<hNps://www.rfcQeditor.org/rfc/rfc7452.txt>.(

Tschofenig,   H.,  Figure

et.  al.,  3.Architectural  Considerations  
Device-to-gateway communication in  Smart  
model O bject  Networking.  Tech.  no.  RFC  
diagram.
7452.  I nternet  Architecture  Board,  Mar.  2015.  Web.  https://www.rfc-­‐editor.org/rfc/rfc7452.txt  
m a broader technical perspective, the IETF Journal article explains the benefit of the device-to-gatew

Benefits  of  device  to  gateway  model

ice, but they can also bridge the interoperability gap between devices themselves. For example, the
oach:
artThings hub is a stand-alone gateway device that has Z-Wave and Zigbee transceivers installed to
47
municate with both families
This [communication of devices.
model] is usedItinthen connects
situations to thethe
where SmartThings cloudrequire
smart objects service,interoperability
allowing the
• Integrate  new  smart  devices  into  a  legacy  system
to non-IP
gain access to the
[Internet devices devices.
protocol] using a smartphone
Sometimesapp
thisand an Internet
approach connection.
is taken for integrating IPv6-only
• But  adds  complexity  and  cost  to  overall  system
devices, which means a gateway is necessary for legacy IPv4-only devices and services.
48
m a broader technical perspective, the IETF Journal article explains the benefit of the device-to-gateway

IETF  journal  11.1  (2015)

oach:
her words, this communications model is frequently used to integrate new smart devices into a lega
em This
with[communication
devices that are not natively
model] is used interoperable with the
in situations where them. A downside
smart of thisinteroperability
objects require approach is that
with the
essary development
non-IP of the application-layer
[Internet protocol] gateway
devices. Sometimes software
this approach and system
is taken adds complexity
for integrating IPv6-only and cost
overall system.
devices, which means a gateway is necessary for legacy IPv4-only devices and services.
48

RFC  7452
her words,
IAB’s this communications
RFC7452 model the
document suggests is frequently used
outlook for to model:
this integrate new smart devices into a legacy
em with devices that are not natively interoperable with them. A downside of this approach is that the
It is development
essary expected that
of in
thethe future, more generic
application-layer gatewaygateways will system
software and be deployed to lower cost
adds complexity andand
cost to
infrastructure
overall system. complexity for end consumers, enterprises, and industrial environments. Such
generic gateways are more likely to exist if IoT device designs make use of generic Internet
IAB’s RFC7452 document suggests the outlook for this model:
protocols and not require application-layer gateways that translate one application-layer
protocol to another
It is expected one.future,
that in the The use
moreofgeneric
application-layer gateways
gateways will will, in
be deployed general,
to lower costlead
and to a more
49
fragile deployment,
infrastructure as has
complexity been
for end observed enterprises,
consumers, in the past… and industrial environments. Such
generic gateways are more likely to exist if IoT device designs make use of generic Internet
evolution of and
protocols systems using application-layer
not require the device-to-gateway communication
gateways model
that translate one and its larger role in addres
application-layer
 IoT communication  models  (RFC  7452)
analyzing the energy consumption and utilities data produced by all the IoT sensors and Internet-enabled
utility systems on the premises. Often in the single device-to-cloud model, the data each IoT sensor or
system produces sits in a stand-alone data silo. An effective back-end data sharing architecture would allow

• Back-­‐end  data  sharing  model

the company to easily access and analyze the data in the cloud produced by the whole spectrum of devices
in the building. Also, this kind of architecture facilitates data portability needs. Effective back-end data-
• Communication   architecture  
sharing architectures allow users that  
to move their data when enables  
they switch uservices,
between IoT sers  tbreaking
o  export  
down and  
analyze smart  object  data  from  a  cloud  service  in  combination  
traditional data silo barriers.

with   data  from  other  sources.

The back-end data-sharing model suggests a federated cloud services approach or cloud applications
programmer interfaces (APIs) are needed to achieve interoperability of smart device data hosted in the
52

• Requires   interoperability  
53
cloud. A graphical among  
representation of this design is shown in b ack-­‐
Figure 4. end   systems

Figure 4. Back-end data sharing model diagram.

Tschofenig,   H.,  et.  al.,  Architectural  Considerations   in  Smart  Object  Networking.  Tech.  no.  RFC  
7452.  I nternet  Architecture  Board,  Mar.  2015.  Web.  https://www.rfc-­‐editor.org/rfc/rfc7452.txt  
 IoT common  standards
AL-FUQAHA et al.: IOT: SURVEY ON ENABLING TECHNOLOGIES, PROTOCOL

TABLE III
• Facilitate  and  simplify   S TANDARDIZATION E FFORTS IN S UPPORT OF THE I OT

application  
programmers’  job
• IEEE,  W3C,  ETSI  and  
IETF  working  groups

AL-FUQAHA et al.: IOT: SURVEY ON ENABLING TECHNOLOGIES, PROTOCOLS, AND APPLICATIONS

Institute of Electrical and Electronics Engineers (IEEE) an

andards’
’Infrastructure  
& Frameworks &
• End-to-end framework
Frameworks
protocols
– Pro security sensors
• Launched Sept. 2015
• e.g. 433 MHz
READ: Can Wi-Fi or Bluetooth Supplant
ZigBee or Z-Wave for Home Automation?
–• •Bluetooth,
ZigBee 3.0 ratified
Z-Wave Alliance
Legrand push-buttons, connected doorbell

oT technologies
AllSeen,BLE, Mesh
ZigBee
– All flavors in one
DO

es IoT
• Wi-Fi
• NFC–
NEW fortechnologies
Alliance
Wi-Fi,
ZigBee HaLow
install,+6LoWPAN
maintenance
Enocean
ologies– Self-powered @ 2.4 GHz
collaboration
MP25556
• Who cepro.com/ces
knew?!
––WillThread
• Vision
Group
combine EnOcean – Wi-Fi,
cepro.com/CES2016guide
6LoWPAN • Remotec
[email protected]

#70560Profiles (EEPs) with ZigBee 3.0

Equipment
– Sensors, Z-Wave devices
© 2016 EH Publishing

• SecureNe
W •Wi-Fi
Participants at booth
HaLow (802.11ah) – low-rate, low-power
0426 – Open Internet
– Atmel
ocol for IoT
– Centralite
– Thread
• Nexia Consortium
– NEW Doorbell Sensor
VP Group #70560Flocoon Pixel with inductive charging
– SHaa
Resol
– DSW
• Samsung, Intel …
battery-operated sensors,
– Feibit
DOWNLOAD Home
– Legrand GUIDE FOR LINKS – Open
• MCO wearables, parkingInternet
meters • Conso
Locks
– Alljoyn/AllSeen #71836
– MMB Networks
• PlumChoice
– Kwiks
• Samsung, Intel …
– NXP
– OSRAM (Sylvania) – Lightify gateway & ecosystem
Fi's answer •to Qualcomm,
Bluetooth” LG, Panasonic,
cepro.com/ces
– OWON - thermostats – NEW ConnectedHome
cepro.com/CES2016guide Expert service
[email protected] © 2016 for • Nortek Se
EH Publishing

– Philips Hue smart-home tech support – 2Gig,

MHz Cisco …
– POMCube – Residential energy storage
– Alljoyn/AllSeen #71836
27 – Ubisys
• Enerwave CES 2015 – Enocean + ZigBee
autom
DIY in
ange of–Wi-Fi,
Apple HomeKit
improved penetration through walls
– XHY Intelligence Tech. Philips Hue Tap, Legrand switches

other • Oomi by Fantem • Qualcomm, LG, Pa

read obstacles
- #70560)
– IFTTT
cepro.com/ces – Complete control system
cepro.com/CES2016guide (see: hubs)
[email protected] © 2016 EH Publishing

e info to come …
• Aeon Labs, Aeotec
Cisco …
– Sensors, bulbs, doorbell, smart window
 100k 9M
c
ont
rôl
eur
sdomot
iques
IoT communication  protocols  trends
Sour
ce↵
:Par
ksAs
soc
iat
es

~x100en5ans
100
France
80

60

40

20

0
2007 2009 2011 2013 2015

Loï
cROUCH–Sécur
itédesobj
etsconnect
és 31 août 2016 - 13
IoTComparison(
communication   protocols  comparison(
[C.(Gomez(et(al.,(MPI(Sensors(journal(2012,(vol12]
Table 2. Main characteristics of ZigBee, 6LoWPAN, Z-Wave, BLE and classic Bluetooth. The data of ZigBee, 6LoWPAN and Z-Wave has
been obtained or adapted from the literature [2].
ZigBee 6LoWPAN (Over 802.15.4) Z-Wave Bluetooth Low Energy Classic Bluetooth
868/908 (all chips)
RF band (MHz) 868/915/2400 2400 (400 2400 2400
serie chip)
9.6/40 (from 200
≤721(v1.2), 3000
series chip) 200
Bit rate (kbps) 20/40/250 1000 (v2+EDR), ≤24,000
(only 400 series
(v3+HS)
chip)
GFSK (v1.2), GFSK/π/
Physical layer 4-DQPSK/8DPSK
Modulation BPSK/BPSK/O-QPSK BFSK GFSK
(v2+EDR), 802.11
(v3+HS)
Spreading FHSS (2 MHz channel FHSS(1 MHz channel
DSSS No
technique width) width)
Receiver −85 or better(2.4 GHz band)−92 ≤−70(required)
−101 (at 40 kbps)
sensitivity (dBm) or better(868/915 MHz bands) −87 to −93 (typical) −90(typical)
Transmit
−32 to 0 −20 to 0 −20 to 10 20/4/0(Class 1/2/3)
power (dBm)
MAC TDMA+CSMA/CA (beacon mode)
CSMA/CA TDMA TDMA
mecha-nism and CSMA/CA (beaconless mode)
64 (max. MAC
Message size
127 (maximum) payload in 200 8 to 47 358 (maximum)
(bytes)
Link layer series chip)
8-bit CRC (header); 16-bit
8-bit checksum.
Error control 16-bit CRC. ACKs (optional) 24-bit CRC. ACKs CRC and 2/3 FEC
ACKs (optional)
(payload). ACKs
Latency (ms) <5 (beaconless mode, at 250 kbps) <39 (at 40 kbps) <3 <100
16- and 64-bit MAC 16- and 64-bit MAC 48-bit public device
32-bit (home ID), 48-bit public device

Comparison([C.(Gomez(et(al.,(MPI(Sensors(journal(2012,(vol12](
Identifiers addresses. 16-bit addresses. 128-bit Bluetooth address or
Sensors 2012, 12 8-bit (node ID) Bluetooth address
NWK identifiers IPv6 addresses random address
27(
Table 2. Main characteristics of ZigBee, 6LoWPAN, Z-Wave, BLE and classic Bluetooth. The data of ZigBee, 6LoWPAN and Z-Wav
been obtained or adapted from the literature [2].
 IoT communication  protocols  comparison  
Comparison((cont.)(
(cont.)
nsors 2012, 12
[C.(Gomez(et(al.,(MPI(Sensors(journal(2012,(vol12](
1175

Table 2. Cont.
ZigBee 6LoWPAN (Over 802.15.4) Z-Wave Bluetooth Low Energy Classic Bluetooth
Edge Router, Mesh Node
Coordinator, Router
Device types or roles (mesh under), Router (route Controller and slave Master and slave Master and slave
and End device
over), Host
Scatternet (routing
Mesh routing, tree
Multi-hop RPL (other protocols protocol out of the scope
routing, and source Source routing Not currently supported
solution are not excluded) of the Bluetooth
routing
specifications)
Network layer
30/10/5 (mesh
routing/tree Outside scope of
Hop limit 255 4 1
routing/source Bluetooth specifications
routing)
Integrity, confidentiality, access control Pairing and Link Key
Security Modes/Levels.
(IEEE 802.15.4 security, using 128-bit AES) Generation.
Pairing. Key
Key management Key management currently 128-bit AES Authentication.
Gener./Distribution.
Security out of scope encryption (400 Confidentiality. Trust
Confidentiality,
series chip) Levels, Service Levels,
Authentication, and
and Authorization.
Integrity
Ex algorithms
45–128 kB (ROM), 24 kB (ROM), 32–64 kB (Flash), ~40 kB (ROM), ~100 kB (ROM),
Implementation size

Comparison((cont.)(
2.7–12 kB (RAM) 3.6 kB (RAM) 2–16 kB (SRAM) ~2.5 kB (RAM) ~30 kB (RAM)

[C.(Gomez(et(al.,(MPI(Sensors(journal(2012,(vol12](
Sensors 2012, 12

Table 2. Cont.
ZigBee 6LoWPAN (Over 802.15.4) Z-Wave Bluetooth Low Energy 28( Blueto
Classic
Edge Router, Mesh Node
 Z-­‐wave  protocol
work over wireless or wired control panels. An open source implementation of Z-
as a “smart home”. The first protocol stack, open-zwave [4], is available but it doe
n systems such as X10 used support the security services as of yet.
uildings• Wireless  as theprotocol   Joseph Hall d
communication et eveloped  
al. by  the  
mited company  
bandwidth, ZenSys they in  1999,  
were acquired  by  
ound
Sigma  Designs  in  2008.
lectrical
e protocol overview interference. Wireless
rcome • Based  
these
protocol is defined
on  
in terms
tofhe  
limitations ITU-­‐T  of
layers. The Physical
G.9959  
thelayer scontrols
(PHY)
tandard:  
the behavior of the radio
ccording but   it  is  a  pexpansion
to the configurations roprietary  pand
in Table 1. The Medium rotocol
Access Control (MAC) layer links network
ovide easier
anaging acknowledgements, error checking, and retransmissions. The Logical Link Control (LLC)
• toNetwork:  
s access
evices. instances of different
e adaptation layersHowever, control  
for handling Mesh as Network nodes  
network protocol
the stacks a
radio
Routing
nd  
(e.g., slave  Between the MAC and
6LoWPAN).
(NWK), Segmentation and Reassembly
ed ornodes,  
Encryption (ENC). Finally,
injected mtheesh   network
byApplication
the (APP) layer controls end device behavior. The PHY, MAC,
attackers,
rs are specified by ITU-T G.9959, while the implementation of the APP layer is left to the device
r. and• Data   rates  (US)
integrity of wireless
o configurations (US)
portance in these systems.
Rate 1 (R1) Rate 2 (R2)
As Rate 3 (R3)
key establishment,
Data rate 9.6 kbpsencryption, 40 kbps 100 kbps
Symbol rate 19.2 kBaud 40 kBaud 100 kBaud
d device Center authentication
freq 908.42 MHz 908.40were MHz 916 MHz
Modulation FSK FSK GFSK
f open wireless Coding
protocols
Manchester NRZ
such NRZ
rity services are built on top of
Deviation ±20 KHz ±20 KHz ±29 KHz

me, illustrated in Figure 1, is constructed according to the layers previously described. While the
algorithms such asconfiguration
Advanced in Table 1, for brevity this work focusesFigure 1 - Z-Wave protocol layers
• In  
e format EAdditionally,
for R2. urope  8not68.42  
t is slightly different for each radio
depicted inM HZ
Figure
on the
1 are the NWK, SAR, or ENC adaptation layers
uccessful attacks against them
ppear when those specific adaptations are invoked.
• Range  the
exploit 50  mimplementation
eters The open-zwave software uses a Z-Wave controller d
r consists of a preamble for symbol synchronization consisting of the binary pattern 01010101
• ofPHY  
management
y a Start Service  
Frame (SOF) practices
delimiter and Data   [1]Ubynit  
followed [2].dataspassed
izes:  
from asMACthe
1the
70B   at  radio
layer modem to communicate with the network n
as a PHY Service
SDU). The MAC layer includes the fields shown in Figure 1. The Home ID is a four-byte unique
ed R3  
by
an instance of aa nd  6Home
Sigma
Z-Wave 4B  Areaat  Network
R1  o(HAN).
Designs, r  R2   rSource
Inc.
The atesID andThe controller
Destination ID fields specifydevices can only manage one Z-Wave ne
, a unique device identifier within a Z-Wave HAN, of the sender and receiver. The Frame Control
ntegrity
of the subfieldsprotection
shown in Table 2. Ofand particulardevice at a given time identified by a unique 32 bits Home ID
interest to this work are the Acknowledgement
the Sequence Number subfields. The Length field represents the byteHome length of theID
PSDU. value
The MAC is written to the controller’s Z-Wave ch
sUnit gaining
(MSDU) is the data momentum
passed from the LLC layer. against
Finally, the MAC layer is concluded with an eight-
cting Frame Check Sequence (FCS).
 sniffer project known an as z-force.study
Theirofsniffer consistsprotocol
of two
Z-­‐wave  networks
similar
niversal
authors
Texas
conduct
and Instruments
in-depth
CC1110
uncover the details of boards,
the Z-Wave
one transmits
frame encryption and receives,
and authentication
• Mesh  and custom firmware.
nalgorithms.
etwork   They
with   one  pBefore
discover an implementing
controller  athe
implementation
rimary   error
nd   usniffer,
to  2the
p  used in
32  
st of wire-authors conduct an in-depth study of the Z-Wave protocol
nodes
messagesand uncover the details of frame encryption and authentication
Automatic  
rs,• alarms, topology  
algorithms. They ddiscover
iscovery an implementation error used in
f wire-
on sensors
Network  inclusion  and  exclusion  devices
a •Z-Wave
essages
teway that
alarms,
sensors Fig. 3: Local gateway access: Users manage their Z-Wave
e features
Z-Wave HAN via their gateway locally. All device control is performed
manage
ay that the
from inside the home.
e the user Local  gateway  access
le beyondFig. 3: Local gateway access: Users manage their Z-Wave
eatures
However,HAN via their gateway locally. All device control is performed
age the
d gatewayfrom inside the home.
e user
work with
beyond
lock their
owever,
the house, Global  gateway  access
.ateway
With this Fig. 4: Global gateway access: Users manage their Z-Wave
Z-­‐wave  frame
S>u 7`K2 S`2K#H2 aQ6 J* .i 6`K2 1Q6

9 R k R R R Q` k
aBM;H2+bi
6`K2 .2biBMiBQM
J* 7`K2 >QK2 A. aQm`+2 A. G2M;i? .i TvHQ/ *?2+FbmK
+QMi`QH A.
+MH R 2i k
9 R k R R R k
aBM;H2+bi
6`K2 a2[m2M+2 .2biBMiBQM
J* 7`K2 >QK2 A. aQm`+2 A. G2M;i? .i TvHQ/ *?2+FbmK
+QMi`QH MmK#2` A.
+MH j
9 R k R R kN R Q` k
JmHiB+bi
6`K2 JmHiB+bi JmHiB+bi
J* 7`K2 >QK2 A. aQm`+2 A. G2M;i? .i TvHQ/ *?2+FbmK
+QMi`QH +QMi`QH #Bi KbF
+MH R 2i k
9 R k R R R kN k
JmHiB+bi
6`K2 a2[m2M+2 JmHiB+bi JmHiB+bi
J* 7`K2 >QK2 A. aQm`+2 A. G2M;i? .i TvHQ/ *?2+FbmK
+QMi`QH MmK#2` +QMi`QH #Bi KbF
+MH j

TTHB+iBQM
>2/2` *QKKM/ *Hbb *QKKM/ S`KR S`Kk S`KXXX S`KM
7`K2

6B;m`2 k, 6Q`Ki Q7  w@qp2 7`K2X

3 3 3 3 3 3 3 3
:2M2`B+ .2@ aT2+B}+ .2@ *QKKM/ XXX *QKKM/
LA6 *T#BHBiv a2+m`Biv _2b2`p2/ "bB+ .2pB+2 *Hbb
pB+2 *Hbb pB+2 *Hbb *Hbb R *Hbb M
 Q7 i?2 `2+2BpBM; /2
Z-­‐wave  frame  example:  SWITCH_BINARY k9VX h?2 +QKKM
PACKET RECEIVED M/ pHm2 Uyt77, P
Packet: 01 00 00 00 00 00 00 00 de ad be ef 01 51 08 0d 18 25 01 ff 49
bmK- `2[m2bib i?2
###[ Gnuradio header ]### brBi+?2/ QMX
proto = ZWave
rfu1 = 0
channel = 0
rfu2
version
= 0
= 0
kXj SB`BM; T
preamble = 0
rf_psnr = 0
extended = 0
*QMi`QHH2`
###[ ZWaveReq ]###
homeid = 0xdeadbeef
src = 0x1
aHp2 BM+HmbBQM
routed = 0L
ackreq = 1L arBi+?BM; iQ BM+HmbB
lowpower = 0L
Frame control

speedmodified= 1L
headertype= 1L LA6 @ LQ/2 AM7Q
reserved_1= 0L
beam_control= 0L
// bHp2 BM K2KQ
reserved_2= 0L
seqn = 8L a2M/BM; BM7Q`K
length = 0xd
dst = 0x18
AM+HmbBQM BM
cmd_class = SWITCH_BINARY
crc = 0x49
###[ ZWaveSwitchBin ]### LA6 iQ +
cmd = SET
###[ Raw ]###
load = '\xff' aHp2 BM+Hm/2/
 aBM;H2+bi

Inclusion  of  a  device  in  a  Z-­‐wave  network

6`K2 .2biBMiBQM
J* 7`K2 >QK2 A. aQm`+2 A. G2M;i? .i TvHQ/ *?2+FbmK
+QMi`QH A.
+MH R 2i k
9 R k R R R k
aBM;H2+bi
6`K2 a2[m2M+2 .2biBMiBQM
J* 7`K2 >QK2 A. aQm`+2 A. G2M;i? .i TvHQ/ *?2+FbmK
+QMi`QH MmK#2` A.

>Qr2
+MH j
*QMi`QHH2` JmHiB+bi
9 aHp2
R k R R kN R Q` k
6`K2 JmHiB+bi JmHiB+bi
J* 7`K2 >QK2 A. aQm`+2 A. G2M;i? .i TvHQ/ *?2+FbmK
+QMi`QH +QMi`QH #Bi KbF
+MH R 2i k
9 R k R R R kN k

Ç bb
JmHiB+bi
6`K2 a2[m2M+2 JmHiB+bi JmHiB+bi
J* 7`K2 >QK2 A. aQm`+2 A. G2M;i? .i TvHQ/ *?2+FbmK
+QMi`QH MmK#2` +QMi`QH #Bi KbF
aHp2 BM+HmbBQM +MH j

arBi+?BM; iQ BM+HmbBQM KQ/2

TTHB+iBQM
7`K2
>2/2` *QKKM/ *Hbb
arBi+?BM; iQ BM+HmbBQM KQ/2
*QKKM/ S`KR S`Kk S`KXXX Ç a2i S`KM

LA6 @ LQ/2 AM7Q`KiBQM 6`K2

6B;m`2 k, 6Q`Ki Q7  w@qp2 7`K2X pH
3 3 3 3 3 3 3 3

hQ Qp
:2M2`B+ .2@ aT2+B}+ .2@ *QKKM/ XXX *QKKM/
LA6 *T#BHBiv a2+m`Biv _2b2`p2/ "bB+ .2pB+2 *Hbb
pB+2 *Hbb pB+2 *Hbb *Hbb R *Hbb M

// bHp2 BM K2KQ`v

a2M/BM; BM7Q`KiBQM *QKKM/

3
*QKKM/ *Hbb XXX
3
*QKKM/ *Hbb *QKKM/ *Hbb t
3 3
*QKKM/ *Hbb BM i?2 7
XXX
3
*QKKM/ *Hbb

+QMi`QHH
+Hbb2b R UamTTQ`iV t@R UamTTQ`iV U*PJJL.n*GaanJ_EV tYR U*QMi`QHV M U*QMi`QHV

6B;m`2 j, 6Q`Ki Q7  LQ/2 AM7Q`KiBQM 6`K2 ULA6VX

AM+HmbBQM BM7Q`KiBQM
KFBM; i?2 +QMi`QHH2` r`2 Q7 r?i +QKKM/b `2 +m`BivX
BM T?b2
LA6 iQ
pBH#H2 7Q` i?Bb /2pB+2X
h?Bb KF2b  w@qp2 M2irQ`F 2ti`2K2Hv `Q#mbi
+QM}`K
w@qp2 b2+m`Biv iF2b TH+2 i /Bz2`2Mi H2p2HbX
h?2 >QK2A. B/2MiB}2b  M2irQ`F M/ Bi Bb mb2/ #v `2HvBM;
Q` 2p2M
;BMbi iQTQHQ;v KQ/B}+iBQMbX ai`iBM; rBi?  bBK@ 2p2`v /2pB+2b Q7 i?2 bK2 M2irQ`F iQ +QKKmMB+i2
TH2 HBbi Q7 `2;Bbi2`2/ MQ/2b-  +QMi`QHH2` Bb #H2 iQ #2ir22M 2+? Qi?2`bX hQ #2 T`i Q7  w@qp2 M2i@
AM+Hm/2/
/Bb+Qp2` i?2 +T#BHBiB2b Q7 HH MQ/2b- M/ ?Qr MQ/2b BM rQ`F-
i?2 M2irQ`F
 /2pB+2 M22/b iQ #2 BM+Hm/2/ #v mbBM; i?2

aHp2 BM+Hm/2/
`2 T?vbB+HHv Q`;MBx2/X TB`BM; T`Q+2bb- r?B+? `2[mB`2b M 2tTHB+Bi +iBQM QM
i?2 M2irQ`FǶb +QMi`QHH2`X #+FmTf
7Q` `2HB
kX8 w@qp2 b2+m`Biv PM+2 i?2 /2pB+2 Bb T`i Q7 i?2 M2irQ`F- i?2 +QM@
i`QHH2` +M b2M/ +QKKM/b iQ BiX AM bT2+B}+ +b2b-
w@qp2 /2pB+2b `2 Q7i2M +HQb2Hv `2Hi2/ iQ i?2 mb2` bQK2 /2pB+2b +M +QKKmMB+i2 /B`2+iHv #2ir22M
+iBpBiv #v #2BM; T`i Q7 ?QK2 miQKiBQM bvbi2KbX 2+? Qi?2`b- #mi i?2v biBHH ?p2 iQ #2 T`i Q7 i?2
h?2`27Q`2- i?2v ;i?2` T2`bQMH BM7Q`KiBQM- M/ bK2 M2irQ`FX "v /27mHi- i?2 +QKKmMB+iBQM Q+@
Z-­‐wave  identifiers
Home  ID  is  written  to  the  controller's  Z-­‐Wave  chip  by  the  manufacture  and  can  not  be  
changed  by  the  controller  software  :  32  bits  -­‐>  4  billions   of  devices
Node  ID  :  8  bits  -­‐>  256  devices
Z-
Wave

nodeI
D↵:5

nodeI
D↵:4
HomeID↵:1EC3D367
nodeI
D↵:1

nodeI
D↵:3

nodeI
D↵:2
nodeI
D↵:6
Loï
cROUCH–Sécur
itédesobj
etsconnect
és 31 août 2016 - 20
 Z-­‐wave  security
Message Freshness:
64-bit Nonce
128-bit Random Network Key: Kn

Encryption:
AES-OFB Custom
Key Establishment Protocol

Data Authentication:
AES-CBCMAC
128-bit Cipher & MAC 
Keys: Derived From Kn

Source:  slide  of  Fouladi et  al,  Honey,  I’m  Home:  Hacking  Z-­‐wave  Home  Automation   Systems,  
BlackHat USA  2013
 Z-­‐wave  communications  security
• Home  ID  for  network  authentication
• Checksum  computation  to  detect  and  discard  erroneous  frames
• Z-­‐wave  secure  communications
• Security  Command  Class  V1    
• encapsulate  packets  into  secure  container,  every  communication  
is  protected  by  a  single  Nonce  (one  time  password)
• AES  128  bits  encryption  in  the  chip  (hardware)

Reference:  Fouladi et  al,  Security  Evaluation  of  the  Z-­‐wave  Wireless  Protocol,  Black  Hat  USA,  2013
ault key in chip’s firmware before being sent to ,15C.,#<%=14.#:995#09;A#,9#1#A29B2#410E.#9D#-*+#;-9*;.#

Z-­‐wave  key  exchange

The value of this temporary key was found to be
ero. Although an attacker could intercept the
,-.2#*++E.#E21E,-95*+.:#;9>>12:+@##

exchange frame, and decipher it using the hard-

• K generated  using  PRNG  
n
attack vector was not interesting to us, as the
(hardware  based  pseudo  random  
only happens at system initial setup time or re-
t limits the attack time window. Furthermore Z-
generator)
can switch their radio to low power transmission
ey exchange process to make packet interception
• Encrypted  using  the  hard  coded  
ore difficult.
default  key  in  the  chip
ssful exchange of the network key (!! ) between
ppliance and the door lock, they both derive two
• Controller  and  device  derive  two  
eys: frame encryption key (!" ) and data origin
new  128-­‐bits  keys  
key (!# ) by using AES encryption in ECB
wing:
• Frame   encryption  key  Kc  =  AES-­‐ Encrypt  &  MAC  by  K0
ECB#Kn" (passwdc)
#%&$! !'())*+ ""
#%&$! !'())*+
'())*+•# Data  
values o rigin  
were authentication  
found to be 16-byte key  Km=
ded into the AES-­‐
Z-WaveECB Kn(passwd
firmware m)
as highlighted in
• 64-­‐bit  nonce  value  is  generated  by  
g message the   chip code (CBC-MAC)
ta origin authentication is based on the cipher
authentication
• Authentication  
can calculate header  
a message authentication is  computed  
code
MAC  
a block cipher =  AES-­‐such as AES. The
algorithm
Encrypt  &  MAC  by  Kn
CBCMACkm(IV,SH|SRC|DST|LEN|C)
C value ensures that the Z-Wave frame is not
h or corrupted during the transmission (data
hat it has been sent by the node claiming to be
ource (origin authentication). In order to prevent
 Vulnerability  analysis  and  exploitation  in  
Z-­‐wave  networks
• Two  approaches
• Bottom-­‐up:  packet  capture  and  injection  attacks
• Top-­‐down:  exploitation  of  Z-­‐wave  gateways
• Packet  injection  attacks
• Enable  an  attacker  to  masquerade  as  a  legitimate  user
• Publicly  available  tools:  Z-­‐force  (not  open  source),  scapy-­‐
radio,  AFIT  Sniffer,  EZ-­‐wave
• Gateway  attacks  
• Exploit  vulnerabilities  discovered  in  Z-­‐Wave  gateways:  lack  of  
user  authentication,  lack  of  encryption,  and  open  ports
• Insert  a  rogue  controller  to  gain  access  to  Z-­‐wave  network
Rogue  Z-­‐wave  controllers
• Reconnaissance  of  each  device:  default  settings  and  
modes  of  operations  are  identified
• Scanning  of  open  ports  :  Web,  SSH
• Examines  vulnerabilities  in  the  device  implementation
• Low  HTTP  authentication,  backup  files  to  reimage  the  system  
and  retrieve  passwords
• Exploits  a  new  vulnerability  to  create  a  persistent  attack  
channel  by  injecting  a  rogue  controller  in  the  Z-­‐Wave  
network
• Put  the  primary  controller  in  inclusion  mode  using  a  crafted  
HTTP  packet
• Replicate  the  primary  controller  to  build  a  rogue  one
• Delete  the  log  entries  from  the  UI
• Transmit  commands  to  the  devices  bypassing  the  gateway
Reference:  Fuller  et  al,  Rogue  Z-­‐Wave  Controllers:  A  Persistent  Attack  Channel,  
in  2015  IEEE  40th  Local  C omputer  Networks  Conference  Workshops   (LCN  Workshops)
Information  hiding  in  the  Z-­‐Wave  MAC  frame
available to hide information at R1 and R2 are less than half of R3.

Singlecast MAC frames includes the home ID, source ID, frame control, length, and destination ID totalling 9B
(Figure 2 and 3). A one byte non-correcting frame checksum is used to validate the MAC frame for data rates R1
• Hide  information  in  the  MAC  frame  at  rates  R1  and  R2  
and R2 (2B are used for R3). Given our channel configuration, we know that the frame checksum of messages
supported in our experimental Z-Wave network is one byte. Thus, there are 54B remaining for the MSDU (frame
(64B)payload). A similar calculation can be done to discover the maximum payload length of the multicast frame
(Figure 3). There are 39B used in the multicast frame excluding the MSDU. Therefore, the MSDU is 25B.

Figure 3: MAC layer frame structure: (a) singlecast frame and (b) multicast frame
• MSDU:   variable  length  (payload  information)
3.1 Space available to hide information

• Basic  
command command   class:  
class being sent to a device SET,  network.
in the Z-Wave GET,  
The R EPORT  
command (known  
class determines length)
The MSDU field has a variable length and contains the frame payload information. The length depends on the
the function that
to be performed by a device. One example is the Basic command class which is supported by all Z-Wave
•needs
Determine  
devices. available  
The Basic command bytes  
class uses three remaining
commands: SET to turn a device on or off, GET to request a device
status, and REPORT to respond to a request.
• Attacker   can  hide  up  to  51B  in  a  singlecast frame  and  up  
Since we know that all devices, including the controller, will accept messages containing the Basic command
to  class
2 2B   in  
(RaZberry a  
Project m ulticast  
n.d.), f rame
we can determine the length required in the MSDU for the Basic command class
portion of the payload. This will allow us to determine available bytes remaining.

The representation of the Basic command class in the MAC frame is 0x20. The byte field following is dependent
upon the command SET (0x01), GET (0x02), or REPORT (0x03). In either case, the payload length needed to
support the Basic command class is at least 3B. Since all Z-Wave devices support the Basic command class, an
attacker can hide up to 51B of data in a singlecast MAC frame and up to 22B in a multicast MAC frame. When
the Z-Wave transceiver receives a packet, the header and EoF are stripped away as the packet moves up the
protocol stack. Once at the application layer, the command class function is executed and the injected bytes
 Z-­‐wave  covert  channel:  information  hiding
• Gain  access   to  the  Z-­‐wave  gateway  by  using  a   rogue  
controller  technique  (Fuller   JonathaneFuller
t  Ramsey,2015)
et al.

• Attacker   c rafts  
time (our experiment Z -­‐Wave  
- ten minutes). Whenp ackets  
re-access to thecZ-Wave
ontaining   h idden  
network is needed, the attacker executes a
Secure Shell (SSH) server on their machine. Using Scapy-Radio, the attacker crafts a Z-Wave packet containing
information
hidden information and transmits the packet to the Z-Wave gateway using a Software-Defined Radio (SDR). To
ensure the injected packet is accepted by the Z-Wave network, the attacker first captures a Z-Wave packet and
• Transmit  them  using  a  Software-­‐Defined  radio  (SDR)  and  scapy-­‐
extracts the home ID using it to construct the packet similar to Figure 4. The attacker follows the ITU-T G.9959
radio.
8-bit checksum algorithm and calculates the checksum before injection.

Figure 4: MAC frame consisting of (a) home ID, (b) source ID, (c) frame control, (e) length, (e) destination ID, (f)
basic command class, command, and payload, (g) hidden information in MSDU, and (h) checksum

• A  The
r unning   script  on  the  gateway  scans  for  any  injected  
key to this attack is locating Z-Wave packets on the gateway controller. The RaZberry Pi keeps a detailed log
that contains all actions on the Z-Wave network. Once awake, the Python script scans the log file for any injected
packet
packet containing the hidden information. The injected packet contains a marker [FE FE] in the MSDU (Figure
4.g). This marker is used because it is unlikely that a standard Z-Wave packet will contain consecutive bytes [FE].
• Dissects  the  packet  
Upon identification, the Python script dissects and  retrieving   the   needed  information,  
the packet retrieving for  ethe
needed information including xample  
attack
attack   type   ( ping   o f  D eath,   d eny  service)
type [01] and IP address [A2-56-C0-05] (Figure 5). Any attack type can be added depending on the needs of the
Clears  include
attacker.•Examples the   lPing
og   fofile  
Death   to deny service or Reverse File Transfer to retrieve the /etc/passwd file
or other important files.
• Counter-­‐measure:  misuse-­‐base  introduction  detection  by  
monitoring  Z-­‐wave  frames
Reference:  Fuller  et  al,  Wireless   Intrusion  Detection  of  Covert  Channel   Attacks  in  I TU-­‐T  G.9959-­‐Based  Networks,  
in  the  Eleventh  I nternational  Conference  on  Cyber  Warfare  and  Security,  pp  137-­‐45,  March  2016.  
https://github.com/AFITWiSec/MBIDS
Some  useful  tools  for  Z-­‐wave  security  
analysis
• Scapy-­‐radio  (https://bitbucket.org/cybertools/scapy-­‐
radio/src):  built  upon  Gnu  radio  and  Scapy for  pentesting for  
RF-­‐based  protocols
• Packets  sniffing  and  injection  using  scapy library
• EZ-­‐Wave  (https://github.com/AFITWiSec/EZ-­‐Wave  ):  set  of  tools  built  
upon  Scapy-­‐radio.  Three  python  based  tools:  EZStumbler,  
EZFingerprint,  EZRecon.
• EZStumbler:  passive  and  active  scanner  for  discovering  and  
enumerating  Z-­‐wave  networks
• EZFingerprint:  identify  the  manufacture,  product  name  and  firmware  
versions
• EZRecon:  status  information  from  a  target,  sensor  reading,  
configuration  settings
• Z-­‐attack  (https://github.com/advens/Z-­‐Attack  ):  Z-­‐wave  packet  
interception  and  injection  using  RfCat USB  dongle
• Z-­‐force  (https://code.google.com/archive/p/z-­‐force/):  
intercept  and  decrypt  Z-­‐wave  keys
 What(is(BLE(
Bluetooth  Low  Energy  (BLE)  protocol
•  BLE(is(part(of(Bluetooth(SIG(specificaGon,(IEEE802.15.1(
V4.0+(standard,(since(2010(
•  BLE(is(very(different(from(classic(Bluetooth,(so(it(can(
almost(be(considered(as(another(stand3alone(standard(
•  BLE(is(one(of(the(Low(power(networking(technology(for(
enabling(IoT(
–  Output(power:(10mW((10dBm)(
–  Maximum(current:(15mA(
–  Sleep(current:(1(µA(
–  Robust(physical(layer:(AdapGve(frequency(hopping(
–  Topology:(star(

2(
 Where is BTLE?
BLE  devices
⇀ High end smartphones
⇀ Sports / fitness devices
⇀ Door locks
⇀ Upcoming medical devices

Mike Ryan Bluetooth Smart / Bluetooth LE USENIX WOOT, August 2013

 Building(your(BLE(applicaGons(
BLE  applications
•  ApplicaGons(
–  Host(applicaGons(that(use(nearby(Low(Energy(devices((
–  Web(applicaGons(that(use(remote(Low(Energy(devices((
•  Devices(
–  Use(new(Profiles(from(the(SIG((
–  Define(proprietary(profiles((
•  Define(the(aeributes(of(the(device((Services,(CharacterisGcs,(
Descriptors,(behavior)(
•  Define(proprietary(163byte(UUIDs(for(these(aeributes((

26(
BLE  adoption By The Numbers
⇀ 186% YoY Growth for H1 20131
⇀ “over 7 million Bluetooth Smart ICs were estimated to
have shipped for use in sports and fitness devices in
the first half of 2013 alone”
⇀ “Analysts Forecast Bluetooth Smart to Lead Market
Share in Wireless Medical and Fitness Devices” 2

1
http://www.bluetooth.com/Pages/Press-Releases-Detail.aspx?ItemID=170
2
http://www.bluetooth.com/Pages/Press-Releases-Detail.aspx?ItemID=165

Mike Ryan Bluetooth Smart / Bluetooth LE USENIX WOOT, August 20

 Bluetooth  versus  BLE
• BLE:  completely  different  than  
previous  Bluetooth
• Range
• Data  rate
• Latency
• Power  consumption
Protocol  BLE(protocol(stack(
stack
What are the pieces?
Applications = Profiles & Services Apps

Generic Access Profile

Generic Attribute Profile
Host
Attribute Protocol Security Manager
L i l Link
Logical Li k Control
C t l & Adaptation
Ad t ti Protocol
P t l
Host Controller Interface
Link Layer Direct Test Mode
Controller
Physical Layer

4(
 Although some of the BLE Controller features are inherited from the class
BLE  packet  format
both types of Controller are currently incompatible. Hence, a device that only i
[C.(Gomez(et(al.,(MPI(Sensors(journal(2012,(vol12](
is referred to as a single-mode device) cannot communicate with a device that
Bluetooth. It is expected that many devices will implement both the classic
protocol stacks. These devices are called dual-mode devices.

A(sniffer(view(
2.2. Physical Layer
A(sniffer(view(
BLE operates in the 2.4 GHz Industrial Scientific Medical (ISM) band
Frequency (RF) channels with 2 MHz channel spacing. There are two type
hadvertising
some of thechannels and data
BLE Controller channels.
features Advertising
are inherited from thechannels
classicare used
Bluetooth
connection
f Controllerestablishment
are currently and broadcast transmission,
incompatible. Hence, a device whereas dataimplements
that only channels a
[C.(Gomez(et(al.,(MPI(Sensors(journal(2012,(vol12]( 5(

ocommunication
as a single-mode between connected
device) devices.
cannot communicate with a device that only implem
t isThree
expectedchannels are defined
that many devicesaswilladvertising
implement channels.
both theThese
classicchannels hava
Bluetooth
frequencies that minimize
cks. These devices overlapping
are called dual-modewith IEEE 802.11 channels 1, 6 and 1
devices.
used in several countries.
An adaptive frequency hopping mechanism is used on top of the data ch
l[source:(TI(CC2540(USB(dongle(BLE(sniffer(quide:(
Layer
hep://processors.wiki.G.com/index.php/BLE_sniffer_guide#AdverGsement_packets](
6(
 PHY Layer
BLE  Physical  layer
⇀ GFSK, +/- 250 kHz, 1 Mbit/sec avoid  interference  
Physical Channels with  Wi-­‐Fi  
⇀ 40 channels in 2.4 GHz channels

⇀ Hopping
⇀ Advertising: 3 channels
⇀ Data: 37 channels

Mike Ryan Bluetooth Smart / Bluetooth LE USENIX WOOT, August 2013

BLE  hopping Hopping
⇀ Hop along 37 data channels
⇀ One data packet per channel
⇀ Next channel ≡ channel + hop increment (mod 37)
⇀ Time between hops: hop interval

3 → 10 → 17 → 24 → 31 → 1 → 8 → 15 → …
hop increment = 7
BLE  link  layerBLE(Link(layer(
•  Two(device(types:(Peripheral((e.g.(sensors)(and(Central(
(e.g.(smartphone,(tablet,(PC)(
•  Four(device(roles:(AdverGser,(Scanner,(Master,(Slave(
•  Two(forms(of(BLE(device(address:(63bytes(public(unique(
MAC(or(randomly(generated(one(
•  Two(communicaGon(modes:((
–  AdverGsing(and(scanning((on(adverGsing(channels)(
•  AdverGser(broadcasGng(data(without(establishing(connecGon(
•  Master(for(discovering(slaves(and(to(connect(to(them(
–  ConnecGon((TDMA)(using(data(channels(
•  ConnecGon(establishment:(a(master(scans(for(detecGng(adverGsing(
slave,(then(sends(connecGon(request,(slave(responds,(connecGon(
established(
•  Data(exchanges(between(the(slave(and(the(master(at(predefined(
Gmes((duty3cycle)(
8(
9(
10(
 BLE  link  layer
BLE(link(layer(
Bluetooth Low Energy and Bluetoo
One(packet(format(and(two(PDU(types:(
om
• 
Data Packet
AdverGsing(and(data((
The transmitted data from a Bluetooth low energy device is formatted according to the Bluetooth Co
Specification and is comprised by the parts shown in Figure 1.

Figure 1. Bluetooth Low Energy Data Packet

The Preamble is a 1 byte value used for synchronization and timing estimation at the receiver. It wi
always be 0xAA for broadcasted packets. The Access Address is also fixed for broadcasted packet
11(
o 0x8E89BED6. The packet payload consists of a header and payload. The header describes the p
 How doesait
Advertising   work:
nd  s advertising
canning
AdverGsing(and(Scanning(
Figure 1. Bluetooth Low 150µS
Energy Data Packet
150µS

< 10mS < 10mS

value Periph.
used for synchronization
ADV_IND and timing estimation
ADV_IND SCAN_RSP at the receiver. It will
ADV_IND
casted packets. The Access Address is also fixed for broadcasted packets, set
et payload consists of a header and payload. The header describes the packet
finesCentral
the purpose of the device. ForSCAN_REQ
broadcasting applications, there are three
hown in Table 1. ADV_IND and ADV_NONCONN_IND have been described
and non-connectable) while ADV_SCAN_IND is simply a non-connectable
Channel 37 Channel 38 Channel 39
de additional information by scan responses.
Advertising event T_advEvent
ble 1. Advertising PDU Types for Broadcasting Data
Devices can advertise for a variety of reasons:
Packet Name Description
• To broadcast promiscuously
ADV_IND Connectable undirected advertising event
• To transmit signed data to a previously bonded device
ADV_NONCONN_IND Non-connectable undirected advertising
• To advertise their presence to a device wanting to connect
event
• To reconnect asynchronously due to aScannable
ADV_SCAN_IND local event
undirected advertising event

hether the advertisers address (contained in the Payload) is public (TxAdd = 0)

xAdd is reserved for other types of packets not covered in this application note, 12(
cons.
 AdverGsing(packet(types(
Advertising  
packet  types
•  Connectable:(a(scanner(can(iniGate(a(connecGon(upon(
recepGon(of(an(adverGsing(packet(
•  Non3connectable:(a(scanner(cannot(iniGate(a(
connecGon((only(for(broadcasGng)(

•  Scannable:(can(issue(a(scan(request(
•  Non3scannable:(cannot(issue(a(scan(request(

•  Directed:(only(for(a(given(scanner((no(user(data)(
•  Undirected:(not(targeted(at(any(parGcular(scanner((can(
contain(user(data)(

13(
How does it work: data
Advertising  
a nd  c onnection
AdverGsing(and(connecGon(
transactions
> 1.25mS
150µS

Periph.
ADV_IND Slave

Etc.

C t l
Central
CONNECT_REQ Master Master

Channel 37 Data Channel

Advertising event Connection event

Once(a(connecGon(is(established:(
nce a connection is made:
3  Master(informs(slave(of(hopping(sequence(and(when(to(wakeup(
3  TransacGons(are(performed(in(the(37(data(channels(
Master informs slave of hopping sequence and when to wake
3  TransacGons(can(be(encrypted((AES3128)(
All subsequent transactions are performed in the 37 data chann
3  Both(devices(can(go(into(sleep(between(transacGons(
3  ConnecGon(interval:(7.5ms(to(4s(
Transactions can be encrypted
14(
B th d
Both devices
i can go iinto
t ddeep sleep
l b
between
t ttransactions.
ti
 ATT((Aeribute(Protocol)(
ATT:  Attribute  protocol
•  Client3server(model:(client(requests(data(and(
server(sends(data(to(clients(
•  Server(contains(data(organized(in(forms(of(
Aeributes(
•  Each(aeribute(has((
–  a(163bit(handle,((
–  a(1283bit(UUID((Universal(Unique(ID,(for(type(and(
nature(of(data(value),(can(be(shortened(to(16(or(32(
bits,(Standardized'by'ISO/IEC'9834<8:2008'
–  a(set(of(permissions(
–  a(value(

15(
Example  oExample(of(aeributes(
f  attributes

Value'
Handle'' Type'' Permissions'' Value''
length'
0x0201( UUID1((163bit)( Read(only,(no(security( 0x180A( 2(
0x0202( UUID2((163bit)( Read(only,(no(security( 0x2A29( 2(
Read/write,(
0x0215( UUID3((163bit)( “a(readable(UTF38(string”( 23(
authorizaGon(required(
0x030C( UUID4((1283bit)( Write(only,(no(security( {0xFF,(0xFF,(0x00,(0x00}( 4(
Read/write,(
0x030D( UUID5((1283bit)( authenGcated(encrypGon( 36.43( 8(
required(
0x031A( UUID1((163bit)( Read(only,(no(security( 0x1801( 2(

16(
 GATT((Generic(Aeribute(Profile)(
GATT:  Generic  Attribute  Profile
•  Dealing(with(data(exchange(in(BLE,(GATT(
defines(a(basic(data(model(and(procedures(to(
allow(devices(to(discover,(read,(write,(and(
push(data(elements(between(them.(It(is,(in(
essence,(the(topmost(data(layer(of(BLE.(
•  Data(is(organized(hierarchically(in(secGons(
called(services,(which(group(conceptually(
related(pieces(of(user(data(called(
characteris/cs.(

17(
GATT  client GATT(client(
•  The(GATT(client(corresponds(to(the(ATT(client.(It(
sends(requests(to(a(server(and(receives(
responses((and(server3iniGated(updates)(from(it.(
The(GATT(client(does(not(know(anything(in(
advance(about(the(server’s(aeributes,(so(it(must(
first(inquire(about(the(presence(and(nature(of(
those(aeributes(by(performing(service(discovery.(
Auer(compleGng(service(discovery,(it(can(then(
start(reading(and(wriGng(aeributes(found(in(the(
server,(as(well(as(receiving(server3iniGated(
updates.(

18(
GATT  server GATT(server(
•  The(GATT(server(corresponds(to(the(ATT(server.(It(
receives(requests(from(a(client(and(sends(
responses(back.(It(also(sends(server3iniGated(
updates(when(configured(to(do(so,(and(it(is(the(
role(responsible(for(storing(and(making(the(user(
data(available(to(the(client,(organized(in(
aeributes.(Every(BLE(device(sold(must(include(at(
least(a(basic(GATT(server(that(can(respond(to(
client(requests,(even(if(only(to(return(an(error(
response.((

19(
GATT  data  ATT/GATT
hierarchy(extra)
⇀ Services: groups of characteristics
⇀ Characteristics
⇁ Operations
GATT(data(
⇀ Everything identified by UUID

⇁ 128 bit
hierarchy(
⇁ Sometimes shortened to 16 bits

55
55

Mike Ryan Bluetooth Smart / Bluetooth LE USENIX WOOT, August 2013

20(
Example  GATT  service:  Heart  Rate

21(
GAP:  GAP((Generic(Access(Profile)(
Generic  Access  Profile
•  Covering(the(usage(model(of(the(lower3level(
radio(protocols(to(define(roles,(procedures,(
and(modes(that(allow(devices(to(broadcast(
data,(discover(devices,(establish(connecGons,(
manage(connecGons,(and(negoGate(security(
levels,(GAP(is,(in(essence,(the(topmost(control(
layer(of(BLE.(This(profile(is(mandatory(for(all(
BLE(devices,(and(all(must(comply(with(it.(

23(
BLE  sniffing informaGon(
•  CC2540(USB(Dongle(and(SmartRF(sniffer(
(coupled(with(wireshark)(
•  For(Linux,(Bluez(Bluetooth(stack,((
–  hcitool(for(scaning(and(connecGng(to(BLE(devices(
–  Gaetool(for(interacGng(with(GATT(services((read,(
How do we sniff it?
write(characterisGcs)(
–  Example:(scan(for(BLE(devices(in(rang:(
Start at the bottom and work our way up:
•  sudo(hcitool(3(i(hci0(lescan(
→ GATT
PC → 22(
ATT
→ L2CAP
→ Link Layer
Ubertooth
→ PHY
Mike Ryan Bluetooth Smart / Bluetooth LE USENIX WOO
Ubertooth block  d iagram
Ubertooth Block Diagram
Capturing  Physical  layer

PHY layer Link layer

RF↔Bits Bits↔Packets

CC2591 RF CC2400 Bits LPC175x

RF Amp Radio ARM MCU

Packets

USB
 Capturing  packets  to  PCAP

More  details:  https://github.com/greatscottgadgets/ubertooth/wiki/Capturing-­‐BLE-­‐in-­‐Wireshark  

 “encrypting”) and signing options for the
Interception of transmitted data is also possible by
BLE  possible  attacks
broadcasted values. The advertised packets change
their values with predefined frequency, and the
value is possible to “decode” only using the
active attack, using the newly introduced tool.

• Attacks  on  advertisements

vendor's mobile application. However, such
mechanisms have to overcome several limitations -
4.2.1. Example vulnerabilities

Smart finder
• Advertisement  spoofing:  spoof  aAnnd  
on both the hardware and software side, as well as
compromise for offline usage requirements. As
advertise  
example them  device
“smart finder” with  
implemented
configurable  interval
vendors guard the “shuffling” algorithm’s technical
authentication in a form of a static 6-digit password
sent from the mobile application to the device in
details in the way of top-secret intellectual
• Denial  of  service:  advertise  a  cloned  
property, it may raise concerns whether the device
cleartext form characteristic write. A screendump
below presents the password (‘123456’) intercepted
mechanism was properly reviewed by a professional
using the GATTacker tool:
• Passive  interception
cryptographer.
Depending on the level of risk, the ideal solution
would be to not rely on received advertisement
• Unencrypted  transmission  can  be  intercepted  by  a  passive  
packets for critical functionality.
eavesdropper

• Active  interception
• Attacker  invoked  connections  with  the  device  and  the  mobile  
application,  and  relays  messages  between  them:  Man  in  the  
middle  (MiTM) 7

• Attacks  on  pairing

• Attack  the  pairing  process  to  guess  the  Long  Term  key  
BLE  security Encryption
• Encryption
⇀ Provided by link layer
⇀ Encrypts and MACs PDU
⇀ AES-CCM

↓↓↓↓↓↓

• Random  MAC  address

• Prevent  tracking  by  changing  the  MAC  of  the  device  on  a  
frequent  basis. 35
• Whitelisting
Mike Ryan Bluetooth Smart / Bluetooth LE USENIX WOOT, August 2013

• Create  a  whitelist  of  accepted  devices’  MAC  addresses.

BLE  encryption
BLE (v4.0) security: encryption
• Pairing (once, in a secure environment)
• JustWorks (R) – most common, devices without display cannot implement
other
• 6-digit PIN – if the device has a display
• Out of band – not yet spotted in the wild
• "Just Works and Passkey Entry do not provide any passive
eavesdropping protection"
• Establish Long Term Key, and store it to secure future communication
("bonding")

Mike Ryan, https://www.lacklustre.net/bluetooth/

BLE  encryption:  key  exchange
• BLE  uses  AES-­‐CCM:  no  known  practical  attacks
• Master  and  slave  establish  a  shared  secret  known  as   Long  
Term  Key  (LTK)
• Could  be  reused  for  future  sessions
And That's It
• Master  and  slave  select  a  temporary  key  (TK),  128  bits  AES  key
⇀ TK → STK
⇀ STK → LTK
⇀ LTK → Session keys
• The  TK  is  used  to  compute  a  “confirm”  value:  all  used  values  
for  its  computation  are  in  plaintext  over  the  air.
• After  that  the  master  and  slave,  compute  a  short-­‐term  key  
KEY EXCHANGE = BR0KEN
(STK),  and  finally  an  LTK.
• The  STK  exchange  messages   are  encrypted  using  the  TK  
 Cracking  the  TK
• Brute  force  algorithm  to  guess  TK
Cracking
• Calculate  the  confirm   the
for  every   TK TK  value  between  0  
possible  
and  999  999
• Find  the  TK  whose  confirm  matches  the  values  exchanged  
over  the  air.
confirm
=
AES(TK, AES(TK, rand XOR p1) XOR p2)

GREEN = we have it
RED = we want it

TK: integer between 0 and 999,999

Just WorksTM: always 0!
37
With  crackle:  Time  to  crack  <  1  second
Mike Ryan Bluetooth Smart / Bluetooth LE USENIX WOOT, August 2013

Reference:  Mike  Ryan,  Bluetooth:  With  Low  Energy  comes  Low  Security,  USENIX  WOOT,  2013
Cracking  the  TK:  mitigations
• If  the  master  and  slave  established  the  LTK  key  they  
need  not  re-­‐establish  a  key  
• But  we  can  forces  a  key  renegotiation  by  injecting  a  
specific  link  layer  message  (LL_REJECT_IND)
• Each  encrypted  session  uses  a  session-­‐specific  nonce  
exchanged  at  the  beginning  of  the  session
• Therefore  even  if  the  LTK  is  known,  if  the  session  
initialization  is  not  captured  the  conversation  cannot  
be  decrypted.  
• We  can  jam  the  connection,  which  forces  the  master  
and  slave  to  reconnect  and  re-­‐establish  a  secure  
session,  al-­‐ lowing  us  to  sniff  the  nonce.  
BLE  (v4.0)
BLE encryption  
securityin  
inppractice
ractice
• 8 of 10 tested devices do not implement BLE-layer encryption
• "Forget" to do it, or do not consider clear-text transmission a problem
• The pairing is in OS level, mobile application does not have full control over it
• It is troublesome to manage with requirements for:
• Multiple users/application instances per device
•
•
Access sharing
Cloud backup
Am I Affected?
• Public access devices (e.g. cash register)
•⇀ Probably
Other hardware/software/UX problems with pairing

⇀ Exception: Some vendors implement their own

security on top of GATT
⇁ Did they talk to a cryptographer?
BLE  security  in  practice
BLE (v4.0) security in practice
Host (OS)
• Security in "application" layer (GATT)
• Various authentication schemes GATT

• Static password/key SMP ATT

• Challenge-response (most common)
• PKI L2CAP

UNENCRYPTED
• Own crypto, based usually on AES Host Card Interface

• No single standard, library, protocol Link layer

Physical layer

Controller (firmware)
 How  to  attack  the  BLE  car  lock?
So, how to attack the BLE car lock?
• Remote relay?

Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars
http://eprint.iacr.org/2010/332.pdf
 How  to  attack  the  BLE  car  lock?
So, how to attack the BLE car lock?
• Remote relay?
• Jamming?
• Brute force?

Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars
http://eprint.iacr.org/2010/332.pdf

http://greatscottgadgets.com/ubertoothone/
 How  to  attack  the  BLE  car  lock?
So, how to attack the BLE car lock?
• Remote relay?
• Jamming?
• Brute force?
• BLE sniffing?
• Mobile app
analysis?
• ...
• MITM?

http://greatscottgadgets.com/ubertoothone/
MiTM BLE  attack
• Typical  connection  flow
Typical connection flow
Start scanning for advertisements

Advertise

Specific advertisement received,

stop scanning

Connect the advertising device (MAC)

Further communication

• MiTM MITM
Start scanning for advertisements

Advertise more
frequently
Specific advertisement received,
stop scanning
MITM?
Keep connection to
original device. It
does not advertise
Connect the advertising device (MAC) while connected ;)

Further communication
MiTM attack  tool:  GATTacker
• Open  source:  https://github.com/securing/gattacker
• Node.js,  websockets
[Jasek et  al,  GATTacking bluetooth smart  devices,  Blackhat USA  2016]

New tool - architecture

Advertise
(high freq) Advertise
Gather
advertisement
and services Get serv
Get serv websockets data for
cloning
Offer exact Data services
services
services interception
and
manipulation
Keep
connection to
original device
Forward
forward
req/resp
req/resp
 Car  hacking  challenge:  authentication
Car hacking challenge: authentication

Get "Challenge"

AES("LOGIN", Random challenge

AES
(Challenge, AES("LOGIN",AES(Challenge,key))
key

Commands
NOT (Open,
ENCRYPTED: Close...)
Open, Close...
Authentication:  attack?
Authentication: attack?

Get "Challenge"

AES("LOGIN", Random challenge

AES
(Challenge, AES("LOGIN",AES(Challenge,key))
key

Close MITM Other cmd

Other commands (based on mobile app):

• initConfigMode – initiate the configuration – overwrite the keys

• initiateDataTransfer – dump the whole configuration (including all

keys)
Smart
Smart  lock
lock  protocol
• Challenge-response, session key
• Commands encrypted by session key
• Challenge looks random
• Ranging: GPS-enabled, you have to leave the area and return
Smart
• What lock
could - protocol
possibly go wrong?

Get "Challenge"

Challenge

SESSION KEY =
AES(Challenge,
Commands AES-encrypted by session key
KEY
Smart  lock  protocol
Smart lock - protocol

Get "Challenge"

Challenge MITM
SESSION KEY =
(intercept,
AES(Challenge,
Close lock
record,
KEY
pass
OK, closed
through)
Smart  lock  attack
Smart lock – attack
The same as
recorded session
Get "Challenge"

Challenge (previously intercepted)

SESSION KEY =
OK, MITM
AES(Challenge,
CLOSED!
Close lock
(replay)
KEY

OK, closed (repeat the encrypted)

Smart  lock  attack  v2
Smart lock – attack v2

Get "Challenge" MITM

Do not forward
STALL req to device.

OK,
Advertise status
CLOSED! "Closed"
Counter-­‐m easures
How to fix the problem?
• Use the BLE security features
• Encryption, bonding, MAC randomization
• Do not allow to bond automatically
• Detect MITM, warn the user
• Your own mechanisms
• Do not implement static passwords
• Design with active interception possibility in mind
• Beware excessive services, misconfiguration
• Prepare fallback for Denial of Service
• ...
• More details in whitepaper
IEEE  802.15.4  and  6LoWPAN
• IEEE  802.15.4:  Medium  Access  control  (MAC)  and  
physical  layer  (PHY)  for  low-­‐rate  wireless  private  area  
networks  (LR-­‐WPAN)
• Low  power  consumption
• Low  data  rate
• Low  cost,  high  message  throughput
• 6LoWPAN
• Adaptation  layer  that  fits  IPv6  packets  to  the  IEEE  802.15.4  
specifications
• Header  compression  to  reduce  transmission  overhead
• Compress  IPv6  headers  to  2  bytes
Low  power  radios
Low power radios
Institut für Technische Informatik | Organic Computing Group

Low-Power Radios
Radio Duty-Cycling
Turn off the radio in sleep mode
Low-power Listening

Carlo Alberto Boano <[email protected]> 26

Contiki: Radio Communication
130
 IEEE  802.15.4IEEE 802.15.4
•  Important standard for home networking,
industrial control and building
automation
•  Three PHY modes
–  20 kbps at 868 MHz
–  40 kbps at 915 MHz
–  250 kbps at 2.4 GHz (DSSS)
•  Beaconless mode
–  Simple CSMA algorithm
•  Beacon mode with superframe
–  Hybrid TDMA-CSMA algorithm
•  Up to 64k nodes with 16-bit addresses
•  Extensions to the standard
–  IEEE 802.15.4a, 802.15.4e, 802.15.5

LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 161

IEEE  802.15.4:  radio  characteristics
 IEEE  802.15.4  topologies AL-FUQAHA et al.: IOT: SURVEY ON ENABLING TECHNOLOGIES, PROTOCO
• (a)  Star  topology
• All  nodes  communicate  via  the  
central  PAN  coordinator
• Leafs  may  be  any  combination   of  
FFD  and  RFD  devices
• PAN  is  usually  having   a  reliable  
power  source
• (b)   Peer-­‐to-­‐peer  topology
• Nodes  can  communicate  via  the  
central  PAN  coordinator   and  via  
additional   point-­‐to-­‐point   links
• Extension  of  the  pure  star  
topology
• ©  Cluster  tree  topology
• Leafs  connect  to  a  network  
coordinators  (FFDs)
• One  of  the  coordinators   servers  as  
the  PAN  coordinator
• Clustered  star  topologies   are  an  
important   case  (each  hotel  room  
forms  a  star  in  a  HVAC  system)
Fig. 20. IEEE 802.15.4 topologies [33]. (a) Star. (b) Peer-to-peer. (c) Cluster-t
AL-FUQAHA et al.: IOT: SURVEY ON ENABLING TECHNOLOGIES, PROTOCOLS, AND APPLICATIONS
IEEE  802.15.4  PHY  frame  format
IEEE  802.15.4  MAC  frame  
IEEE  802.15.4  device  classes
• Full  Function  Device  (FFD)
• Any  topology
• PAN  coordinator  capable
• Talks  to  any  other  device
• Implements  complete  protocol  set
• Reduced  Function  Device  (RFD)
• Reduced  protocol  set
• Very  simple  implementation
• Cannot  become  a  PAN  coordinator
• Limited  to  leafs  in  more  complex  topologies
IEEE  802.15.4  definitions
• Network  device
• An  RFD  or  FFD  implementation  containing  an  IEEE  802.15.4  
medium  access  control  and  physical  interface  to  the  wireless  
medium
• Coordinator
• An  FFD  with  network  device  functionality  that  provides  
coordination  and  other  services  to  the  network
• PAN  coordinator
• A  coordinator  that  is  the  principal  controller  of  the  PAN.  A  
network  has  exactly  one  PAN  coordinator.
 Example:
Example:  CC2420 CC2420

•  IEEE 802.15.4 compliant radio

•  2.4 GHz band using DSSS at 250 kbps
•  Integrated voltage regulator
•  Integrated digital baseband and MAC functions
–  Clear channel assessment
–  Energy detection (RSSI)
–  Synchronization
–  Framing
–  Encryption/authentication
–  Retransmission (CSMA)

Sleep Idle Tx Rx

20 uA 426 uA 8.5 – 17.4 mA 18.8 mA

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 126

 IEEE  802.15.4  security
Security Services
Security Suite Description
Null No security (default)
AES-CTR Encryption only, CTR Mode
AES-CBC-MAC-128 128 bit MAC
AES-CBC-MAC-64 64 bit MAC
AES-CBC-MAC-32 32 bit MAC
AES-CCM-128 Encryption and 128 bit MAC
AES-CCM-64 Encryption and 64 bit MAC
AES-CCM-32 Encryption and 32 bit MAC

•Key
Key  management
management  must
must  bebe  provided bybhigher
provided   layers
y  higher  layers
•Implementations
Implementation  must
must  support
support  AES-CCM-64
AES-­‐CCM-­‐64  and
and  Null
Null
 What is 6LoWPAN?
What  is  6LoWPAN?
•  IPv6 over Low-Power wireless Area Networks
•  Defined by IETF standards
–  RFC 4919, 4944
–  draft-ietf-6lowpan-hc and -nd IPv6
–  draft-ietf-roll-rpl
•  Stateless header compression
•  Enables a standard socket API
•  Minimal use of code and memory
•  Direct end-to-end Internet integration
–  Multiple topology options

LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 158

Protocol  stack
 Other Link-Layers for 6LoWPAN
Other  links  for  6LoWPAN
•  Sub-GHz Industrial, Scientific and Medical band radios
–  Typically 10-50 kbps data rates, longer range than 2.4 GHz
–  Usually use CSMA-style medium access control
–  Example: CC1110 from Texas Instruments

•  Power-Line Communications
–  Some PLC solutions behave like an 802.15.4 channel
–  Example: A technology from Watteco provides an 802.15.4
emulation mode, allowing the use of 6LoWPAN

•  Z-Wave
–  A home-automation low-power radio technology

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 162

 Features
6LoWPAN  features
•  Support for e.g. 64-bit and 16-bit 802.15.4 addressing
•  Useful with low-power link layers such as IEEE 802.15.4,
narrowband ISM and power-line communications
•  Efficient header compression
–  IPv6 base and extension headers, UDP header
•  Network autoconfiguration using neighbor discovery
•  Unicast, multicast and broadcast support
–  Multicast is compressed and mapped to broadcast
•  Fragmentation
–  1280 byte IPv6 MTU -> 127 byte 802.15.4 frames
•  Support for IP routing (e.g. IETF RPL)
•  Support for use of link-layer mesh (e.g. 802.15.5)

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann

 6LoWPAN Addressing
6LoWPAN  addressing
•  IPv6 addresses are compressed in 6LoWPAN
•  A LoWPAN works on the principle of
–  flat address spaces (wireless network is one IPv6 subnet)
–  with unique MAC addresses (e.g. 64-bit or 16-bit)
•  6LoWPAN compresses IPv6 addresses by
–  Eliding the IPv6 prefix
•  Global prefix known by all nodes in network
•  Link-local prefix indicated by header compression format
–  Compressing the IID
•  Elided for link-local communication
•  Compressed for multihop dst/src addresses
–  Compressing with a well-known “context”
–  Multicast addresses are compressed

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann

 IP Header Compression (IPHC)
IP  header  compression  (IPHC)
6LowPAN Dispatch Codes
Base All
Header
LoWPAN encapsulated datagrams are prefixed by an
encapsulation header stack.
• All  LoWPAN +-------------------------------------+------------------------
Each header in the stack starts with a header type field
encapsulated   IP Header Compression (IPHC)
| Dispatch
followed by+ zero
LOWPAN_IPHC (2-3
or more header octets) | Compressed IPv6 Header
fields.
+-------------------------------------+------------------------
datagrams  are   Bit Pattern Short Code Description
LOWPAN_IPHC Encoding
prefixed  by  an   00 xxxxxx
Base Header
01 000001
NALP
IPv6
Not A LoWPAN Packet
uncompressed IPv6 addresses
encapsulation  header   0 +-------------------------------------+------------------------
01 000010
1
01 010000
2
LOWPAN HC1 HC1 Compressed IPv6 header
3 4 5 6 7 8
LOWPAN BC0 BC0 Broadcast header
9 0 1 2 3 4 5

stack +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|01Dispatch
111111
| 010 |xxxxxx
ESC
1 | 1 MESH
| TF
Additional
+ LOWPAN_IPHC
|NHMesh
(2-3 Dispatch
octets)
routing header
| HLIM
octet follows
| Compressed IPv6 Header
|CID|SAC| SAM | M |DAC| DAM |
+-------------------------------------+------------------------
11 000xxx FRAG1 Fragmentation header (first)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
11 100xxx FRAGN Fragmentation header (subsequent)
LOWPAN_IPHC Encoding
TF = Traffic Class, Flow Label
NH = Next Header Flag 23 / 52
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
HLIM = Hop Limit
• Each  header  in  the  stack  CID+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
= Context Identifier Extension
starts  with  a  header   | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
SAC = Source Address Compression
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
type  field  followed   by   SAM = Source Address Mode
zero  or  more  header   M TF = Multicast Compression
= Traffic Class, Flow Label
DAC = Destination Address Compression
fields NH = Next Header Flag
DAM = Destination Address Mode
HLIM = Hop Limit
CID = Context Identifier Extension
draft-ietf-6lowpa
SAC = Source Address Compression
6LoWPAN: TheSAM
Wireless Embedded Internet, Shelby & Bormann
= Source Address Mode
174
M = Multicast Compression
DAC = Destination Address Compression
DAM = Destination Address Mode
 6LoWPAN  frame  format:  worst  case

• Dispatch  code  (01000001)  indicates  no  compression

• Up  to  54/33  octets  left  for  payload  with  a  max.  size  
MAC  header  with  null/AES-­‐CCM-­‐18  security

PAN: The Wireless Embedded Internet, Shelby & Bormann 172

 6LoWPAN  frame  format:  best  case

• Dispatch  code  (01000010)  indicates  HC1  compression

• HC1  compression  may  indicate  HC2  compression  
follows
PAN: The Wireless Embedded Internet, Shelby & Bormann 172
• This  show  the  maximum  compression  achievable  for  
link-­‐local  addresses  (does  not  work  for  global  
addresses)
 6LoWPAN  routing
6LoWPAN Routing

•  Here we consider IP routing (at layer 3)

•  Routing in a LoWPAN
–  Single-interface routing
–  Flat address space (exact-match)
–  Stub network (no transit routing)

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 178

 Types  of  rTypes
outing  ofprotocols
Routing Protocols
•  Algorithm classes
–  Distance-vector
Links are associated with cost, used to find the shortest route.
Each router along the path store local next-hop information
about its route table.
–  Link-state
Each node aquires complete information about the network,
typically by flooding. Each node calculated a shortest-path tree
calculated to each destination.
•  Types of Signaling
–  Proactive
Routing information aquired before it is needed.
–  Reactive
Routing information discovered dynamically when needed.
•  Route metrics are an important factor

6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 179

 IETF ROLL
IETF  ROLL  working  group
•  Routing Over Low power and Lossy networks (ROLL)
–  Working group at the IETF
•  Standardizing a routing algorithm for embedded apps
•  Application specific requirements
–  Home automation
–  Commercial building automation
–  Industrial automation
–  Urban environments
•  Analyzed all existing protocols
•  Solution must work over IPv6 and 6LoWPAN
•  Protocol in-progress called RPL “Ripple”
–  Proactive distance-vector approach
–  See draft-ietf-roll-rpl for detailed information
RPL  for  
RPL 6LoWPAN   routing
: IPv6 routing protocol for LLN
•  Definitions
–  Directed Acyclic Graph (DAG) : a directed graph with no cycles exist
–  Destination Oriented DAG (DODAG) : a DAG rooted at a single
destination
–  Node Rank: Defines a node’s relative position within a DODAG with
RPL Node Rank
respect to the DODAG root

•  Approach : build DAG(s) rooted at these nodes

Defines a node’s relative position within a DODAG with
–  Up towards the DAG root for themany-to-one
DODAG root.
–  Down away from the DAG root for one-to-many
–  Use the DAG to detect and avoid loops Rank = 0
–  Allow point-to-point via up and down

Rank = 1 Rank = 1

Rank = 2 Rank = 3
Rank = 3
RPL:  DefinitionsDefinitions
Definitions
draft-ietf-roll-rpl-18
draft-ietf-roll-rpl-18 - RPL:- IPv6
RPL:Routing
IPv6 Routing Protocol
Protocol for...Low ...
for Low http://tools.ietf.org/html/draft-ietf-roll-rpl-18
http://tools.ietf.org/html/draft-ietf-roll-rpl-18
•  Objective
•  Objective Function:
Function: identifies
identifies metrics,
metrics, constraints,
constraints, andand objectives
objectives
•  Instance
•  InstanceInternet-Draft
Internet-Draft draft-ietf-roll-rpl-18
draft-ietf-roll-rpl-18 February
February 2011 2011
–  Defines
–  Defines thethe optimization
optimization objective
objective Function
Function when
when forming
forming
paths
paths
with
Figure
with
DODAGtowards
towards
1 depicts
DODAG Roots
Roots R1, roots
an
roots
R1,
R2,
example
R2, R3.
and
of
and R3.
a RPL Instance
Each Each
comprising
of these
of these DODAG
DODAG
three
Figure 1 depicts an example of a RPL Instance comprising three DODAGs
Roots
Roots
DODAGs

advertises
advertises the same
the same RPLInstanceID.
RPLInstanceID. The lines
The lines depict
depict connectivity
connectivity
•  Link
•  Linkbetween
between properties
properties
parents
parents : (reliability,
: (reliability,
and children.
and children. latency)
latency)
•  Figure
•  Figure
Node Node
DODAG
2 properties
2 properties
depicts
depicts how a
Version.
how a :DODAG
:DODAG (Powered
(Powered or
Version
Version or
not)not)
number
number increment
increment leadsleads
to a to a new
new
DODAG Version. This This depiction
depiction illustrates
illustrates a DODAG
a DODAG Version
Version number
number
–  –  increment
Objective
Objective
new
increment
new DODAG
DODAG : optimize
: optimize
that that
results
Version
Version does does not paths
not paths
results
in a in
based
a different
different
always
always imply based
DODAG
a on
DODAG
imply on
one one
topology.
topology.
different
a different ortopology.
Note Note
DODAGDODAG more
ortopology.
more
that that
a a
metrics
metrics
To accommodate
To accommodate certain
certain topology
topology changes
changes requires
requires a DODAG
a new new DODAG Version,
Version,
–  –  asScope
Scope described: LLN
as :described
LLN later network
network
later
in in this
this specification.
specification.

–  –  Please
Composed
ComposedPlease
depicted
depicted for of one
of one
note note
that that
in the
or
simplicity,
for simplicity, oralthough
more
in following
althoughmore
the following
examples
the disjoint
disjoint
examples
the
DODAGDODAG DODAGs
DODAGs
tree-like
tree-like
structure
structure
structures
structures
allows
allows for sharing
sharing each thethe
are are
for
each
same
same Objective
Objective
node node to have
to have multiple
Function
Function
multiple parents
parents when when the connectivity
the connectivity supports
supports it. it.

+----------------------------------------------------------------+
+----------------------------------------------------------------+
| | | |
| +--------------+
| +--------------+ | |
| | | | | | | |
| | | | (R1) (R1) | | (R2) (R2) (R3) (R3) | |
| | | | / \/ \ | | /| \ /| \ / | /\ | \ | |
| | | |/ /\ \| | / | /\ | \ / |/ \ | \ | |
| | |(A)
| (A)(B) (B)| | (C) | (C)(D)
| (D) ... ...(F) (G)
(F) (G)
(H) (H)| |
| | |/|\
| /|\ |\ | |\ | / |/ / |\
| / |\ |\ ||\ || | | |
| :
| | : | : : :: : |: : | : :
(E) (E)
: : : : : `:: `:: : | |
| | | | | | / \ / \ | |
| +--------------+
| +--------------+ : : : | |
| | DODAGDODAG | |
| | | |
+----------------------------------------------------------------+
+----------------------------------------------------------------+
RPL Instance
RPL Instance
Source:
Source: draft-RPL
draft-RPL
 DAG construction
DAG  construction
DAG Construction
•  Distance-Vector
–  Advertise path cost to root
–  Choose parents that minimize path cost
–  But be careful about loops and count-to-infinity
•  A rank assigned to every node
stance-Vector
Route Construction and Forwarding Rules
–  decreases towards root
dvertise path cost to root
Route Construction
Up routes towards nodes of decreasing rank (parents)
Down routes towards nodes of increasing rank Rank = 0
hoose parents that
Nodes inform minimize
parents pathandcost
of their presence reachability
to descendants
Source route for nodes that cannot maintain down routes
ut be careful about loops & count-to-infinity Rank = 1
Forwarding Rules Rank = 1
All routes go upwards and/or downwards along a DODAG
When going up, always forward to lower rank when
possible, may forward to sibling if no lower rank exists

sign every node a Rank

When going down, forward based on down routes
Rank = 2
Rank = 3 Rank = 3
39 / 52

Rank strictly decreasing towards root

 RPL Control messages
RPL  control  messages
•  New ICMPv6 type for RPL : ICMPv6 code 155
•  Source address : link local
–  Except DAO in non-storing mode
•  Destination address : link local unicast or all-RPL-nodes
multicast address
•  Code field : type of RPL message
–  0x0 : DODAG Information Solicitation (DIS)
•  Solicit a DODAG Information Object from a RPL node
–  0x01 : DODAG Information Object (DIO)
•  Carries information that allows a node to discover an RPL instance,
learn its configuration parameters and select DODAG parents
–  0x03 : Destination Advertisement Object (DAO)
•  Used to propagate destination information upwards along the
DODAG
DODAG:  
DODAG distributed  algorithm  
: distributed algorithm o peration
operation
•  Some node configured to be DODAG roots
•  Nodes advertise periodically their presence using a link-local
multicast DIO
•  Nodes listen for DIO and join a new DODAG
–  Select DODAG parents
–  Maintain an existing DODAG
•  Nodes provision routing table for destinations specified by
DIO via their DODAG parents
•  Nodes may use a DIS message to solicit a DIO
Constrained  Application  Protocol  (COAP)
• Constrained  machine-­‐to-­‐machine  web  protocol
• IETF  Constrained  RESTful Environments  (CoRE)  working  
group  created  CoAP
• Representation  State  Transfer  (REST)  architecture
• Simple  proxy  and  caching  capabilities
• Low  header  overhead  and  parsing  complexity
• URI  and  content-­‐type  support
• UDP  binding  (may  use  IPsec  or  DTLS)
• Reliable  unicast  and  best-­‐effort  multicast  support
• Built-­‐in  resource  discovery
 CoAP transactions provide
COAP  functionality reliable UDP messaging Application
CoAP methods resemble
• CoAP transactions  provide  
HTTP rmethod
eliable  requests
UDP   CoAP Methods

messaging and responses CoAP Transactions

• CoAP methods  resemble  
CoAPHmethod
TTP  requests  
calls may and   UDP
messages involve multiple CoAP
IPv6 / RPL
• CoAP method  calls  mtransactions
ay  involve  multiple  
CoAP transactions
OTOCOLS, AND APPLICATIONS
Roles at the transaction 6LoWPAN
2353
layer may change during a 802.15.4
method request / response
execution
 CoAP transactions
Messages
Message Description
CON Confirmable requests that the receiving peer
sends an acknowledgement or a reset
NON Non-confirmable messages do not request any
message being sent by the receiving peer
ACK Acknowledges that a CON has been received,
may carry payload
2354 IEEE COMMUNICATION SURVEY
RST Indicates that a CON has been received but
some context is missing to process it
Fig. 6. CoAP message types [64]. (a) Confirmable. (b) Non-confirmable. (c) Piggybacked responses. (d) Separate respo
Transactions are invoked peer to peer (not client/server)
Transactions are identified by a Transaction ID (TID)

46 / 52

Fig. 7. CoAP message format.

the need to update the whole data to reduce the commu-

nication overhead.
• Resource discovery: Server utilizes well-known URI
CoAP methods
Methods
Method Description
GET Retrieves information of an identified resource
POST Creates a new resource under the requested URI
PUT Updates the resource identified by an URI
DELETE Deletes the resource identified by an URI

Resources are identified by URIs

• Resources  are  identified  by  URIs
Methods are very similar to HTTP methods
• Methods  are  very  similar  to  HTTP  methods
Response codes are a subset of HTTP response codes
• Response  codes  are  a  subset  of  HTTP  response  codes
Options carry additional information (similar to HTTP
• Options  
header clines,
arry  but
additional  information  
using a more compact (encoding) similar  to  HTTP  
header  lines,  but  using  a  more  compact  encoding)
47 / 52
 CoAP message  format
Fig. 6. CoAP message types [64]. (a) Confirmable. (b) Non-confirmable. (c) P

Fig. 7. CoAP message format.

• The  Ver field  contains  the  version  number,  the  T  field  is  the  
the need
message   to update
type,   and  the  the
OC  fwhole data
ield  the   to reduce
number   the commu-
of  options
nication
• The   overhead.
Code  field  
carries   the  method  code  /  response  code  
•(methods  
Resource numbers  not  Server
are  discovery: strings) utilizes well-known URI
paths
• The   based
unique   on the web
Transaction   ID  is  link fieldsfor  
changed   in eCoRE linkrequest  
very  new   format to
but  
not  during  
provide retransmissions
resource discovery for the client.
• Interacting with HTTP: Flexibility of communicating
Security  concerns
• New  features  and  mechanisms  of  the  IoT cannot  be  
secured  by  conventional  security  protocols  which  are  
used  on  the  Internet.  
• The  security  protocols  on  the  Internet  are  designed  to  
work  over  standard  non-­‐resource  constrained  devices  
like  desktop  and  laptop  computers  
• Security  should  be  addressed  in  all  layers:  from  the  
application  to  infrastructure  layers  including  inside  the  
resource-­‐constrained  devices
Security  mechanisms
• Secure  storage  data:  Codo
• Security  solution  at  the  file  system  level  designed  for  Contiki OS
• Caching  data  for  bulk  encryption  and  decryption
• IEEE  802.15.4  link  layer  encryption
• IPsec  at  the  network  layer:  mandatory  for  IPv6  networks
• IPsec  for  6LoWPAN
• Presents  more  efficient  communication  than  IEEE  802.15.4  
security
• It  can  serve  upper  layer  including  application  protocols  that  rely  
on  TCP  or  UDP
• TLS  (TCP)  or  DTLS  (UDP)  at  the  application  layer
• Lithe  for  secure  CoAP:  compressed  version  DTLS  and  CoAP
• Dedicated  Intrusion  Detection  Systems  for  IoT
Reading  material
• L.  D.  Nardis and  M.-­‐G.  Di  Benedetto.  Overview  of  the  IEEE  
802.15.4/4a   standards  for   low  data  rate   Wireless  Personal  
Data  Networks.  In  Proc.  of  the  4th  IEEE  Workshop  on  
Positioning,  Navigation  and  Communication  2007  
(WPNC’07),  Hannover,  March  2007.  IEEE.  
• N.  Kushalnagar,  G.  Montenegro,  and  C.  Schumacher.  IPv6  
over  Low-­‐Power  Wireless  Personal   Area  Networks  
(6LoWPANs):  Overview,  Assumptions,  Problem  Statement,  
and  Goals.  RFC  4919,  August  2007.  
• T.  Winter,  P.  Thubert,  A.  Brandt,  T.  Clausen,  J.  Hui,   R.  
Kelsey,  P.  Levis,  K.  Pister,  R.  Struik,  and  JP.  Vasseur.
RPL:  IPv6  Routing  Protocol  for  Low  power  and  Lossy
Networks.  RFC
• Z.  Shelby,  B.  Frank,   and  D.  Sturek.  Constrained  Application  
Protocol  (CoAP).  RFC
 Security  and  privacy  issues  
in  Internet  of  Things

Yuchen et   al,   A  Survey  on  Security   and  privacy   issues   in   Internet  of  things,  IEEE   INTERNET  of  Things   Journal,  2017
IoT security
• Ensuring  the  security,  reliability,  resilience  and  stability  of  
Internet  applications  and  services  is  critical
• Security  in  IoT is  important  and  linked  to  the  ability  of  
users  to  trust  their  environment
• Poorly  secured  IoT devices:  entry  points  for  cyber  attacks,  
reprogram  the  device,  malfunctioning
• Poorly  designed  devices  can  expose  user  data  to  theft  
• Competitive  cost and  technical  constraints:  security  
design  deficiency
• Every  poorly  secured  device  that  is  connected  online  
potentially  affects  the  security  and  resilience  of  the  
Internet  globally  (Mirai botnet,  end  2016)
 Challenges
• Large  scale:  deployment  of  IoT devices  at  a  massive  scale
• High  connectivity  and  multiple  protocols:  device  to  device,  
device  to  gateway,  device  to  cloud
• Low  diversity:  a  vulnerability  in  a  protocol  may  affect  many  
devices  sharing  the  same  protocol
• Difficult to  reconfigure or  to  upgrade
• The  user  has  no  visibility  into  the  data  produced by  the  
device  or  its  internal  working
• Build  Your  own  Internet  of  Things:  poor  security  practices
IoT botnets
• December  2013:  first  IoT botnet
• 25%  of  the  botnet  was  made  up  of  devices  other  than  
computers,  including  smart  TV,  baby  monitors  and  other  
household  appliances
• October  2016:  Mirai botnet
• Many  web  sites  including:  Twitter,  Netflix,  Spotify,  Airbnb,  
Reddit,  Etsy,  SoundCloud and  The  New  York  Times,  were  
reported  inaccessible  by  users  caused  by  a  distributed  
denial  of  service  attack  (DDoS)  attack  using  a  network  of  
consumer  devices  from  the  Internet  of  Things  (IoT)  
• 2016:  IRCTelnet
• Infect  Linux-­‐based  insecure  IoT devices  and  turn  them  into  a  
botnet  to  carry  out  massive  DDoS attacks  
Why  it  is  difficult  to  secure  IoT?
• Battery  life  extension
• Limited  energy  to  execute  the  designed  functionality  and  
heavy  security  instructions  can  drain  the  devices’  resources  
• Use  the  minimum  security  requirements  on  the  device,  which  
is  not  recommended  especially  when  dealing  with  sensitive  
data.
• harvest  energy  from  natural  resources  (e.g.,  light,  heat,  
vibration,  wind):  requires  hardware  upgrade  and  increases  cost
• Lightweight  computation
• limited  memory  space  which  can’t  handle  the  computing  and  
storage  requirements  of  advanced  cryptography  algorithms.  
• Latency  hiding  technique:  breaking  down  the  query  results  of  
large  size  into  small  sized  data  sets.  
• Lightweight  encryption  scheme:  Identity-­‐based  Encryption  
 Classification  of  IoT attacks
• Physical  attack:  performed  when  the  attacker  is  in  a   close  
distance  of  the  device  
• Use  secure  booting  by  applying  a  cryptographic  hash  algorithms  
and  digital  signature  to  verify  its  authentication  and  the  integrity  of  
the  software  
• Network  attack:  manipulating  the  IoT network  system  to  
cause  damage  
• Authenticate  itself  to  the  network  before  any  transmission  or  
reception  of  data  
• Software  attack:  happen  when  the  IoT applications  present  
some  security  vulnerabilities  that  allow  the  attacker  to  seize  
the  opportunity  and  harm  the  system.  
• Encryption  attack:  breaking  the  system  encryption.  This  kind  
of  attacks  can  be  done  by  side  channel,  cryptanalysis,  and  
man-­‐in-­‐the-­‐middle  attacks  

Andrea,   C.  Chrysostomou,   and  G.  Hadjichristofi,   “Internet  of  things:   Security  vulnerabilities  
and  challenges,”  in  2015  IEEE  Symposium  on  Computers  and  Communication   (ISCC),   July  2015.  
 Classification  of  IoT attacks
• Taxonomy  classification  for  IoT attacks  based  on  how  
the  attacker  features  deviates  from  the  legitimate  IoT
devices  
• ignoring,  reducing,  misusing,  and  extending  the  system  
functionality  
• Creating  a  covert  channel:  organization  building  that  
implemented  smart  lights  
• Optical  receiver  that  could  read  the  data  from  a  distance  of  
over  100  meters  by  measuring  the  exact  duration  and  
frequency  of  the  small  changes  in  the  lights  intensity  
• Use  those  lights  to  create  strobes  in  the  sensitive  light  
frequencies,  which  can  lead  to  a  risk  of  epileptic  seizures  

E.Ronen and  A.Shamir,“Extended functionality   attacks  on  iot devices:  The  case  of   smart  lights,”  
in  2016  IEEE  European  Symposium  on  Security  and  Privacy  (EuroS&P),   March  2016,  pp.  3–12.  
 IoT security  at  different  layers
• Applying  existing  Internet  standards  to  smart  devices  
can  simplify  the  integration  of  the  envisioned  scenarios  
in  the  IoT contexts  
• Security  mechanisms  in  conventional  Internet  
protocols  need  to  be  modified  or  extended  to  support  
the  IoT applications  
urnal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2017.2694844, IEEE Internet of
Things Journal

• Apply  security  in  different  layers  of  IoT systems

5

of a Base Station BS, a

Application Layer
the BS contains the PKG
Smart home, Health system, etc.
ed. Their solution requires
ted to the SN which then Transport Layer
and each transmission is TLS, DTLS, etc.
. The encrypted data will
e function before sending Network Layer
cure a sent message with 6LoWPAN, IPSec, etc.
d that both messages will
uirement is that a shared
Perception Layer
WSN, IMD, RFID, GPS, etc.
between N node and SN,
IoT perception  layer  security
• Perception  node:  sensors  or  controllers
• Perception  network:  communicate  with  transport  
network
• Abnormal  sensor  node:  physically  attacked  or  
compromised
• Detect  faulty  nodes
• Cryptography  algorithms  and  key  management  
mechanisms
• Low-­‐power  public  key  encryption  algorithms:  Rabin’s  
Scheme,  NtruEncrypt and  Elliptic  Curve  Cryptography  
• Key  management:  secret  key  generation,  distribution,  
storage,  updating  and  destruction.  
IoT network  layer  security
• 6LoWPAN/IPsec
• End-­‐to-­‐End  (E2E)  secure  communication  between  IP  enabled  
sensor  networks  and  the  traditional  Internet  
• IPSec’s Authentication  Header  (AH)  and  Encapsulation  
Security  Payload  (ESP),  so  that  the  communication  endpoints  
are  able  to  authenticate,  encrypt  and  check  the  integrity  of  
messages  using  standardized  and  established  IPv6  
mechanisms  
• 6LoWPAN  security  headers  
• enable  end-­‐to-­‐end  security  between  sensor  nodes  and  hosts  
on  the  Internet,  while  also  providing  mechanisms  to  
selectively  control  the  energy  expended  with  security  
operations  on  the  WSN  
IoT transport  layer  security
• Two-­‐way  authentication  scheme  for  the  IoT system,  
based  on  existing  Internet  standards,  especially  the  
DTLS  protocol  
• Exchange  of  X.509  certificates  containing  RSA  keys  
• 6LoWPAN  header  compression  for  DTLS  
• reduces  the  number  of  additional  security  bits  
• the  number  of  additional  security  bits  can  be  reduced  by  
62%  
• Integration  of  DTLS  and  CoAP
• Reduce  the  overheads  of  the  DTLS  handshake  
• pre-­‐validation,  session  resumption,  and  handshake  
delegation  
Reading  material
• S.  Raza,  S.  Duquennoy,  J.  Hoglund,  U.  Roedig,  and  T.  Voigt,  
“Secure  communication  for  the  internet  of  things:  a  comparison  
of  link-­‐layer  security  and  ipsec for  6lowpan,”  Security  and  
Communication  Networks,  vol.  7,  no.  12,  2014.  
• S.  Raza,  D.  Trabalza,  and  T.  Voigt,  “6lowpan  compressed  dtls for  
coap,”  in  2012  IEEE  8th  International  Conference   on  Distributed  
Computing  in  Sensor  Systems,  May  2012,  pp.  287–289.  
• S.  Raza,  H.  Shafagh,  K.  Hewage,  R.  Hummen,  and  T.  Voigt,  
“Lithe:  Lightweight  secure  coap for  the  internet  of  things,”  IEEE  
Sensors   Journal,  vol.  13,  no.  10,  pp.  3711–3720,  Oct  2013

• R.  Hummen,  J.  H.  Ziegeldorf,  H.  Shafagh,  S.  Raza,  and  K.  Wehrle,  
“Towards  viable  certificate-­‐based  authentication  for  the  
internet  of  things,”  in  Proceedings   of  the  2Nd  ACM  Workshop  
on  Hot  Topics  on  Wireless  Network  Security  and  Privacy,  ser.  
HotWiSec ’13,  2013,  pp.  37–42.  
 Case  studies:  
security  analysis  of  IoT
devices
 Nest  thermostat
• Smart  device  to  control  a  standard  heating,  
ventilation  and  air  conditioning  (HVAC)  unit  based  on  
heuristics  and  learned  behavior.  
• Motion  sensor
• WiFi module:  connection  with  Nest  cloud,  remote  control
• Zigbee module:  communicate  with  other  Nest  devices  
• Linux  kernel  version  2.6.37
• Code:  open  sourceIEEE TRANSACTIONS ON MULTI-SCALE COMPUTING SYSTEMS, VOL. 1, NO. 2, APRIL-JUNE 2015

. 1. Front (left) and backplate (right) of a Nest Thermostat (credit: Nest, iFixit).

Arias  et  access

is includes al,  Privacy  and  security  
to the Nest Cloud, which in  Internet  of  Things  and  wearable  
authenticates Speed USB controller with devices,  
USB OTG capabilities, an emula-
IEEE  Tusing
dentials RANSACTIONS  
OAuth tokens.ON  M ULTI-­‐SCALE  
OAuth COMPUTING  
tokens have the tion moduleSYSTEMS,  
for Vdebugging,
OL.  1,  NO.  a 2General
,  APRIL-­‐JUNE  
Purpose2015  
Memory
 controller peripherals, such as UART, power rails 4.5 Boot Process and Device Initialization

Device  overview
control signals. Upon normal power on conditions, the Sitara AM3703 starts
rgest part count is found in the front plate of the to execute the code in its internal ROM. This code initializes
t, which is driven by a Texas Instruments Sitara the most basic peripherals, including the General Purpose
system-on-chip [43], interfacing directly with a Memory Controller. It then looks for the first stage boot-
CC NAND flash memory module, a Samsung loader, x-loader, and places it into SRAM. Once this
• Blackplate
memory module and a LCD screen. The front plate
s two wireless connectivity modules (an Ember
• ST  microelectronics  ARM  
or ZigBee and a TI WL1270B coupled with a Sky-
Cortex-­‐M3
Y2463 for WiFi), a button, a long range and a short
tion sensor, an optical navigation module (ADBM-
• SHT20:  temperature  sensor
d other miscellaneous components. Power distri-
thin the front plate is managed by a Texas Instru-
• I2C  bus  protocol
S65921B power management module, which also
high speed USB capabilities. A customized GNU/
• Front  plate
ck provides the backbone of the software interface,
research units running kernel version 2.6.37.
• Texas  instruments  Sitara
nd 2 show the device internals and device map,
ely.
AM3703  SoC:  ARM  Cortex-­‐A8
AM3703—A• NAND   flash  memory
Close Look
• SDRAM
M3703 SoC is composed of a 32 Channel DMA con-
dual-output three-layer display processor, High Fig. 2. Device map of the Nest Thermostat.
• LCD  screen
• Wireless  modules:  Wi-­‐Fi  and  
Zigbee
• Motion  sensor
Device  security
• Only  the  Wi-­‐Fi  module  is  active  and  used
• WPA2-­‐Personal  encryption:  no  WPA2-­‐Entreprise  
encryption
• TLS  1.2  for  log-­‐related  communications
• Access  to  Net  Cloud:  OAuth tokens
• Updates  and  non-­‐critical  data:  plain-­‐text  
communication
• Update  images  are  cryptographically  signed  using  PKCS  
#7  certificates  
• The  Nest  Thermostat’s  internal  software  stack  rejects  
any  update  image  which  does  not  contain  a  valid  
signature.  
Attack  vectors
• Booting  with  a  modified  code
• Using  Boot  pin  to  boot  from  a  peripheral  interface  USB  or  
UART3
• Obtain  a  shell:  mount  the  device  file  system,  enable  
remote  access  to  the  device
• Forensics  analysis:  toolchain information,  application  
binary  interface
• Refining  backdoors
• Install  secure  shell  and  SFTP  binaries
• Inject  a  trojan
• Dial  into  a  remote  server:  bypass  NAT  and  firewall
• scan  the  network  for  other  devices,  sending  this  
information  a  remote  attacker.  
Nike+  FuelBAND
• Low-­‐power  Bluetooth  4.0-­‐enabled  fitness  wristband  
designed  to  measure  daily  physical  activity,  such  as  the  
amount  of  steps  taken,  sleep  patterns  and  estimate  
ARIAS ET AL.: PRIVACY AND SECURITY IN INTERNET OF THINGS AND

the  amount  of  calories  burned  

• Reading  data  from  the  on-­‐board  three-­‐axis  
accelerometer  

Fig. 7. Nike+ Fuelband SE Fitness Tracker (credit: Nike).

• Can  communicate  with  a  Windows  or  OS  X  based  

fitness devices owned by corporate executives could be
against them, causing the corporation’s value to deteri

computer,  as  well  as  Android  and  iOS  devices:  data  

on the market, severely affecting its performance.
Much like our work with the Nest Thermostat, we

synchronization
formed a similar analysis on medical and wearable de
looking for possible hardware vulnerabilities which m
utilized against an unsuspecting user. In the following
tions, we introduce as a secondary case study our

• The  collected  data  can  then  be  analyzed,  tracked  and  

with the Nike+ Fuelband, a wearable device with fi
monitoring capabilities.

shared  with  the  Nike+  online  community   6.1 High Level Overview
The Nike+ Fuelband is a low-power Bluetooth 4.0-en
fitness wristband designed to measure daily physical
ity, such as the amount of steps taken, sleep patterns
estimate the amount of calories burned (see Fig. 7). T
done by means of reading data from the on-board three
accelerometer, which is subsequently stored within
 Device  overview
• ST  Microelectronics  
STM32L151QCH6  microcontroller:  
S ET AL.: PRIVACY AND SECURITY IN INTERNET OF THINGS AND WEARABLE DEVICES 105

ARM  Cortex-­‐M3
• LIS3DH  three-­‐axis  MEMS  
accelerometer  
• 120-­‐LED  matrix  is  driven  by  an  AMS  
AS1130  driver
• Bluetooth  communication  is  
7. Nike+achieved   bTracker
Fuelband SE Fitness y  m(credit:
eans  Nike).of  a  Cambridge  

Silicon  
ess devices owned byRcorporate
adio  Cexecutives
SR1010  Bluetooth  
could be used
Low  Energy  module  
nst them, causing the corporation’s value to deteriorate
he market, severely affecting its performance.
Much like our work with the Nest Thermostat, we per- Fig. 8. Device map of the fuelband.
med a similar analysis on medical and wearable devices,
king for possible hardware vulnerabilities which may be ARM Cortex-M3 core, this microcontroller is described in
zed against an unsuspecting user. In the following sec- greater detail in Section 6.4. An LIS3DH three-axis MEMS
s, we introduce as a secondary case study our work accelerometer from the same manufacturer interfaces
h the Nike+ Fuelband, a wearable device with fitness with the STM32 by means of a Silego SLG46300 program-
Device  security
• Bluetooth  interface  to  communicate  with  a  smartphone  
• Fuelband settings:  configured  through  these  means  and  
information  from  the  band  can  be  sent  back  to  the  
smartphone  using  this  channel.  
• Firmware  updates:  Nike+  application  on  a  Windows  or  
OS  X  based  personal  computer  
• Firmware  is  checked  against  a  checksum  before  it  is  run  
ensuring  a  valid  image  
Attack  vector
• STM32  contains  the  necessary  capabilities  to  lock  
external  reads  and  writes  against  the  internal  flash  
• This  protection  was  not  employed  on  the  Nike+  Fuelband
• The  contents  of  flash  can  be  freely  modified  by  an  attacker  
• USB  connector  which  is  used  for  both  device  charging  
and  synchronization  
• Can  be  used  to  write  new  firmware  onto  the  device  
• Requires  access  to  the  boot  pin:  not  externally  provided  
• Open  the  device  and  locate  the  boot  pin
• ST  Microelectronics  development  tools  
• Extract  the  firmware  over  USB  
• Modify  the  firmware:  string  replacement
• Recompute the  image  CRC
• Write  the  firmware
 this paper.

Haier  SmartCare:  home  automation  system A. High Level Overview

The Haier SmartCare is a smart device designe
control and read information from various sensors p
throughout a user’s home which include a smoke dete

• Smart  device  designed  to  control  and  read  information   a water leakage sensor, a sensor to check whether d
are open or closed, and a remote power switch. T

from  various  sensors  placed  throughout  a  user’s  home  

sensors are connected through the ZigBee protocol.
primary function of this device is to allow the user to
ter monitor their homes when they are away and t

which  include  a  smoke  detector,  a  water  leakage   alerts based on sensor information.

sensor,  a  sensor  to  check  whether  doors  are  open  or  

closed,  and  a  remote  power  switch  
• Sensors  connected  through  the  ZigBee  
protocol
• Monitor  homes  when  users  are  away  
and  get  alerts  based  on  sensor  information
• Mobile  application  to  connect  to  the  device Fig. 1. Haier SmartCare Device (credit: Haier)

• SmartCare connected  to  the  Ethernet  home  network In order for users to connect to the device, they
first download a mobile application from the man
turer’s website. Next, they must connect the Smart
to their network using an Ethernet connection. Fo
ing, they must connect their mobile device to the
Wurm et  al,  Security  Analysis  on  Consumer   and  Industrial  IoT Devices,  
local network as their SmartCare. Once it is conne
they must open the mobile application and create a
21st Asia  and  South   Pacific  Design   Automation   Conference  (ASP-­‐DAC),   2016
count through the manufacturer’s cloud service, whic
lows users to view their sensor data outside of their
 evices often su↵er lyze the components on the SmartCare’s hardware plat-

Device  overview
] which may be re-
nstrate these secu-
form. The main processing unit is a TI AM3352BZCZ60,
which is a part of TI’s Sitara line of processors. The pro-
/consumers better cessor contains an ARM Cortex A8 with NEON exten-
• The  main  processing  unit  is  a  TI  AM3352BZCZ60,  which  
Haier SmartCare
as a case study in
sions. The processor also supports the use of operating
systems such as Linux and Android. Upon analyzing the
is  a  part  of  TI’s  Sitara line  of  processors:  ARM  Cortex  A8  
data sheet for the processor, we were able to locate traces
for UART on the device. The SmartCare PCB is shown
• Linux  or  Android  OS
in Figure 2.

•
deviceUART  
designedpto
ous sensors placed
ort
e a smoke detector,
eck whether doors
wer switch. These
Bee protocol. The
ow the user to bet-
e away and to get
Attack  vector
• Leveraging  UART  connection
• Read  serial  data:  view  the  start  up  sequence
• Modify  boot  parameters
• Go  into  the  shell:  root  account,  telnet  server,  TFTP,  wget
command
• Get  the  root  password  from  /etc/shadow:  brute  force
• Network  analysis
• Scan  ports:  telnet
• Connect  to  the  device  using  the  root  credentials
• Main-­‐in-­‐the-­‐middle  attack:  analyze traffic  send  by  the  device
• Encrypted  traffic  between  the  device  and  the  server
• Firmware  update  over  a  plaintext  HTTP  connection
• Extract  and  analyze the  firmware
• Binary  analysis
• MQTT  protocol  to  communicate  with  the  server
 Itron Centron smart  meter
• Measure  a  customer’s  energy  usage  and  report  the  
collected  information  through  an  RF  channel  to  a  
nearby  meter  reader  or  to  a  local  substation  
• Charge  the  customer  for  their  energy  usage:  statistics  
on  energy  usage
firmware image. Because
d over a plaintext connec-
a standard utility to fetch
the update ourselves. Af-
get and performing a file
find that the firmware up-

ed us to see the Smart-

bash scripts for updating
artCare’s main initializa-
tialization script, the de-
en run the device’s main
ion, the next step in our
vice handles firmware up-
gineering the SmartCare’s Fig. 6. Itron Centron CL200 Smart Meter (credit: Itron)
 subscribers. The subscribers subscribe to topics, which
ware platform of the smart meter. Inside of the device w

Device  overview  
are posted by the publishers. In our case, the SmartCare
were able to see a heavy-duty plastic cover, which guarde
is a subscriber which communicates to the manufacturer’s
the main hardware platform. When looking at the hard
server to fetch the names of firmware updates, the correct
ware platform, we identified that it measures line voltag
hashes for the updates, commands from the user, and the
measures reference voltages, checks the energy flow d
• Measures  line  voltage,  measures  reference  voltages,  
current time. It also acts as a publisher, sending sensor
information back to the manufacturer’s server.
rection, energy pulse data, and checks the line frequenc
Attached to the main hardware platform is a daughte
checks  the  energy  flow  direction,  energy  pulse  data,  and  
In terms of actually performing the firmware update,
the device will fetch the package using the information
board, which is used when a company wants to implemen

checks  the  line  frequency  

gathered over MQTT. Once received, the device will run
an MD5 checksum on the package and compare this hash
functionality on the meter without having to replace th
entire device.

• A  daughter-­‐ board  attached  to  

to the hash provided by the manufacturer over MQTT. If
both hashes match, the device will go through with the
update. If the hashes do not match, the device will reboot,
the  main  hardware  platform  
and start the entire process again. The whole verification
mechanism is still under investigation for possible security
• Implement  functionality  on  
vulnerabilities.

III. the  meter  

Industrial IoTw ithout  
Device having  
Security to  
Analysis

replace  
Similar the  eIoTntire  
to commercial device
devices, smart devices are
also widely used in industrial applications. These devices,
• collect  may
if compromised, energy   usage  
have a more information  
serious impact than
compromised commercial IoT devices. To better under-
standalong   with  
the security tamper  
protections data  
in place and  the  
for industrial IoTID  

otherof  the  board  

Figure 6i tself  
devices, we selected the Itron Centron smart meter as the
case study. shows the smart meter.
• ATMega microcontroller,  a  tamper  
A. High Level Overview
sensor,  and  a  1  KB  EEPROM  
Fig. 7. Smart Meter CL200 Daughterboard
JTAG  functionality
• primary
The port of this device is to measure
a customer’s energy usage and report the collected infor- In this case, the daughterboard is used to collect energ
Attack  vector
• Modify  the  smart  meter  ID  in  order  for  a  meter  reader  
to  read  the  incorrect  ID  for  the  device  
• The  ID  is  stored  in  the  external  EEPROM  
• The  ID  is  on  the  meter  itself,  which  is  found  on  the  
front  of  the  device  underneath  the  grey  cover  
• Analyzing  the  EEPROM  dump
• Find  the  ID  and  change  it
• Energy  theft  becomes  possible!
Putting  them togeter:  Residential IoT
Security  impact
• A  compromised  IoT device  can  be  utilized  to  further  attack  
other  units  
• backdoor  injection  or  leaking  user  information  
• Rogue  services:  disrupt  regular  network  operations  
• DNS,  DHCP,  ARP  poisoning
• Safety  concerns
• a  compromised  device  could  then  be  used  to  cause  physical  harm  to  
its  user  
• overstress  the  HVAC  unit  it  is  connected  to,  causing  it  to  malfunction.  
• build  a  profile  of  the  victim  
• Privacy  concerns
• User  information  stored  within  unit
• collect  information  such  as  the  location  of  the  thermostat,  whether  it  
is  being  used  in  a  home  or  business,  the  postal  code  of  the  area  
• user’s  heartbeat  and  sleeping  patterns,  which  can  then  be  learned  by  
the  attacker.  
The  threats:  one  scenario
Security  enhancement
• Verifying  the  firmware  at  update  time  
• The  software  stack  must  also  be  authenticated  before  it  
can  reliably  determine  if  an  update  is  valid  or  not  
• Proper  chain  of  trust
• cryptographic  certificates  +  trusted  Certificate  Authority  
• The  exposure  of  debug  interfaces  in  these  devices  
presents  a  risk  
• Left  as  residues  from  development  prototypes  or  as  testpoints
used  during  manufacturing  
• Must  be  protected  against  attackers:  secure  JTAG  access,  
protect  certain  memory  segments  from  access  
• Only  load  and  exe-­‐ cute  cryptographically  signed  binaries  
Security  analysis  of  Smart  Home  applications
• In-­‐depth  empirical  security  analysis  of  a  popular  
emerging  smart  home  programming  platform
• Samsung  SmartThing (https://www.smartthings.com/)
• 499  SmartThings apps
• 132  devices:  static  code  analysis  tools
• SmartApps can  be  overprivileged:  gain  access  to  more  
operations  on  devices  than  their  functionality  requires
• SmartThings event  subsystem,  which  devices  use  to  
communicate  asynchronously  with  SmartApps via  
events,  does  not  sufficiently  protect  events  that  carry  
sensitive  information  such  as  lock  pincodes.
• Used  tools:  
https://github.com/earlence/SmartThingsAnalysisTools
Fernandes et  al,  Security  Analysis  of  Emerging  Smart  Home  Applications
In  Proceedings  of  37th  IEEE  Symposium  on  Security  and  Privacy,  May  2016  
(https://iotsecurity.eecs.umich.edu)
SmartThings platform

Fig. 1. SmartThings architecture overview.

Capability  system
• SmartThings has  a  security  architecture  that  governs  
what  devices  a  SmartApp may  access  
Fig. 1. SmartThings architecture overview.

• Capability:  a  set  of  commands   1 definition(

name: "DemoApp", namespace: "com.testing",
(method  calls)  and  attributes   2
3 author: "IoTPaper", description: "Test App",
(properties)   4 category: "Utility")
5
• Commands  represent  ways  in   6 //query the user for capabilities

which  a  device  can  be  controlled   78 preferences {

section("Select Devices") {
or  actuated   9 input "lock1", "capability.lock", title:
"Select a lock"
• Attributes  represent  the  state input "sw1", "capability.switch", title:
TABLE I "Select a switch"
10

information  of  a  device  

E XAMPLES OF C APABILITIES IN11 THE } S MART T HINGS F RAMEWORK
12 }
13

Capability Commands 14def updated() {

Attributes
15 unsubscribe()
capability.lock lock(), unlock()
16 lock (lock status)
initialize()
17 }
capability.battery N/A battery (battery status)
18

capability.switch 19 def installed()

on(), off() switch (switch
{ status)
20 subscribe sw1, "switch.on", onHandler
capability.alarm off(), strobe(),
21 alarm
subscribe (alarm
sw1, status)
"switch.off", offHandler
siren(), both()
22 }
23
capability.refresh refresh() N/A
24 def onHandler(evt) {
25 lock1.unlock()
Smart  apps  request  capabilities

Fig.3.3. SmartApps
Fig. SmartAppsvs. vs.SmartDevices
SmartDevicesvs.vs.Physical
PhysicalDevices:
Devices:Whe
Wh
installs this SmartApp, SmartThings will show the lock
installs this SmartApp, SmartThings will show the lock and the and th
sensor since
sensor since both
both the
the corresponding
corresponding device
device handlers
handlers (SmartDev
(SmartDe
SmartDevice2) expose the requested capability.
SmartDevice2) expose the requested capability.

Fig. 2.2. Installation

Fig. Installation user
user interface
interface and
and device
device enumeration: securityexception)
security
enumeration: This exception)since
This example
example sincethreading
threadingisisnotnotononthe
theSmart
Sma
shows that an app asks for devices that support whitelist.Apps
capability.lock
shows that an app asks for devices that support capability.lock and and
Appscannot
cannotcreate
createtheir
theirown
ownclasses,
classes,load
loade
capability.switch.The Thescreen
screenononthe
theright
rightresults whitelist.
resultswhen
whenthe
theuser
usertaps
taps
capability.switch.
on the first input field of the screen on the left. SmartThings
JARs, perform
JARs, perform reflection,
enumerates all
reflection, oror create
create their
theirown
ownthreads
thread
on the first input field of the screen on the left. SmartThings enumerates all
is only one in the example). The user SmartAppand
lock devices (there is only one in the example). The user must choose one oror
lock devices (there must choose
SmartApp andSmartDevice
one SmartDevicealso alsohas
hasaaprivate
privatedata
datasto
st
InInsummary,
summary,from fromaaprogramming
programmingperspective,
perspective,SmaSm
moredevices
more devicesthat
thatthe
theapp
appcan
canaccess.
access.
SmartDevices,and
SmartDevices, andcapabilities
capabilitiesarearekey
keybuilding
buildingblocks
block
bilitiesdefine
bilities defineaasetsetofofcommands
commandsand andattributes
attributesthat
that
4) WebService SmartApps: SmartApps
4) WebService SmartApps: SmartApps can choose to ex-
Fig. 3. canSmartApps
choose to ex- can support
support and
vs. SmartDevices
can and SmartAppsDevices:
vs. SmartApps
Physical statethe
state theWhen
capabilities
a user
capabilities the
they
pose Web service endpoints, responding to HTTP
to Fig. GET, PUT,
pose Web service endpoints, respondinginstalls this 3.
HTTP GET,SmartApps
SmartApp,
PUT, SmartThings
Based
Based
vs.onSmartDevices
on will
that,
that, show
users
users the
bind
bind
vs.
lockPhysical
SmartDevicesand to
SmartDevices the Devices
motion
toSmartApps
SmartApp
POST, and DELETE requests from external applications.
POST, and DELETE requests from
HTTP requests trigger endpoint handlers,
installs
external
sensor
specified
this
by
theSmartApp,
sinceapplications.
both corresponding
the B. ThreatSmartThings
device handlers
Model will (SmartDevice1
show the lock and a
HTTP requests trigger endpoint handlers, specified
SmartDevice2)
sensor by the
expose
since the B. the
Threatcorresponding
bothrequested Model
capability. device handlers (Sma
SmartApp, that execute developer-written blocks
SmartApp, that execute developer-written blocks of Groovyof Groovy Our work focusesononsystematically
systematicallydiscovering
discoveringandande
Our work focuses
SmartDevice2) expose the requested capability.
code.
Security  analysis  of  SmartThings
• Least-­‐privilege  principle  adherence  
• Does  the  capability  model  protect  sensitive  operations  of  devices  
against  untrusted  or  benign-­‐but-­‐buggy  SmartApps?  
• Sensitive  event  data  protection  
• What  access  control  methods  are  provided  to  protect  sensitive  
event  data  generated  by  devices  against  untrusted  or  benign-­‐but-­‐
buggy  SmartApps?  
• External,  third-­‐party  integration  safety  
• Do  SmartApps and  third-­‐party  counterpart  apps  interact  in  a  secure  
manner?  
• External  input  sanitization
• How  does  a  WebService SmartApp protect  itself  against  untrusted  
external  input?  
• Access  control  of  external  communication  APIs
• How  does  the  SmartThings cloud  backend  restrict  external  
communication  abilities  for  untrusted  or  benign-­‐but-­‐ buggy  
SmartApps?  
•
Overprivilege in  SmartApps
• Coarse-­‐Grained  Capabilities
• Least  privilege:  states  that  an  entity  (user,  program,  etc)  should  have  
the  minimum  privilege  to  function.
• Difficult  in  practice;  SmartThings is  coarse-­‐grained
• Problem  can  derive  from  developers  or  framework
• Use  static  analysis  to  compute  overprivilege on  SmartThings
• the  “auto-­‐lock”  SmartApp,  available  on  the  SmartThings app  store,  
only  requires  the  lock  command  of  capability.lock but  also  gets  
access  to  the  unlock  command  
• Coarse  SmartApp-­‐SmartDevice Binding
• SmartThings enumerates  all  physical  devices  which  support  
capabilities  in  Preferences
• Not  told  which  capabilities  were  requested
• Once  selected,  the  SmartApp gains  access  to  all  of  the  capabilities  
implemented  by  the  device  handlers
• SmartApp requests  ZWave SmartDevice’s capability.battery
• the  SmartApp also  gains  access  to  the  requested  capability  and  all  
the  other  capabilities  defined  for  the  ZWave lock  
Insufficient  Event  Data  Protection
• Event  Leakage  via  Capability-­‐based  Access  
• Once  a  SmartApp is  approved  for  access  to  a  SmartDevice
after  a  capability  request,  the  SmartApp can  also  monitor  any  
event  data  published  by  that  SmartDevice
• Event  Leakage  via  SmartDevice Identifier
• if  a  SmartApp learns  a  SmartDevice’s device  identifier,  it  can  
to  register  for  events  related  to  that  SmartDevice even  if  it  is  
not  authorized  to  talk  to  that  SmartDevice.  
• Event  spoofing
• an  attacker  can  create  a  legitimate  event  object  with  the  
correct  identifiers  and  place  arbitrary  state  information.  
When  such  an  event  is  raised,  SmartThings propagates  the  
event  to  all  subscribed  SmartApps,  as  if  the  SmartDevice
itself  triggered  the  event.  
OAuth and  Groovy:  security  issues
• SmartApps can  provide  HTTP  endpoints  for  third-­‐party  
apps  to  interface  with  SmartThings.  
• The  endpoints  are  protected  via  the  OAuth protocol  
and  all  remote  parties  must  attach  an  OAuth bearer  
token  to  each  request  while  invoking  the  WebService
SmartApp HTTP  endpoints  
• Incorrect  implementation  can  lead  to  remote  attacks  
• Unsafe  use  of  Groovy  Dynamic  method  invocation
• Apps  can  be  tricked  into  performing  unintended  actions
Unrestricted  external  communications  API
• SmartThings does  not  place  any  restrictions  on  
outbound  Internet  communication  of  SmartApps
• SmartApps can  send  SMSs  to  arbitrary  numbers  via  a  
SmartThings-­‐provided  service  
• Malicious  SmartApps:  abuse  this  ability  to  leak  
sensitive  information  from  a  victim’s  home  
Exploiting  Design  flows  in  smartThings
TABLE V
F OUR PROOF - OF - CONCEPT ATTACKS ON S MART T HINGS

Attack Description Attack Vectors Physical World Impact

(Denning et al. Classification [12])
Backdoor Pin Code Injection Attack Command injection to an existing WebService SmartApp; Overprivilege Enabling physical entry; Physical
using SmartApp-SmartDevice coarse-binding; Stealing an OAuth token theft
using the hard-coded secret in the existing binary; Getting a victim to
click on a link pointing to the SmartThings Web site
Door Lock Pin Code Snooping At- Stealthy attack app that only requests the capability to monitor battery Enabling physical entry; Physical
tack levels of connected devices and getting a victim to install the attack theft
app; Eavesdropping of events data; Overprivilege using SmartApp-
SmartDevice coarse-binding; Leaking sensitive data using unrestricted
SMS services
Disabling Vacation Mode Attack Attack app with no specific capabilities; Getting a victim to install the Physical theft; Vandalism
attack app; Misusing logic of a benign SmartApp; Event spoofing
Fake Alarm Attack Attack app with no specific capabilities; Getting a victim to install the Misinformation; Annoyance
attack app; Spoofing physical device Events; Controlling devices with-
out gaining appropriate capability; Misusing logic of benign SmartApp

intercept a redirection. Broadly, this part of the attack involves

getting a victim to click on a link that points to the authentic
SmartThings domain with only the redirect_uri portion
of the link replaced with an attacker controlled domain. The
victim should not suspect anything since the URL indeed takes
the victim to the genuine HTTPS login page of SmartThings.
Once the victim logs in to the real SmartThings Web page,
SmartThings automatically redirects to the specified redirect
URI with a 6 character codeword. At this point, the attacker
 Example:    Door  Lock  Pin  Code  Snooping  Attack  
• When  a  victim  sets  up  a  new  pin-­‐code,  the  lock  manager  app  
issues  a  setCode command  on  the  ZWave lock  device  handler  
• Device  handler  creates  a  codeReport event  object  containing  
various  data  items.  One  of  these  is  the  plaintext  pin-­‐code  that  has  
been  just  created  
• Battery  monitor  SmartApp register  for  all  types  of  codeReport
events  on  all  the  devices  it  is  authorized  to  access.  

]
 SmartThings security:  summary
• Blackbox Cloud  system
• Overprivilege:  Coarse  grained  capabilities,  and  Coarse  
SmartApp-­‐SmartDevice Binding  
• Insecure  Events:  Apps  do  not  need  special  privileges  to  
access  sensitive  info
• 55%  of  apps  do  not  use  all  operations  their  capabilities  
imply;  43%  get  capabilities  they  did  not  explicitly  request
• Designed  attacks:  device  independent,  and  long-­‐range  
 Security  analysis  of  Smart  Locks
• Home  smart  lock  systems:  electronically  controllable  
ones  that  communicate  with  a  user’s  smart  phone  or  
the  lock  manufacturer’s  servers  
• Automatically  unlock  the  door  if  it  infers  that  a  legitimate  
user  intends  to  enter  
• Security  analysis  of  5  commercial  systems
• Attacker  can  evade  the  revocation  
mechanisms  and  access  logging  procedures  
• Existing  protocols  can  often   Figure 1: View of one smart lock (Oki-
dokeys) from the interior of the home.
undesirably  unlock  the  door  by   All locks augment or replace the inte-
rior deadbolt’s turn knob with the smart
lock’s electronically controllable compo-
accident  or  in  the  presence   nent; however, all locks can be manually
operated from the inside and they main-

of  an  adversary   tain a traditional keyhole on the exterior

of the door.
Ho et  al,  “Smart  Locks:  Lessons  for  Securing  Commodity  Internet  of  Things  Devices”,  ASIACCS  2016
2.4 Locking and Unlocking Pr
Common  smart  locks  properties
• An  electronically  augmented  deadbolt  installed  onto  an  
exterior  door  
• A mobile  device  that  can  electronically  control  the  lock,  
and  a  remote  web  server  
• Users  can  use  their  mobile  devices  to  control  the  lock  
by  installing  the  lock’s  mobile  app,  creating  an  account  
on  the  manufacturer’s  servers,  and  then  pairing  their  
mobile  device  with  the  lock  using  a  local  wireless  
channel,  such  as  Bluetooth  Low  Energy  (BLE)  
Architecture Interaction model Devices Admin interfaces
Kevo DGC touch-to-unlock smartphone, keyfob mobile app, website
August DGC press button in mobile app; automatic unlocking smartphone mobile app
Dana DGC press button in mobile app; automatic unlocking smartphone mobile app, website
Okidokeys DGC press button in mobile app smartphone mobile app, website
Lockitron direct Internet connection press button in mobile app or web interface smartphone, website mobile app, website

Table 1: Summary of the system design and properties for each smart lock. DGC stands for a Device-Gateway-Cloud architecture. The
Interaction model column corresponds to the user process for unlocking/locking the door; automatic unlocking works via proximity. The
Devices column specifies which kinds of electronic devices can be used to lock/unlock the smart lock. The Admin interfaces column
indicates how homeowners can administer their lock.

sults that suggest this defense achieves our desired security The second architecture, used only by Lockitron, has a
 Connectivity  model

Figure 2: Internet connectivity model for August, Danalock, Kevo, and Okidokeys. The
smart locks themselves do not connect to the Internet. Rather, they connect to a user’s
phone via BLE and expect the smart phone to be connected to the Internet, where it
will be able to push and receive relevant information and updates (such as updates to
the lock’s software or a new digital key). We call this the DGC model.

ocess For example, consider an apartment or AirBnB tenant

unlock their door whose lease is expiring, or a household worker such as
app. a baby sitter who is being relieved of duty.
Threat  models
• A  physically-­‐present  attacker  can  observe  Alice’s   physical  
interactions  with  the  smart  lock  (including  accidental  ones,  
such  as  Alice  inadvertently  leaving  her  door  unlocked)  and  can  
also  physically  interact  with  the  smart  lock  at  any  time.  
However,  this  type  of  attacker  does  not  possess  an  authorized  
device  and  can-­‐ not  physically  alter  the  lock.  
• A  revoked  attacker  possesses  legitimate  access   that  Alice  
gave  her,  which  will  be  revoked  in  the  near  future.  For  
example,  consider  an  apartment  or  AirBnB tenant  whose  
lease  is  expiring,  or  a  household  worker  such  as  a   baby  sitter  
who  is  being  relieved  of  duty.  
• Thief:  Mallory   steals  Alice’s   authorized  device.  
• In  a  relay  attacker  threat  model,  Mallory  has  an  accomplice,  
Michael,   one  of  whom  is  near  Alice  and  the  other  is  near  the  
smart  lock.  They  both  possess  a  Bluetooth  device  that  can  
communicate  with  other  Bluetooth-­‐enabled  devices,  as  well  
as  transmit  data  between  the  two  of  them  over  long  
distances.  Neither  of  them  are  authorized  to  open  Alice’s   lock.  
 Vulnerabilities  summary
State consistency (§ 3.3) Unwanted unlocking (§ 3.4)
August thief physically-present attacker, relay attacker
Danalock thief, revoked attacker physically-present attacker, relay attacker
Kevo thief, revoked attacker physically-present attacker, relay attacker
Lockitron N/A (no auto-unlock feature)
Okidokeys thief*, revoked attacker* N/A (no auto-unlock feature)

y of vulnerabilities discovered. The two columns correspond to our two classes of attacks. Non-empt
• Smart  locks  rely  on  the  user’s   mobile  device  for  connectivity  
scovered, and list the kinds of attackers that can successfully execute the attack. For state consisten
e cases, the adversary only has a short time frame to execute the attack (see our tech report [19]
to  the  Internet:  the  only  way  they  can  receive  state  updates  
analysis, Okidokeys released a geo-fencing auto-unlock feature like the one used in August and Dan
from  the  server  is  through  messages  relayed  by  the  user’s  
mobile  
cking all packets d toevice.  
State  
the remote consistency  
server. In is a ttacks  
o✏ine, then exploit  
this  cannot
the server trust  push thi
model  
ttacks are as simple and  
asnswitching
etwork  Mallory’s
design,  allowing  
phone and an  the
attacker   to  eunaware
lock remains vade   of the
e mode. thermore, we also discovered that even if a le
revocation   a nd   access  
wo types of attackers: a thief who steals Al- l ogging. teracts with the lock with a di↵erent device
• Unwanted   u nlocking:   w
a revoked attacker (e.g., a misbehaving ten-
evicts from an apartment or an ex-spouse).
henever  a  device  with  the  correct  
revocation, the o✏ine phone maintains acc
lock: the server will not push revocation up
access  permissions  enters  BLE  cvia ommunication   range  weof  found
other devices. Finally, the   that
tion Evasion
smart  lock,  the  door  will  unlock  app
automatically  
and website interface for Danalock dis
s we studied allow owners to revoke other tion message that indicated a successful
 Case  study:  Danalock
• Allows  users  of  any  access  level  to  freely  interact  with  the  lock,  even  
when  not  Internet-­‐connected  
• thief  and  a  revoked  attacker  (e.g.,  Airbnb tenant  or  ex-­‐spouse  who  
previously  had  legitimate  access)  can  evade  revocation  by  simply  
switching  the  malicious  phone  to  airplane  mode  
• Key  revocation  works  by  having  the  remote  server  push  a  revocation  
message  to  the  revoked  user’s  phone;  however,  if  the  phone  is  
offline,  then  the  server  cannot  push  this  information  to  phone  and  
the  lock  remains  unaware  of  the  revocation  
• An  attacker  who  blocks  the  app’s  packets  from  reaching  the  server  
(e.g.,  by  taking  the  phone  offline)  can  prevent  her  interactions  with  
the  lock  from  being  recorded  
• Unwanted  locking:  if  Alice  lives  in  a  large  home  with  many  
roommates  and  several  entrances  with  smart  locks,  entering  through  
one  entrance  will  automatically  unlock  all  the  other  doors  as  Al-­‐ ice  
moves  around  her  house  (causing  her  smart  phone  to  enter  BLE  
range  of  the  other  locks).  This  leaves  Alice’s  home  open  to  theft  and  
unwanted  intrusion  
 Defenses
• Mitigating  state  consistency  attacks
• For  smart  locks  that  follow  a  DGC  architecture,  state  consistency  
attacks  fundamentally  arise  because  they  are  distributed  systems,  
and  their  design  does  not  provide  consistency  in  the  face  of  
network  partitions.  
• Eventual  Consistency:  Each  time  a  user  interacts  with  the  lock,  the  
user’s  mobile  app  fetches  a  signed,  updated  access  list  from  the  
server  and  sends  it  the  lock;  to  prevent  replay  of  old  access  lists,  
the  signed  update  message  should  include  an  incrementing  
version  number  or  timestamp.  Upon  verifying  that  the  updated  list  
came  from  the  server  and  is  fresh,  the  lock  updates  its  access  list  
accordingly.  If  the  lock  does  not  receive  a  valid  update  from  the  
server,  it  does  not  modify  its  current  access  control  list;  however,  it  
does  allow  the  current  user  to  perform  smart  lock  actions  
consistent  with  the  user’s  permissions  on  the  lock’s  current  access  
control  list  
 Summary:  IoT security
considerations  and  best  
practices
IoT security  questions
• Good  Design  Practices.  What  are  the  sets  of  best  practices  for  
engineers  and  developers  to  use  to  design  IoT devices  to  make  
them  more  secure?  How  do  lessons  learned  from  Internet  of  
Things  security  problems  get  captured  and  conveyed  to  
development  communities  to  improve  future  generations  of  
devices?  
• Cost  vs.  Security  Trade-­‐Offs.  How  do  stakeholders  make  
informed  cost-­‐benefit  analysis  decisions  with  respect  to  Internet  
of  Things  devices?  How  do  we  accurately  quantify  and  assess  
the  security  risks?  What  will  motivate  device  designers  and  
manufacturers  to  accept  additional  product  design  cost  to  make  
devices  more  secure,  and,  in  particular,  to  take  responsibility  for  
the  impact  of  any  negative  externalities  resulting  from  their  
security  decisions?  How  will  incompatibilities  between  
functionality  and  usability  be  reconciled  with  security?  How  do  
we  ensure  IoT security  solutions  support  opportunities  for  IoT
innovation,  social  and  economic  growth?  
IoT security  questions
• Standards  and  Metrics.  What  is  the  role  of  technical  and  
operational  standards  for  the  development  and  deployment  of  
secure,  well-­‐behaving  IoT devices?  How  do  we  effectively  identify  
and  measure  characteristics  of  IoT device  security?  How  do  we  
measure  the  effectiveness  of  Internet  of  Things  security  initiatives  
and  countermeasures?  How  do  we  ensure  security  best  practices  
are  implemented?  
• Data  Confidentiality,  Authentication  and  Access  Control.  What  is  
the  optimal  role  of  data  encryption  with  respect  to  IoT devices?  Is  
the  use  of  strong  encryption,  authentication  and  access  control  
technologies  in  IoT devices  an  adequate  solution  to  prevent  
eavesdropping  and  hijacking  attacks  of  the  data  streams  these  
devices  produce?  Which  encryption  and  authentication  
technologies  could  be  adapted  for  the  Internet  of  Things,  and  how  
could  they  be  implemented  within  an  IoT device’s  constraints  on  
cost,  size,  and  processing  speed?  What  are  the  foreseeable  
management  issues  that  must  be  addressed  as  a  result  of  IoT-­‐scale  
cryptography?  Are  concerns  about  managing  the  crypto-­‐key  
lifecycle  and  the  expected  period  during  which  any  given  algorithm  
is  expected  to  remain  secure  being  addressed?  Are  the  end-­‐to-­‐end  
processes  adequately  secure  and  simple  enough  for  typical  
consumers  to  use?  
IoT security  questions
• Field-­‐Upgradeability.   With  an  extended  service  life  expected  
for  many  IoT devices,  should  devices  be  designed  for  
maintainability  and  upgradeability  in  the  field  to  adapt  to  
evolving  security  threats?  New  software  and  parameter  
settings  could  be  installed  in  a  fielded  IoT device  by  a  
centralized  security  management  system  if  each  device  had  an  
integrated  device  management  agent.  But  management  
systems  add  cost  and  complexity;  could  other  approaches  to  
upgrading  device  software  be  more  compatible  with  
widespread  use  of  IoT devices?  Are  there  any  classes   of  IoT
devices  that  are  low-­‐risk  and  therefore  don’t  warrant  these  
kinds  of  features?  In  general,  are  the  user  interfaces  IoT
devices  expose  (usually  intentionally  minimal)  being  properly  
scrutinized  with  consideration  for  device  management  (by  
anyone,  including  the  user)?  
• Shared  Responsibility.  How  can  shared  responsibility  and  
collaboration  for  IoT security  be  encouraged  across  
stakeholders?  
IoT security  questions
• Regulation.  Should  device  manufacturers  be  penalized  for  
selling  software  or  hardware  with  known  or  unknown  security  
flaws?  How  might  product  liability  and  consumer  protection  
laws  be  adapted  or  extended  to  cover  any  negative  
externalities  related  to  the  Internet  of  Things  and  would  this  
operate  in  a  cross-­‐border  environment?  Would  it  be  possible  
for  regulation  to  keep  pace  and  be  effective  in  light  of  evolving  
IoT technology  and  evolving  security  threats?  How  should  
regulation  be  balanced  against  the  needs  of  permission-­‐less  
innovation,  Internet  freedom,  and  freedom  of  expression?  
• Device   Obsolescence.   What  is  the  right  approach  to  take  with  
obsolete  IoT devices  as  the  Internet  evolves  and  security  
threats  change?  Should  IoT devices  be  required  to  have  a  
built-­‐in  end-­‐of-­‐life  expiration  feature  that  disables  them?  Such  
a  requirement  could  force  older,  non-­‐interoperable  devices  
out  of  service  and  replace  them  with  more  secure  and  
interoperable  devices  in  the  future.  Certainly,  this  would  be  
very  challenging  in  the  open  marketplace.  What  are  the  
implications  of  automatic  decommissioning  IoT devices?  
Securing  IoT
• Incorporate  security  at  the  design  phase
• Building  security  in  at  the  design  phase  reduces  potential  disruptions  
and  avoids  the  much  more  difficult  and  expensive  endeavor of  
attempting  to  add  security  to  products  after  they  have  been  
developed  and  deployed.  
• Security  updates  and  vulnerability  management
• Vulnerabilities  may  be  discovered  in  products  after  they  have  been  
deployed
• Prioritize   security  measure  according  to  potential  impact
• Risk  models  differ  substantially  across  the  IoT ecosystem.  For  
example,  industrial  consumers  (such  as  nuclear  reactor  owners  and  
operators)  will  have  different  considerations  than  a  retail  consumer.
• Connect  carefully  and  deliberately
• IoT consumers  can  also  help  contain  the  potential  threats  posed  by  
network  connectivity  by  connecting  carefully  and  deliberately,  and  
weighing  the  risks  of  a  potential  breach  or  failure  of  an  IoT device  
against  the  costs  of  limiting  connectivity  to  the  Internet.  
Incorporate  security  at  the  design  phase
• Enable  security   by  default  through  unique,  hard  to  crack  
default  user  names  and  passwords.  User  names  and  
passwords  for  IoT devices  supplied  by  the  manufacturer  are  
often  never  changed  by  the  user  and  are  easily  cracked.  
Botnets  operate  by  continuously  scanning  for  IoT devices  that  
are  protected  by  known  factory  default  user  names  and  
passwords.  
• Build  the  device  using  the  most  recent  operating   system that  
is  technically  viable  and  economically  feasible.  Many  IoT
devices  use  Linux  operating  systems,  but  may  not  use  the  
most  up-­‐to-­‐date  operating  system.
• Use  hardware  that  incorporates  security   features  to  
strengthen  the  protection  and  integrity  of  the  device.  For  
example,  use  computer  chips  that  integrate  security  at  the  
transistor  level,  embedded  in  the  processor,  and  provide  
encryption  and  anonymity.  
• Design  with  system  and  operational   disruption   in  mind
Security  Updates  and  Vulnerability  Management
• Patches  would  be  applied  automatically  and  leverage  
cryptographic  integrity  and  authenticity  protections  to  
more  quickly  address  vulnerabilities.  
• Consider  coordinating  software  updates  among  third-­‐
party  vendors  to  address  vulnerabilities  and  security  
improvements  to  ensure  consumer  devices  have  the  
complete  set  of  current  protections.  
• Develop  automated  mechanisms  for  addressing  
vulnerabilities
• Develop  a  policy  regarding  the  coordinated  disclosure  of  
vulnerabilities,  including  associated  security  practices  to  
address  identified  vulnerabilities.
• Develop  an  end-­‐of-­‐life  strategy  for  IoT products
Prioritize  Security  Measures  According  to  
Potential  Impact
• Know  a  device’s  intended  use  and  environment,  
where  possible.  This  awareness  helps  developers  and  
manufacturers  consider  the  technical  characteristics  
of  the  IoT device,  how  the  device  may  operate,  and  
the  security  measures  that  may  be  necessary
• Perform  a  “red-­‐teaming”  exercise,  where  developers  
actively  try  to  bypass  the  security  measures  needed  at  
the  application,  network,  data,  or  physical  layers
• Identify  and  authenticate  the  devices  connected  to  
the  network,  especially  for  industrial  consumers  and  
business  networks.  
Connect  Carefully  and  Deliberately
• Advise  IoT consumers  on  the  intended  purpose  of  
any  network  connections.  Direct  internet  connections  
may  not  be  needed  to  operate  critical  functions  of  an  
IoT device,  particularly  in  the  industrial  setting
• Make  intentional  connections.  There  are  instances  
when  it  is  in  the  consumer’s  interest  not  to  connect  
directly  to  the  Internet,  but  instead  to  a  local  network  
that  can  aggregate  and  evaluate  any  critical  
information
• Build  in  controls  to  allow  manufacturers,  service  
providers,  and  consumers  to  disable  network  
connections  or  specific  ports  when  needed  or  desired  
to  enable  selective  connectivity
Reading  material
• Bruce  Schneier:  security  and  the  Internet  of  Things:  
https://www.schneier.com/blog/archives/2017/02/se
curity_and_th.html
• Strategic  principles  for  securing  the  Internet  of  Things,  
U.S  Department  of  Homeland  Security,  November,  
2015
• Yuchen Yang,  Longfei Wu,  Guisheng Yin,  Lijie Li,  and  
Hongbin Zhao,  A  Survey  on  Security  and  Privacy  Issues  
in  Internet-­‐of-­‐Things,  IEEE  INTERNET  OF  THINGS  
JOURNAL,  2017
 Lab  session  1:
protocols  analysis
Z-­‐Wave,  BLE  communications
Z-­‐wave  messages  capture  and  analysis
PC

SDR
GNU  Radio
USRP  B210

Scapy-­‐Radio

Z-­‐Wave  device

OpenZwave Z-­‐Wave  controller

Open  Z-­‐Wave
3.1.2 Ressources logicielles
Open-Zwave
• http://www.openzwave.com/
Open-Zwave est une librairie open source dédiée aux développeurs souhaitant tester et
incorporer des fonctionnalités Z-Wave à leurs applications. Nous utiliserons cette librairie
• Open  source  
avec notre programming  
contrôleur USB pour contrôlerlibrary  
for  
le réseau Z-­‐Wave  PC  controllers
Z-Wave.
• Voici une
Control  p impression
anel  
f or  
Z d’écran d’Open-Zwave
-­‐wave  
d evices Control Panel, une interface graphique
pour Open-Zwave :

F IGURE 13: Open-Zwave Control Panel

 étés capables de détecter le message d’activation envoyé par le contrô
SDR  boards
lorsque le capteur de mouvement était activé, et en conséquence, d’en
de désactivation aussitôt. L’attaque a été couronnée de succès et a créé
C’est sur leur travail que nous avons basé notre approche.
• Software  Defined  Radio:  a radio  communication  
system  where  the  signal-­‐capturing  components  are  
3 Notre démarche
software-­‐configurable   and  the   : sexpériences
ignal-­‐processing  et résulta
components  are  software-­‐implemented  
3.1 Environnement de travail : ressources utilisée
• Examples:  HackRF,  bladeRF,  USRP2
3.1.1 Ressources matérielles
• Full-­‐duplex,  dual-­‐channel  and  they  offer  large  radio  
spectrum  capabilities  as  
Communication radio w ell  carte
: la as  a  Ettus-USRP
great  amount  
B210 of  
bandwidth  

Ettus USRP  B210

plifie la tâche pour l’écoute des paquets échangés mais ne correspond pas vraiment à un
GNU  Radio
cas réel de réseau domotique Z-Wave.

GNU Radio
GNU  
•Pour Radio  
traiter is  a  framework
les signaux reçus par la carte SDR et les transformer en paquets, nous
• Click  
utilisons GNUaRadiond  play  
sur Gune
UI  machine
(GNU  Radio  companion)
virtuelle Linux. Ce logiciel est open source et a
l’avantage
• Gr-­‐de
mprésenter
odtool to   unehelp  
interface graphique
extend  it ergonomique où il suffit d’assembler des
modules.
• Python  and  C++
En reprenant les travaux des ingénieurs ADS, on réceptionne les paquets Z-Wave avec
• Supports  
ce modèle : a  lot  of  SDR

F IGURE 14: Partie réception dans GNU Radio

Scapy
• Interactive  packet  manipulation  program
• Used  world-­‐wide  by  pentesters
• Full  Python  code
• Supported  under  Windows,  Linux,  Mac  OSX
• Easy  to  extend
• Lots  of  protocols  already  supported
• Native  Fuzzing  capabilities
development that was necessary to make that
Scapy-­‐
happen.radio

Software Defined Radio

XMLRPC GRC flow graph (GNU Radio)

OUT socket IN socket

UDP + GNU Radio
Control

custom encapsulation

Scapy UDP SuperSocket IN socket OUT socket

Scapy

layer layer layer

layer layer layer
layer layer layer
layer layer layer
utilisons GNU Radio sur une machine virtuelle Linux. Ce logiciel est open source et a
l’avantage de présenter une interface graphique ergonomique où il suffit d’assembler des
GNU  Radio:  Receiving  Z-­‐Wave  packets
modules.
En reprenant les travaux des ingénieurs ADS, on réceptionne les paquets Z-Wave avec
ce modèle :

F IGURE 14: Partie réception dans GNU Radio

Le bloc UHD : USRP Source correspond aux signaux réceptionnés par la carte SDR,
que nous avons réglé sur la fréquence Z-Wave (868.4 MHz) avec une fréquence d’échan-
tillonnage de 800kHz. Après plusieurs blocs pour démoduler le signal et le transformer
en bits, puis en paquets, ces paquets sont envoyés dans le bloc Socket PDU qui permet la
communication avec Scapy.
De la même manière, nous envoyons des paquets Z-Wave avec ce modèle :
 GNU  Radio:  sending  Z-­‐Wave  packets
Le bloc UHD : USRP Source correspond aux signaux réceptionnés par la carte SDR,
que nous avons réglé sur la fréquence Z-Wave (868.4 MHz) avec une fréquence d’échan-
tillonnage de 800kHz. Après plusieurs blocs pour démoduler le signal et le transformer
en bits, puis en paquets, ces paquets sont envoyés dans le bloc Socket PDU qui permet la
communication avec Scapy.
De la même manière, nous envoyons des paquets Z-Wave avec ce modèle :

F IGURE 15: Partie émission dans GNU Radio

Scapy-Radio
Dans la console, on lance Scapy, qui combiné à GNU Radio nous permet de décoder
des paquets Z-Wave et d’en injecter. Les principales commandes utilisées sont :
— sniffradio() : écoute les paquets échangés et les décode en message (requête ou
acquittement)
 Étude et Analyse sur la sécur
py-Radio, on utilise les commandes sniffradio() et show() comm
mentPackets   capture
pour capturer et analyser les paquets.
p est un tableau de paquets. Pour analyse
rivons à capturer l’échange suivant : lesccommandes
• Capturing  packets  between  utilise
a  USB   ontroller  p[0].show()
and  a  plug
et p[1].sho
• sniffradio()  and  show()

F IGURE 20: Echange capturé

 Étude et Analyse sur la sécurité des objets connectés
Plug  -­‐>  controller:  state  notification
BLE  testing  environment
• BLE  SensorTag devices
http://processors.wiki.ti.com/index.php/SensorTag_User_Guide
• Sniffing  packets  using  Ubertooth One
http://ubertooth.sourceforge.net/

• Sniffing  packets  using  CC2540  

BLE  USB  dongle  
http://www.ti.com/tool/cc2540emk-­‐usb
SensorTag
• Texas  instrument   SensorTag includes  a  CC2541  
Bluetooth  Low  Energy  radio  System  on  Chip  with  
256KB  flash  and  8KB  RAM
Sniffing  BLE  SensorTag packets
• Spectrum  analysis:  run  ubertooth-­‐specan-­‐ui

Wi-­‐Fi Bluetooth   discovery

Channel  11

• Start  ubertooth-­‐btle to  capture  packets  to  a  PCAP  file

• ubertooth-­‐btle -­‐f  -­‐c  ble.pcap
• Open  the  ble.pcap with  wireshark
• Filter  the  packet  to  display  connection  packets  and  non  zero  
data  packets:  btle.data_header.length >  0  ||  
btle.advertising_header.pdu_type ==  0x05
MiTM:  GATTack
• Testing  Environment

Peripheral: Central:
GATTack GATTack
tool tool

• Tools
• https://github.com/securing/gattacker
• https://github.com/securing/gattacker/wiki/FAQ
Steps
• Install  GATTack tool  on  two  boxes
• https://github.com/securing/gattacker
• Central  module:  listens  for  advertisements,  scans  the  device’s  
services  for  cloning  in  “peripheral”,  and  forwards  the  
read/write/notification  messages   exchanged  during  active  
attack.
• Peripheral  box:  loads  device  specification  (advertisement,  
services,  characteristics,  descriptors)  collected  by  “central”  
module,  and  acts  as  the  device  “emulator”.
• Install  on  Android/IOS  mobile  the  SensorTag application
• http://www.ti.com/tool/sensortag-­‐sw
 Starting  the  central  module
• Go  to  the  gattack/node_modules/gattacker folder  and  run  the  central  
module

• Scan  the  sensorTag advertisements

• Explore  sensorTag services  and  characteristics

• All  the  data  are  saved  inside  the  devices  folder  in  JSON  format
Start  the  peripheral  module
 Lab  session  2
Inside  a  smart  plug
Inside  a  smart  plug
• The  smart  plug  provides  a  Wifi network:  mFI D25CE7
• Connect  your  host  to  this  WiFi network
• Execute  nmap to  find  the  IP  of  the  connected  smart  plug:
• Nmap –sn 192.186.2.0/24

• Using  your  browser  type  the  IP  address  of  the  smart  plug  
(192.168.2.20)
• Scan  the  device  using  nmap to  identify  the  open  ports

Cool
 How?:  inside a  smart  plug

• Telnet  connections  (port  23)

• Possible  SSH  connections  with easy to  find login/password
• Dropbear sshd 0.51:  2  vulnerabilities
• Lighttpd 1.4.31:  6  vulnerabilities
• DNS  resolver (port  53):  could be used as  a  DDoS amplifier
• Let’s  connect  to  the  device  using  telnet!!
• Let’s  explore the  file  system
Let’s  explore  network  connections
The  embedded  web  server  private  key