1. Internet of Homes
Security Analysis of Home Automation Communi-
cations Standards and Implementations
Erich A. Ficker
SRN: 130498366
Supervisor: Konstantinos Markantonakis
Submitted as part of the requirements for the award of the
MSc in Information Security of the University of London
2016
2.
3. Internet of Homes
School of Mathematics and Information Security
Royal Holloway, University of London
4.
5. Declaration of Authorship
I, Erich A. Ficker, hereby declare that this report and the work presented
in it is entirely my own. Where I have consulted the work of others, this is
always clearly stated.
Signed:
(Erich A. Ficker)
Date:
13. Summary
The Internet of Things (IoT) is a collection of computer controlled devices that in-
teract with the real world to provide convenience to humans. ”Smart” is a term
that is typically pre-pended to everyday items such as thermostats, door locks and
even umbrellas. Items marketed as ”smart” are usually part of IoT. These are often
grouped into networks that allow communication between devices to create more
value for the end user.
This project focused on the security of the network communications, specif-
ically radio transmissions. Protocols are identified with a sub-set evaluated for
security against their documentation. Potential issues are identified.
A sample of IoT ecosystems were identified and deployed in the same way that
they would be used by an end user. In order to evaluate these networks, a checklist
of test procedures were authored to facilitate accurate and comparable test results.
The test systems were then evaluated for secure communications in an operating
environment.
Several weaknesses were identified and confirmed in both the documentation
and the practical testing. During this testing it was found that communications are
not secure and that an attacker with only marginal technical skill would be able
to capture data and interact with the network without authentication. This would
allow an attacker to disable home security systems, actuate network devices such
as a door lock and adjust the settings of a thermostat.
Recommendations follow these findings on how these communications can be
protected and thus protect the end users that rely on IoT devices.
vii
14.
15. Chapter 1
Introduction
1.1 Internet of Things
The Internet of Things (IoT) has now encompassed just about every single device
with a useful purpose. Any device, be it a doorbell [74], refrigerator [76] or garage
door opener [46], has now been retrofitted to be network addressable and control-
lable from a remote location. This has been taking place with computers since the
days of the ARPAnet [3] when the first four nodes of a new network were con-
nected that eventually became the Internet. Since that time, however, security has
been an evolving concern with somewhat appropriate controls being retrofitted to
inherently insecure protocols (eg HTTP).[19]
The Internet of Things (IoT) poses similar challenges as the original network
nodes. Even the most basic device in an IoT network has similar or more computing
power than those first Internet nodes. The emphasis so far has been focused on how
to get these devices to communicate, not to communicate securely.
The first home devices to fall under extreme scrutiny were home network
routers.[35] These are the gateways to the most internal network and can contain
basic vulnerabilities that impact security. Some of those vendors [20], [77], [51]
have been responsive to outside research and notification (so-called responsible
disclosure). These devices are hopefully on their way to a more mature, secure
state.
IoT is very much in its infancy. There are few communication standards in
use[37], [95], [39]; some are ad hoc, where others are more formalized. These stan-
dards do not seem to prioritize security although some contain some form of it. The
end product and implementation of wireless radio frequency (RF) technology stan-
dards designed for IoT devices and security features are the topic of this project.
Some of these devices perform trivial tasks like toggling a light bulb, while
others can be more critical in nature like managing a power grid [73]. For example,
it may not matter if a light bulb acts up or turns off or on at inopportune times,
however frustrating; but if a home security system malfunctions, or is caused to
malfunction by an attacker this may be of a larger concern.
1.2 Motivation
While much security research has been conducted on traditional systems and net-
works, IoT poses unique challenges. Today’s standard computer systems and net-
works have reached a point where they have formal standards like NIST FIPS [60]
and Common Criteria CEM [12] by which security can be implemented and au-
dited. This is still dependent on the vendors and people managing these imple-
1
16. 1. INTRODUCTION
mentations. Successful attacks often involve social trust exploitation to facilitate an
initial technical foothold in the target environment.[86]
While this progress in system and software security has improved the overall
security posture of most organizations, embedded hardware prevalent in IoT has
only been lightly influenced. This remains the wild west of data security. Even
mature vendors have been subject to glaring vulnerabilities that even basic security
reviews uncover.[69]
IoT ecosystems are trusted by end users to project their home’s ingress egress
access and to monitor critical systems like heating, ventilation and air condition-
ing (HVAC). These end users expect a level of assurance from technology when
marketed with security functions.
This project attempted to identify just how insecure these networks are in an
attempt to make more data available to end users and as a counterpoint to potential
vendor claims of security.
1.3 Research Approach
This project assessed the current state of IoT communication protocols by analyzing
their documentation. The project then moved on to a few specific protocols and
assessed them based on actual operating ecosystems. The focus was on the wireless
communications of the network.
In order to establish a baseline for data security in embedded IoT devices, an
exhaustive search for communications protocols and best practices was conducted
and documented. These standards were evaluated against the more mature, tradi-
tional protocols and standards of wired [45] and wireless [44] network communi-
cations.
Transport encryption standards were also evaluated to ensure their adherence
to best practice. Initialization procedures, key management, proposed algorithms
and feasibility of implementation was also evaluated.
A survey of interesting home automation embedded ecosystems was selected
to assess the implementation of these standards. Ecosystems were selected based
on popularity, interoperability, complexity, cost and breadth of connected devices.
The emphasis was on residentially-focused home automation and physical secu-
rity solutions that were end-user installable and incorporated RF communication.
Professionally installed and wired-only systems of similar purpose were not con-
sidered.
In order to assess the selected implementations, a testing checklist was devel-
oped to ensure that testing was thorough and consistent across the differing hard-
ware. This provided the ability to identify vulnerabilities in common.
Recommendations for remediation is offered based on the findings for both ac-
tivities.
1.4 Project Format
In the background chapter 2, challenges unique to low power embedded devices
are discussed with regard to data security. How these devices are currently used
and the implications of human reliance on such systems is also discussed.
2
17. 1.4 PROJECT FORMAT
The Communications Standards Analysis chapter 3 documents the standards
identification and analysis with a focus on securing communications.
The Hardware Implementation Assessment chapter 4 sets forth the developed
testing checklist and findings. Justification for specific hardware selection is dis-
cussed.
In the Remediation Recommendations chapter ??, findings documented in the
implementation assessment section are discussed. Potential attack vectors and sce-
narios are put forth and recommendations for remediation are discussed.
This report ends with a conclusion in chapter 6 and identifies areas of potential
further research.
Supporting appendices and cited resources are located at the end of the report.
3
18.
19. Chapter 2
Background
2.1 Devices That Interact with the Real World
Historically, computer controlled physical devices were the topics of lengendary
fiction. The robots of 1950’s and 1960’s television shows such as Lost in Space [4]
and Forbidden Planet [38] sparked the imagination and showed that it was possi-
ble to imagine having a useful piece of machinery driven by computational power.
These robots were often limited in their function. Even today scientists and en-
treprenuers struggle to create robots that autonomously navigate and decipher spa-
cial reasoning.[24]
Over the next nearly seventy years, useful network connected and computer
controlled devices were the property of wealthy organizations like the United
State’s NASA [55] and commercial and military flight computers. These systems
and hardware cost exorbitant amounts of money (over 2.5 billion USD) in the case
of the Mars Mission rovers.[6]
The cost of having a computer controlled, network connected device has signif-
icantly dropped since NASA dropped off its rolling data collectors in 2003. Most
inhabitants of planet Earth now carry more computing power in their pocket than
what was used to guide the first manned mission to the moon. Cellular telephones
have evolved from merely having the ability to chat with others over a voice com-
munications channel to having the ability to obtain almost any obscure factoid
within seconds. They can be used to communicate in myriad other ways such as
text, photo sharing and social media. Minimal effort is required to develop some-
thing no one has ever thought to do before (like navigate effectively in an unknown
city without a paper map). This allows an even deeper voyage into a world where
control of one’s anything is literally sitting in their pocket. Phones don’t necessar-
ily have hardware that can interact with objects physically but may facilitate the
means for communication and control of such devices.
Unfortunately, or fortunately for those suffering from automatonophobia, com-
puter controlled, networked hardware devices that interact with the real human
world are quite a bit different than the robots of the golden era of television, at
least so far. Robots generally take a form follows fuction design instead of a hu-
manoid effigy. They can work full time jobs building automobiles or exploring
hostile planets.
The common thread amoung all these devices is their interactivity with the real
world. They are controlled via networks and pre-programmed software that allow
them to move objects, analyze a rock or dirt sample, or control the temperature of
a building. These devices are designed, programmed, built and controlled by hu-
mans. They are entrusted to land planes, fly space ships, control or park automo-
5
20. 2. BACKGROUND
biles, manage environmental controls or electric power grids and oversee nuclear
material enrichment and power generation.
Humans need not be physically turning knobs or flipping switches. They can
control these devices from afar.[41] Fallable programmers are employed to ensure
that these devices never misbehave and are impervious to malicious actors; how-
ever, the designers are not always successful in preventing these types of incidents.
While some visionaries [36] claim that self-driving cars will be a reality within the
next couple of years, top engineers [52] say some problems are more difficult than
they appear. In either case, residential homes are now being connected to a public
network at an exponential rate facilitating remote control and potentially, remote
attack.
2.2 Connecting Low-Power Devices to Networks
Network computing is the solution to distributed physical control with a centrally
controlled means. It is possible to deploy a stand-alone device that is pre-
programmed to handle a very specific and limited set of inputs and outputs and
make predefined control decisions. This device could account for changes in en-
vironmental conditions (inputs) and make calibration changes to connected phys-
ical devices (output) based on its programming, sensor ranges and output calibra-
tions. If this device is not connected to any sort of network, it is limited to its
pre-programmed feature set.
For an example, consider a household theromstat, originally an on-off switch.
The need to react to the current temperature automatically gave birth to mercury
encased in a glass tube with an electrical lead at one end mounted on a temperature
sensitive spring that caused the glass tube to tilt, powering the lead when the tem-
perature was outside of the preset. Now fully computerized, internet connected
smart thermostats [33] allow settings to be modified by the owner via their mobile
phone. The thermostat has evolved to take additional inputs such as power usage
statistics from the building’s power meter [26], outside ambient temperature and
weather and patterns of human behavior inside the building. All of these can aid
in decisions to most efficiently cool or heat a building.
Remote control and external environmental conditions are not always collected
by sensors of the thermostat. The thermostat now requires an internet connection
in order to operate at efficient levels, gather external weather changes and weather
forecasts that can be used to make more efficient decisions. The theromstat hasn’t
eliminated the need for human intervention, however, and it also can never have
perfect error free programming. The ability for a human to control this device
remotely is typically dependent on the thermostat connecting out to an external
(publicly accessible) web service that takes in data from the thermostat and allows
the owner to control it based on that data. The owner can issue commands to
the mutually accessible web service and in turn that web service pushes data back
down to the thermostat.
The thermostat [33] now has a complete network stack, including a means of
existing on the owner’s local area network (typically 802.11 WiFi) and connections
out to the web service are managed solely by the thermostat. This includes provid-
ing security services. Confidentiality and integrity are typically provided by Secure
6
21. 2.3 CURRENT USAGE OF IOT DEVICES
Socket Layer (SSL) or Transport Layer Security (TLS). Vulnerabilities are common
in some free implementations of this type of encryption, especially those imple-
mented in embedded Internet of Things devices. This coupled with the imperfect,
bespoke software running the thermostat (and other IoT devices), means that up-
dates will be required. These updates can happen several ways. The owner can
initiate a firmware update through the web interface used to control the device, or
an update can be pushed down from the web service or manufacturer of the ther-
mostat. This opens a potential for abuse and when misconfigured by default can
result in devices being updated with rouge or malicious firmware, as was the case
of some home network wireless routers.[22]
The trust that is placed in these devices can range from a simple home thermo-
stat, to a home security system, to life sustaining medical implants.[17] The ability
for these devices to adequately protect data communications and ensure accurate
and expected operation is based largely on default factory configurations, software
that responds correctly to malformed inputs (error handling) and prevention of
unauthorized access.
A substantial challenge with low power IoT devices is secure communications
providing the confidentiality and integrity of messages. Two complexities that
compound this challenge are the computing power required for encrypting and
decrypting messages and secure encryption key management.
2.3 Current Usage of IoT Devices
The current usage of the Internet of Things is exploding as vendors scramble to
create value in this new and exciting market segment. End-users are connecting
devices to their homes and subsequently to networks, public and private. To get a
view into what these devices accomplish, a virtual tour of a fully connected home
may be beneficial.
Out on the street before even entering the home, an end-user can open their
garage. This is not new technology, nor novel. The garage door opener has be-
come as ubiquitous in the United States as a hot water heater. While it could be
argued that a garage door opener is neither smart nor connected to a network, it
is operated remotely, and is subject to attack.[42] What if the end-user was on hol-
iday and needed to allow a friend access to their garage? If they were able to plan
this in advance, they could provide a spare opener (key) to the garage; however, in
an emergency situation, remote access could be convenient. Remotely controlling
a garage door is now a trivial task thanks to solutions from garage door opener
vendors.[1] This now allows access to actuate a garage door from anywhere a pub-
lic network connection is available.
From the driveway of a home, an observer could witness several automated
features. Outdoor lights are controlled from myriad devices. This is one of the
most basic and most prevelent features of an Internet of Things home automation
ecosystem. Motion sensors are also visible as they provide the input to lighting
control to actuate based on input. A foward approach to the house is monitored by
a camera system.[25] Moving around the side of the house will reveal a connected
power and gas meter. These are sometimes connected wirelessly with limited range
for data collection. Utility companies are typically the only authorized users of
7
22. 2. BACKGROUND
these systems, however, internet giant Google made an attempt to connect power
consumers with their power usage data in 2009.[26] This effort failed, although
utility companies still have access to their own proprietary devices. In certain US
states like California, residents are encouraged by a service credit to allow utility
providers to install a remotely controlled cut off switch on their air conditioning
condenser.[2]
Back on the front walk heading towards the front door, other connected devices
appear. Additional cameras are in place to watch an approach or observe if a pack-
age has been delivered (or stolen). Nearing the front door, two devices of note are
observed. The first allows a visitor’s photo to be taken based on sound, motion or
actuating the doorbell.[34] The photo or video can be sent to a smartphone, email
or chat messenger. A visitor can even leave a video message. The other and slightly
more critical connected device is the deadbolt. The deadbolt has long been the pin-
nacle of physical security when it comes to residential dwellings. It also represents
the most inconvenient mechanism for ingress egress. In the past it had to be manu-
ally actuated from the inside and actuated with a key from outside. Now, however,
deadbolts are electronic and may be connected to the internet.[10] This allows the
owner to remotely unlock using a phone, code, or web apppliation.
Entering the front door, a security system may have logged the front door open
event and continues to follow you around with motion sensors, indoor security
cameras, body heat sensors, window and back door sensors.[13] Moving into the
living room reveals the television that allows you to control a large number of con-
nected devices.[53] Next to the TV there is a device that competes for control of
connected devices using a human voice.[9]
In the kitchen, there is a surprising amount of connectivity given that cooking
is generally a manual activity. The refrigerator is network connected, has a color
touchscreen with access to email and calendar functions and takes photos of those
opening the door. Contents are also photographed before and after something is
removed.[76] The oven [85], slow cooker [75], food scale [11], beer micro-brewery
[8], and of course coffee maker [82] are all network connected as well.
Virually every item in the home with a mechanical component can be auto-
mated, connected and remotely controlled including bathroom scales, toilets and
showers. Moving down the hallway post-bathroom break reveals a color touch-
screen on the wall displaying some weather information. It includes the weather
inside and outside of the home. This connected device can obtain outside weather
conditions, indoor temperatures, human movement and energy consumption
targets.[33] This device is tasked with providing a comfortable environment for hu-
mans and other living things in the house. It is also tasked with providing a safe
environment through air filtration.
IoT devices employed for home automation, external connectivity and conve-
nience seemingly provide an increase in quality of life for most humans. The re-
liance on these devices is high, especially when possibilities for failure are con-
sidered. What happens when failures, unintended behavior or exploited expected
behavior occur at the hands of a malicious actor?
8
23. Chapter 3
RF Communication Standards
Analysis
3.1 RF Communication Standards Designed for
Low-power Devices
Several competing communication standards exist for low power devices with their
associated strengths and shortcomings. A specific set of challenges exist for con-
necting low power Internet of Things devices to communications networks. A net-
work stack robust enough to transceive messages that are useful enough for com-
mand and control must exist on each device. Turning on a light bulb is a basic task
and requires very little hardware or computing power to do so; however, sending
and receiving messages in a format that is effective requires complex software.
Standards and technology exist for wired communications of IoT devices with
transmission media such as in-home mains power cabling, twisted pair serial com-
munication, power over ethernet (PoE) and other proprietary systems. These are
often the best choice when devices are deployed as a result of new home construc-
tion where this infrastructure can be installed at low cost. These systems often
provide power and some are simply an extension cable to a basic sensor (for ex-
ample a magnetic door sensor). While these are optimal for both simplicity and
communication security, they are only available at great cost for existing homes.
Wireless IoT devices are relatively easy to deploy, do not require complex in-
stallation and can be installed by a home owner with little more than some double
sided tape and a drill. These are also the more prevalent options and are very
affordable. The challenge is to provide a communications channel to pass useful
messages between all nodes on the network. Several solutions to this challenge are
available. A survey of low-power communication standards is presented in this
chapter.
3.1.1 Wireless Standards
These standards all follow similar basic principles when it comes to the physical
layer of communications. They utilize radio waves generated by an RF transmit-
ter to send messages to other nodes and use an RF receiver to receive messages.
Moving up the network stack, radio waves are modulated and data messages are
encapsulated in some type of packet structure to facilitate addressing, routing and
delivery. Some standards use multi-cast or broadcast messages, while others use a
receive and forward method to get to devices that may be outside the range of the
master node.
9
24. 3. RF COMMUNICATION STANDARDS ANALYSIS
IoT home automation ecosystems must provide:
• secure node enrollment,
• reliable communication and
• secure communication.
This section will discuss the first two items with the third item discussed in the
next section.
3.1.2 IEEE 802.15.4
The IEEE 802.15.4 wireless standard was defined in 2003 and quickly became a
popular choice for low power computing communication. Like WiFi (802.11), it
is maintained by the Institute of Electrical and Electronics Engineers (IEEE). It is
an open standard that focuses on low cost communication with neighboring de-
vices using wireless RF technology, alleviating the need for high cost underlying
infrastructure. Its objectives are ease of installation, low cost and low power con-
sumption. It introduces the idea of a low-rate wireless personal area network (LR-
WPAN). It also claims to have a flexible protocol for ease of vendor implementation.[32]
IEEE 802.15.4 can operate in two different topologies, star and peer-to-peer, and
serves to service the physical and media access control layers of the network stack.
Several well known higher layer services are built on 802.15.4:
• Zigbee,
• ISA100.11a,
• WirelessHART,
• MiWi,
• Thread and others.
IEEE 802.15.4 only specifies layer 1 (physical) and layer 2 (data-link) of the net-
work stack and as such only attempts to provide reliable communication. This
leaves development of the higher levels of the network model such as enrollment
and security to individual implementations.
3.1.3 Private or Proprietary Standards
A few vendors have developed their own standards to closer fit their needs and the
perceived needs of their customers. This allows the vendor to have a tighter control
on the technology, but may stifle its adoption rate and on-going development. Peer
review is essential for assessing weaknesses in protocols and standards. Aside from
the authoring vendor and perhaps a third party security review, other parties may
not be allowed clear access to the protocols and standards. Security related issues
may not be uncovered until exposed to the public market.
10
25. 3.1 RF COMMUNICATION STANDARDS DESIGNED FOR LOW-POWER DEVICES
3.1.4 ANT[+]
ANT is a low power networking standard that operates in the unlicensed 2.4Ghz
radio frequency (RF) range (similar to WiFi) known as the industrial, scientific and
manufacturing (ISM) band. Adoption in the personal fitness segment has been
high and is often used for heart rate monitors, speed and distance monitors, bicy-
cle speed and cadence monitoring. It is mainly used for applications where low
amounts of data are communicated periodically [93].
3.1.5 Z-Wave
The Z-Wave protocol, introduced in 2008, quickly gained momentum in the home
automation and the IoT realm as a reliable, secure means of communication. It op-
erates in the 900Mhz ISM RF range. Z-Wave requires proprietary hardware and
Sigma Designs (the owner of Z-Wave) maintains tight control on the technical doc-
umentation. They require all vendors who wish to use the technology to be con-
strained by a non-disclosure agreement.[5] Z-Wave is presented as a solution to
the low power network communications challenge and offers a full network stack.
This enables vendors of end-user devices to develop their product offerings with-
out designing their own communication methods.[95]
Application Layer
Z-Wave Command Classes
Routing Layer
Mesh Network Management and Routing
Transport Layer
Framing, Retransmission and ACK
Physical Layer
RF Transceiver
Figure 3.1: Z-Wave Protocol Stack [5]
Z-Wave controllers are uniquely identified by a 32 bit Home ID and a Node ID
of 1. Devices on the network are identified by both the Home ID and a Node ID
assigned by the primary controller. This prevents the controller from interfering
in neighboring networks. Node addressing facilitates the sending of specifically
addressed traffic. Secure enrollment takes place through a momentary push button
11
26. 3. RF COMMUNICATION STANDARDS ANALYSIS
that is actuated by the end-user. [37] The Z-Wave protocol stack is illustrated in
Figure 3.1 and lists each network layer and their respective components.
3.1.6 Insteon
Insteon is a proprietary communications protocol for low power IoT devices. It is
similar to Z-Wave as it provides a full network stack for licensing to third parties.
It differs, however, in that its technology is more open.
Insteon provides secure node enrollment through a unique 24-bit identifier that
is stored in non-volatile memory during manufacture. This unique identifier is
provided to the command and control unit during enrollment. As per the specifi-
cation, this unique identifier is not disclosed over network communications unless
a physical button is actuated, typically during device enrollment.
Figure 3.2: Insteon Archetecture [39]
Reliable network communications are provided by a peer-to-peer network
schema that facilitates message repeating. A network message originates on a de-
vice on the network and that message is sent to all neighboring devices. This mes-
sage is then repeated to all devices within range up to a maximum of three times.
Devices in an Insteon environment can send, receive or repeat messages [39].
Insteon is somewhat unique in its design. Some ecosystems allow for both
wired and wireless network nodes, where wired nodes must be connected directly
through additional low-power cabling. Insteon provides wireless communications
12
27. 3.2 SECURITY FEATURES
over the ISM band (915MHz) and wired communications over the existing mains
(AC) power of the building or home. This provides connectivity for other devices
that may otherwise be outside of the RF range of neighboring devices. One com-
plexity introduced in this method, however, is support for legacy X10 devices. X10
devices were very early home automation devices that allowed remote control us-
ing very basic 4-bit commands over the building mains (AC) existing power lines.
Allowance of legacy hardware often introduces added complexity.[16]
An illustration of the Insteon ecosystem can be found in Figure 3.2. This shows
how both the wired and wireless network co-exist using the same hub or control
unit and also illustrates the interaction between wireless devices that are relaying
messages from the hub to network nodes that may be out of direct RF range due to
distance or physical obstacles.
3.1.7 Other Wireless Standards
Some IoT ecosystems have implemented other, more common wireless standards.
While these are arguably more mature, they all typically require more processing
power which in turn increases the cost and complexity of individual devices.
These standards include:
• 802.11 WiFi,
• 802.15.1 Bluetooth and
• Cellular Network.
Each of these standards have their own merits and drawbacks. For example,
WiFi provides very high bandwidth, adequate range and ubiquitous deployment,
however, requires complex software for higher levels in the network stack and
encryption. Cellular network connections enjoy exceptional range, but require
monthly carrier fees. Bluetooth is utilized on some IoT devices such as exterior
door locks, however, also carries licensing fees on top of increased computing
power requirements.
3.2 Security Features
A brief survey of various communication standards has been presented for the
benefit of additional background. A focus of two of the preceding standards are
analyzed and their security features discussed. The following section covers the se-
curity features of the Z-Wave protocol (proprietary) and the Insteon protocol (pro-
prietary).
3.2.1 Z-Wave Protocol
One of the benefits that the Z-Wave protocol enjoys due to its proprietary nature is
that the details of the protocol and features at low levels are protected somewhat
from public view by legal constraints. Those entrusted with this data are bound
by non-disclosure agreements. The next best available method for obtaining these
details are through reverse engineering, observation and intelligent extrapolation.
13
28. 3. RF COMMUNICATION STANDARDS ANALYSIS
While obscurity can offer some level of security, once devices are obtainable by the
public, analysis tends to follow. This section discusses these details. This infor-
mation was discovered and analyzed by Fouladi and Ghanoun.[5] Their research
represents the most comprehensive research performed on the Z-Wave protocol
and security features.
Fouladi and Ghanoun reverse engineered the coding and modulation schemes
for RF communication. The transport layer of the Z-Wave network stack takes care
of packet origin authentication, but only when in secure transmission mode. This
mode is not enabled by default, and most messages are passed in the clear. This
adds an 8-byte from authentication header between the end of the frame before the
checksum field.[5]
When secure transmission mode is enabled the following analysis applies. At
the time of initial device enrollment, a hardware based pseudo random number
generated (PRNG) value is encrypted using a temporary hard-coded default key in
the Z-Wave chip’s firmware before being sent to the door-lock for decryption and
acknowledgment. This is completed over the air using wireless radios; however,
an additional feature allowing the reduction in broadcast strength can be initiated
reducing the distance of the broadcast, and in turn the range for interception. This
initial key exchange happens only once when the device is first added to the net-
work which further limits the opportunity for interception. The encrypted key (Kn)
is then sent from the controller to the connecting device. Once this key exchange is
complete two more keys are generated: a frame encryption key and a data origin
authentication key. Both are generated using the Advanced Encryption Standard
(AES) in Electronic Book Mode (ECB) using a additional hard-coded 16 byte value
(Passwdc and Passwdm). A graphical representation of the secure key exchange is
shown in Figure 3.3.[5]
Kc = AES − ECBKn (Passwdc) (3.1)
Km = AES − ECBKn (Passwdm) (3.2)
Data origin authentication uses cipher block chaining message authentication
code (CBC-MAC) calculated from the AES block cipher algorithm. This provides
data integrity and also provides origin authentication using a number used once
(nonce) received from the destination network node. 64-bit nonce values are used
in the MAC formula to prevent network traffic replay attacks.[5]
MAC = AES − CBCMACKm (IV, SH||SRC||DST||LEN||C) (3.3)
The initialization vector (IV) is 16 bytes with bytes zero to seven set by the
PRNG and eight to fifteen being the nonce from the destination node. The security
header (SH) is one byte and dictates the type of security in use. SRC and DST
represent the node IDs that are communicating and C is the encrypted payload. P
is a plain text variable payload containing the Z-Wave specific data payload.[5]
C = AES − OFBKc (IV, P) (3.4)
14
29. 3.2 SECURITY FEATURES
Controller Network Node
Key Exchange Start
Ready
Get Nonce
Nonce
Cipher
Get Nonce
Nonce
Cipher
Figure 3.3: Z-Wave Key Exchange [5]
3.2.2 Insteon Protocol
The Insteon protocol uses two types of messages. The standard message does not
support encryption and allows for message lengths of 10 bits. The extended mes-
sage format can support an encrypted payload and is 24 bits in length. While the
official documentation[39] states that the extended message format supports an
encrypted payload, it is unclear if that is referring to a natively encrypted Insteon
packet, or simply an encrypted message provided by a network node. It is impor-
tant to distinguish the difference in this instance because Insteon is designed to be
compatible with multiple technologies.
It is of interest to note that in the official public documentation, the section on
security is one page out of a fifty-five page document. Insteon states that network
security is maintained at two levels. Secure node enrollment only takes place when
15
30. 3. RF COMMUNICATION STANDARDS ANALYSIS
a user actuates a physical button on each network node or device. They further
state that users would have to have the device in their physical possession, limit-
ing the exposure to an attack that would allow a malicious user to add a device
to a network at will. The other method to add a network node requires a user
to input the three byte address that uniquely identifies each device in an Insteon
network.[39]
The 3 byte device ID provides the security of the device. Without a valid, en-
rolled ID, messages are not accepted on network nodes. This provides a type of
source filtered network security. The destination ID is required to send messages
addressed to a specific node. If the source ID does not match a device ID on the
network, that traffic is ignored. The documentation takes the example of a modem
that provides a link between the Insteon network and a computer over USB. This
link allows an end-user to view all connected nodes in the network. It also allows
them to see other traffic that may not belong to their network such as a neighboring
network they do not control. The IDs are masked for the network outside of their
control; however, the networks may support each other through message relaying.
The network IDs captured and shown in the computer software by the modem are
filtered by the modem firmware itself.[39] Analysis follows in the next section.
3.3 Best Practice Analysis of Standards
Each protocol is discussed based on the official claims to security implementation
as stated in the documentation. The measures that the developers state to have fol-
lowed and their methodology that drove their conclusions. This section then delves
deeper into the official documentation and makes an attempt to discover additional
insight into how these protocols actually attempt to resist malicious abuse. Protec-
tion from unauthorized device control is also analyzed. This section will discuss
documentation only, with practical analysis detailed in chapter 4.
3.3.1 Z-Wave Protocol Security Analysis
In 2001 the United States Federal Information Processing Standards (FIPS) publica-
tion 197 [18] announced a new standard for data encryption. This announcement
replaced the Data Encryption Standard (DES) with the Advanced Encryption Stan-
dard (AES). This United States government official standard became the new de
facto standard for data protection. AES was the result of an open competition start-
ing in 1997 between multiple competing algorithms.[57] Several rounds of elimina-
tion took place to identify a winner through peer review and rigorous testing. This
newly chosen algorithm was previously known as Rijndael.[14]
Z-Wave appears to utilize industry best practices for key exchange. It uses AES
for encryption of the initial temporary encryption key. The inputs for this encryp-
tion are a hardware based pseudo random number generated (PRNG) value and a
hard coded 16-bit string in the Z-Wave chip’s firmware. It was found by Fouladi
and Ghanoun that this hard coded 16-bit string is all zeros.[5] The vector to attack
this known, hard coded and simplistic value is limited to initial network node en-
rollment. This combined with the optional low-power transmit option during key
exchange, significantly reduces the attack time window and the attack range avail-
able to malicious attackers. While this could be a valid vulnerability in theory, this
16
31. 3.3 BEST PRACTICE ANALYSIS OF STANDARDS
reduced window of opportunity reduces the ability and likelihood of exploitation.
Without the standard hard coded key, an additional measure would be required
during secure node enrollment to calculate a shared value, pass a shared value in
the clear or require user intervention. One possible solution to this finding might
be to implement a unique node ID that is provided to the end user with each node
for input into the primary controller. This would provide a shared value between
both the primary controller and the network node without having to exchange it
over the air, or use the hard coded all zero’s value. Given the limited vector and
time window for attack, the current implementation is probably acceptable in all
but the most secure environments.
Z-Wave specifies a cryptographically secure algorithm, AES, for all encrypting
operations, however, there are some issues with the implementation. The first be-
ing the initial hard coded value of all zeros used in part for the encryption of the
original nonce during initial key exchange.
It is also important to realize, that while Z-Wave does implement this secure op-
tion for data encryption in transit, it is completely optional. The IoT device vendor
makes the decision to implement this feature or not. Although trivial to implement
(it requires only a special code to be passed at the start of a communications event)
most vendors choose not to use it. Fortunately, more secure devices do tend to use
encryption such as door locks as shown in section 4.3.3.4.
3.3.2 Insteon Protocol Security Analysis
The Insteon official public documentation [39] makes claims that security is not
only incorporated, but was a focus during development. Insteon claims that their
methodology follows the most mature and tried and true form of security: physical
security. They claim that unless an attacker has physical access to a device and the
hub (or software authenticated to the hub via a computer or smart phone) that they
cannot affect the network, its security or take control of devices that belong to the
network.
3.3.3 Insteon Secure Enrollment
The first item for analysis is secure enrollment. All network nodes are assigned a
three byte address during manufacture. Using only a three byte identifier leaves
a brute force attack of the device ID an option for the determined attacker. The
request format for enrolling a device needs to be known, along with the three byte
address of the central command and control hub. According to the Insteon docu-
mentation, all addressing is obfuscated or masked from public view. If an attacker
wanted to add a device to an existing network they did not control, they would
need to obtain the three byte address of the central hub and force it into add device
mode. The attacker would already have the address of the device to be added, as
that is provided to the end-user (in this case the attacker). The hurdle that may stop
an attacker here is getting the central hub into add device mode. It is unclear from
the documentation if this is possible without a physical button press on the hub
itself, and may be enough mitigation to prevent enrolling an additional device.
17
32. 3. RF COMMUNICATION STANDARDS ANALYSIS
3.3.4 Insteon Direct Node Control
The next item for consideration is directly controlling a network node (be it a light
bulb, a power outlet or a physical door lock). This would most likely need to take
place over the wireless communication provided by the Insteon infrastructure. In
theory, an attacker could connect to the network by plugging in a rogue device to
the mains power network on an outdoor outlet; however, for this exercise physical
access will remain out of scope. Insteon claims that without the three byte address
of both an authenticated device and the target device an attacker cannot generate a
valid network command and thus cannot control a node directly through network
traffic replay or a crafted network packet containing a command.[39] The address-
ing, Insteon claims, is masked by device firmware and cannot be obtained other
than by interception during network node enrollment. Network node enrollment
is only a brief period and while it may be possible to capture that data during this
window, it represents only a short period of time and does not offer the casual
or even a moderately determined attacker adequate opportunity. An attack on a
network that is connected and functioning is much more attractive if found to be
vulnerable to this type of attack.
In the security section of the Insteon documentation, they use the example of
connecting Insteon’s PowerLinc Modem (PLM) to the network. The documentation
outlines the secure enrollment method and states that this device allows a bridge
between the Insteon network and a computer running appropriate software using
a USB connection. The interesting point in this example is that the firmware in the
PLM itself is what masks the three byte network node IDs, noting that although
neighboring networks can help each other by repeating traffic, the non-owned or
controlled network device addresses are not seen in the computer software. The
astute reader may recognize here that if the device (in this case the PLM) itself is
masking these network IDs, they may be sent in the clear over their RF network
links. RF can be captured, sometimes at great distances. Implementation analysis
demonstrated this possibility in section 4.3.2.4.[39]
3.3.5 Insteon Existing Research
In August of 2015, Peter Shipley presented research centered around the Insteon
ecosystem and specifically its wireless communications.[79] Shipley claims that
most of the public documentation that is available[39] is false, and seeks to further
obfuscate the actual details of the wireless protocol. He substantiates that network
addressing is, in fact, passed in the clear and that the only protections from obtain-
ing these addresses are afforded through standard use.[79] It is clear that Insteon
does not take into account that malicious actors rarely limit attacks to standard and
acceptable use. Attackers often have specialized tools that can capture arbitrary
radio signals and decipher them. They may have the ability to write programs that
can perform analysis and replay captured traffic or custom crafted packets. Further
analysis is presented in chapter 4.
It may seem clear at this point that some developers of IoT and home automa-
tion devices believe that their product offering may not be an interesting target to
malicious users. This is a mistake that is made over and over by technology ven-
dors and is a naive way to view end user’s privacy and potentially their safety.
18
33. Chapter 4
Implementation Assessment
This practical implementation assessment chapter will evaluate three competing
ecosystems in the IoT market vertical that are targeted towards private residence
use. A standard, industry best practice methodology is presented and utilized for
objective testing. Setup, configuration and testing these three ecosystems took ap-
proximately one hundred hours. This included research and testing machine con-
figuration. This amount of time could have easily been spent evaluating a single
ecosystem for a more comprehensive security assessment.
4.1 Implementation Selection Process and Reasoning
Ecosystems were chosen based on several criteria:
• market penetration,
• employ RF wireless communications,
• provides a safety or security function,
• promoted as home or end user installable and thus affordable,
• has been the subject of little or only recent security research.
Market penetration was used as a qualitative metric to determine potential im-
pact for issues discovered. The more pervasive the ecosystem, the larger the poten-
tial impact.
Wireless communications offer the greatest attack surface and has the poten-
tial to draw more interest from attackers. It is often harder to implement wireless
communications securely, offering a more interesting analysis.
An ecosystem that purports to provide a safety or security function infers a
greater trust level of the end user in that system. This level of trust is given to the
manufacturer of the devices to implement a secure system. A system that can keep
the users home out of reach of at least the casual attacker is expected. This expec-
tation is one that is possibly misplaced given recent findings in IoT devices.[28]
It was important that the solutions reviewed were relatively affordable. This
contributes to market penetration, but it also creates budgetary limitations on the
manufacturers of IoT devices trying to ensure that the default configuration is se-
cure. Insecure default configurations are often perpetuated by the end user due to
a lack of due diligence or simply a lack of awareness. This leaves the end user in a
vulnerable state in the event that they become a target of opportunity.
19
34. 4. IMPLEMENTATION ASSESSMENT
In an effort to provide novel and interesting work, an ecosystem that has had
countless public security reviews or has been the subject of a lot of independent
research has been avoided. That is not to say that these ecosystems have never been
subjected to independent scrutiny, however. In situations where existing research
has been published, an attempt was made to utilize that information. If tools were
made public as a result of existing research, those tools were used to validate the
findings of the associated research.
4.2 Assessment Process and Standard Testing Procedure
In this section a standardized plan of testing is presented and developed to ensure
that all ecosystems receive at least the same baseline of testing procedures for com-
parison. As is the result with most vulnerability research and testing, additional
testing procedures will typically evolve as a function of findings.
4.2.1 OWASP
The Open Web Application Security Project (OWASP) was started in 2001 in an
effort to provide a means of authoring and distributing testing and securing pro-
cedures for web-based applications. Since that time OWASP has expanded into
mobile and compiled applications. OWASP brings contributors from various dis-
ciplines and aims to share this information freely. They also offer several security
testing tools that allow security researchers and professionals to carry out the sug-
gested testing documented in their Top Ten projects. Top Ten projects are the ten
most dangerous and pervasive vulnerabilities in each software type. The Web Ap-
plication Top Ten is the industry standard for web application testing.[68]
OWASP is generally centered around a Top 10 most common vulnerabilities
model. For IoT, the model has shifted slightly and is in its infancy having started
only a few years ago. The model for IoT is illustrated in Figure 4.1. This shows
the divergence from the standard Top 10 model and focuses on a modified model
for IoT. The deviation is due to the unique nature of IoT and its additional vec-
tors for attack. An IoT ecosystem has the potential to have a component of a wide
and varied technology cross section from web applications to mobile applications
to specialized low bandwidth networking. While the focus for the security assess-
ment was largely the home automation wireless communication network, interest-
ing technologies unique to IoT were reviewed with vulnerabilities noted.
The OWASP IoT Attack Surface Areas [49] draft will serve as the building block
for the standard assessment criteria; however, it required augmentation for prac-
tical use. The green blocks in Figure 4.1 show the progress made thus far in the
project, and the blue represent planned areas of development. For the purposes
of this report, a testing guide was produced to both facilitate a standard testing
methodology for sample ecosystems and to contribute to the OWASP project. The
efforts of which should promote a general advance towards standardized testing
of these ecosystems and more public awareness of IoT security overall.
The Attack Surface Areas list is composed of fifteen areas for potential attack
and testing. These fifteen items were then grouped into four logical categories.
All categories and developed procedures are included for completeness, however,
20
35. 4.2 ASSESSMENT PROCESS AND STANDARD TESTING PROCEDURE
IoT Project
Attack Surface Areas
Testing Guide Top Vulnerabilities
Figure 4.1: Current OWASP IoT Project Design [49]
actual testing focused on RF communications. Additional findings are presented
but are not necessarily comprehensive.
4.2.1.1 Communications
Ecosystem communication, ecosystem access control and network traffic are dis-
cussed in this section. This includes the low power network communication be-
tween nodes on the IoT network, device health checks, heartbeats, command and
control and node enrollment. This section also covers trust relationship enforce-
ment among network nodes and any other network communication employed by
the ecosystem.[49]
Some of the topics of concern here include an attacker’s ability to take control or
manipulate network nodes in a way that is unauthorized, compromising sensitive
information that is traversing the network or gaining physical access to a structure
without detection using a technical means of exploit. Analysis included capture
and review of network traffic, replay testing, parameter fuzz testing and crafted
network packet creation and delivery. Testing procedures are listed in Table 4.1.
4.2.1.2 Supporting Infrastructure
The supporting infrastructure category is a bit of a catch-all for all technologies that
support but are not directly connected to the ecosystem. This includes cloud or re-
mote web management applications, vendor and third party application program
interfaces (APIs), mobile applications and updating mechanisms.[49] Attacks here
range from compromise of the vendor’s network and systems to information leak-
age of sensitive user data to insecure communications within a mobile application.
The majority of these items are covered through existing frameworks, the OWASP
Mobile Top Ten [29] or the OWASP Top Ten.[89] The update mechanism testing
was an exercise in best security practice. Testing procedures are listed in Table 4.2
4.2.1.3 Hardware
Hardware attacks take place when an attacker obtains physical access to a device.
This does not necessarily need to be the device being attacked. An attacker can ob-
tain a device through legal means and examine it for weakness. If a weakness can
be determined and replicated, it can then be weaponized against the same device
21
36. 4. IMPLEMENTATION ASSESSMENT
Communications Testing Procedures
Tool Usage technique
Software
defined
radio
The software defined radio adapter and supporting soft-
ware (capture, analyze, replay, demodulate, decode) is
used for pulling RF transmissions from the air for capture
and analysis. The low level transmission format is reverse
engineered or exposed from existing resources. Traffic is
converted into a readable format and examined for vulner-
abilities. Example tools: HackRF One [62], YardStick One
[63], RFCat [92], GNU Radio [43]
Network
test envi-
ronment
(See Figure
4.2)
This sits between the ecosystem being tested and any other
LAN or the Internet. A choke-point capable of port mir-
roring is required for comprehensive traffic capture. This
is typically a managed switch [59] and the mirror port will
have a device [40] capable of capturing traffic at near wire
speed with adequate storage for several hours of testing. If
the ecosystem requires WiFi, ensure that a wireless access
point (WAP) sits inside the capture choke-point.
Network
traffic
analysis
tools
Software tools that can read, analyze and allow the tester
search capabilities to identify connections in and out, data
payloads transferred and identify data streams. Example
tools: Wireshark [91], Tshark [90], TCPDump [83], custom
scripting [48].
Mains
power test
lab
A safe environment for mains power with a single toggle
switch. To be used in the event an electrical fault takes place
or for testing outage scenarios.
Table 4.1: Communications Attack Surface Testing Procedure Matrix
deployed in the wild. In some instances it is helpful to purloin a device in an effort
to obtain any data contained on it. This is especially true for central hubs. Hard-
ware attacks include dumping device memory in search of interesting data, com-
promise of data at rest in storage, firmware extraction, administrative command
line interface (CLI) access and encryption key compromise [49]. Testing procedures
are listed in Table 4.3.
4.2.1.4 Software
It is common to administrate an IoT ecosystem through a web application or mo-
bile application interface. That interface may reside on the central hub itself or an
outside webserver (see section 4.2.1.2). Local storage is evaluated for unencrypted
data and missing integrity checks. Standard web application testing is employed
22
37. 4.2 ASSESSMENT PROCESS AND STANDARD TESTING PROCEDURE
Supporting Infrastructure Testing Procedures
Tool Usage technique
Web proxy A web proxy is used for testing web applications. More ad-
vanced tools provide some automated scanning function-
ality and the ability to fuzz and replay crafted requests in
search of unexpected behavior. All web traffic is proxied
as the tester spiders (visits all areas and pages) of the web
application. Valid requests are captured. Requests are then
examined for interesting components (POST requests with
data, session management, host responses). Requests and
responses are replayed, parameters fuzzed and crafted in
an attempt to elicit unexpected behavior. Example tools:
BurpSuite [71], ZAProxy [67].
Web
browser
The web browser is the medium by which the site is ac-
cessed via the proxy. Most allow inspection of some traffic
and attributes. It is used to both find and validate vulnera-
bilities. Beware that some browser’s built-in security func-
tions can obscure client-side vulnerabilities. Example tools:
Google Chrome [23], OWASP Mantra [66], Firefox [54].
API and
crafted
request
tools
Some browsers offer plugin functionality allowing control
of crafted requests to both a web server and an API end-
point. These plugins are used to test parameters manually
for unexpected behavior.
Traffic anal-
ysis tools
Much like the tools in Table 4.1 these tools are used here
also, as well as tools that can analyze web traffic.
Table 4.2: Supporting Infrastructure Attack Surface Testing Procedure Matrix
[89]. This item also includes any network services that are listening. Industry
standard penetration testing techniques are employed to evaluate these listening
services.[49] Often a device will employ a fallback CLI for management on a lis-
tening TCP port.[50] All network services are enumerated and evaluated. Testing
procedures are located in Table 4.4.
4.2.2 Testing Procedures
Internet of Things ecosystems are made up of virtually every other technology in
use. Most have a high speed network connection (WiFi or ethernet) to provide
external connectivity and to facilitate command and control. Most nodes on an
IoT network will have an integrated circuit (IC) that performs processing and is
programmed with firmware to carry out specific tasks or make decisions based on
user or environmental input. To facilitate communication within the ecosystem, RF
23
38. 4. IMPLEMENTATION ASSESSMENT
Hardware Testing Procedures
Tool Usage technique
JTAG Inter-
face
A JTAG interface is used to attempt a connection between a
computer and hardware that may not have any other input
/ output (I/O) interface. The tester can attempt to com-
municate with the device and dump memory and the en-
tire firmware for analysis. Rogue firmware can also be in-
stalled. Example tools: Bus Pirate [88], JTAGulator [27].
USB
Adapter
Bridge
Used for testing varied communications ports on a device.
Many devices have a serial interface of varied specifica-
tions. This interface is used to attempt control or manipu-
lation of devices during testing. Example tools: Bus Pirate
[88], JTAGulator [27], FTDI Friend [21].
*nix Utili-
ties
Unix and Linux CLI utilities are used for analysis of capture
data. Output is chained together to allow output from one
tool to be fed directly into another for processing.
Table 4.3: Hardware Attack Surface Testing Procedure Matrix
communications are typically utilized. The central hub may allow user interaction
from a web or mobile application.
The attack surface for an IoT implementation includes all of the technologies
that are utilized to support it. For the following testing procedures, areas that are
generally well-developed are not covered in detail while still listing the relevant
areas for testing. RF communications are not unique to IoT; however, testing these
systems is a relatively new concept aside from 802.11 research. RF communications
testing details will be the in-depth focus of this section.
4.2.2.1 Testing Environment
The test environment for IoT testing requires some special attention. The test envi-
ronment for this project is outlined logically in Figure 4.2. For any given environ-
ment there may be multiple paths of communication. To capture TCP/IP network
traffic a common choke point is used. All category 5 ethernet connections converge
at the Lab Network Switch. In order to create a mirror port, the switch must be
managed and provide an interface for configuration. To provide for WiFi connec-
tivity, a WiFi access point (AP) is attached to the switch. The only function served
by the AP is to bridge traffic from the WiFi radio to the switch. The mirror port is
attached to a small form factor computer running Ubuntu Linux. This computer is
used to capture and store traffic mirrored from the switch.
Connectivity to the public network is provided by a router running dynamic
network address translation (NAT). IoT central hubs are attached to either the
wired ethernet switch or the WiFi AP. All ports used by IoT and the WiFi AP are
24
39. 4.2 ASSESSMENT PROCESS AND STANDARD TESTING PROCEDURE
Software Testing Procedures
Tool Usage technique
Web proxy As discussed in Table 4.2. Used in testing the local applica-
tions for web related vulnerabilities [89].
Web
browser
As discussed in Table 4.2.
Network
scanners
Network scanners are used to enumerate all open and lis-
tening ports on the devices. Services detected by scanners
are then manually interrogated for management function-
ality. Example tools: NMAP [47].
Vulnerability
Scanners
These are directed at the devices during testing. The
most likely target of vulnerability scanners are the central
command and control hubs. Example tools: Nessus [84],
Rapid7 Nexpose [72], OpenVAS [61].
Custom
scripts
Scripts can be written to automate some of the testing. This
usually comes once all other discovery items are complete
and output is available to formulate a specific attack.
Table 4.4: Testing Procedure Matrix for Software Attack Surface
mirrored to the capture computer.
The approach to testing RF communications is by using a software defined ra-
dio (SDR) dongle with proof of concept or custom code to capture layer 1 data.
4.2.3 RF Testing Approach
4.2.3.1 Enumerate RF Communications
RF communication data is available in the United States Federal Communications
Commission (FCC) database. Outside the US, other countries may still have an
FCC ID printed on it if it is intended for an international market, if not, other gov-
ernments may have similar publicly available information. Before a product that
broadcasts an RF signal can be sold in the US it must be tested for harmful inter-
ference. The FCC publishes the results of this testing and several other interesting
pieces of information. External and internal photos of the test subject or equip-
ment under testing (EUT) are provided. This can be helpful in confirming that the
product selection is correct.
Details about the RF transmissions are contained in the test report. This docu-
ment outlines how the EUT was tested and the results showing that it did not cause
harmful interference to other areas on the RF spectrum. In the process of demon-
strating that, the test report will list interesting information, such as the exact fre-
quency of broadcast and the modulation in use. It may also list any other radio
25
40. 4. IMPLEMENTATION ASSESSMENT
Lab Network Switch
Ecosystem Hub
Device
Node
Device
Node
Device
Node
Lab Network WiFi AP
Captured
Network
Traffic
Storage
Tester’s Computer
RF Capture
Device
Network
Cabling
WiFi
RF Radio
Mirror port
Public Network
Remote
Services
Ecosystem Testing Supporting
Router
Figure 4.2: Test Environment Diagram
communications methods (including receivers). Document the data provided in
the test report.
An FCC search can be simplified by using fcc.io.[81] An FCC search can be
initiated from the web form on their homepage or inputting the FCC ID after the
domain:
1 https://fcc.io/[FCCID]
This method can make it trivial to programmatically look up or scrape many
test reports for FCC IDs.
4.2.3.2 Wireless Traffic Capture
Once information has been obtained about the RF medium, a software defined ra-
dio (SDR) tool and GNU Radio Companion (GRC)[43] can now be configured to
capture RF transmissions. GRC can be configured in many ways. In a capture sce-
nario, the source is configured as the SDR hardware and the output is captured by
a file sink, which writes the RF data to a raw format on disk to the path specified
as shown in Figure 4.8. The details of configuring GRC is beyond the scope of this
report, but several resources exist.[64]
With a working GRC configuration capture several control events including:
26
41. 4.2 ASSESSMENT PROCESS AND STANDARD TESTING PROCEDURE
1. node actuation,
2. node enrollment,
3. system arming and disarming,
4. and any other interesting actions.
Ensure that separate files delineate the actions and are named appropriately.
4.2.3.3 Wireless Traffic Replay
RF replay is a useful attack that allows a few conclusions to be drawn about the
protocol in place. Ensure the IoT system is in the correct state to accept commands
and configure GRC correctly. This time the file will be played back by using a file
sources block. That will output the specified pre-recorded file into the flow graph.
The output of the flow graph will be the radio sink. In the case of using the HackRF
(and many other SDR tools), this is the osmocom sink. Configure the output fre-
quency and any other required options. This should look somewhat similar to
Figure 4.9.
If the replay is successful, several assumptions may be true. The RF protocol
does not employ a cryptographic mechanism to verify the sender of the message
such as message signing. The protocol also does not employ any type of replay
detection like a number used only once (nonce) or a sequence number. The mes-
sage payload is not cryptographically unique. These are the lowest complexity RF
findings. This demonstrates that an attacker does not need to be highly skilled in
reverse engineering RF signals to perpetrate an attack. They could perpetrate an
attack with about 300USD in hardware, a laptop and a few hours to learn the basics
of GRC and SDR.
4.2.3.4 Existing Proof of Concept (PoC) Code
Reverse engineering an RF signal from radio waves to usable, digital data is a time
consuming and arduous process. It involves a deep understanding of RF and dig-
ital data transmission. The path of least resistance may often be to find existing
PoC code in the wild. This is typically where another researcher has analyzed the
target ecosystem and released a set of tools they wrote during their analysis. For
the purposes of this project, two of the three IoT ecosystems tested have PoC code
publicly available. The third has very recently been analyzed, however, no PoC
code has been released.
4.2.3.5 Captured RF Signal Analysis
While RF signal replay is straightforward and does not require a high level of tech-
nical skill, RF signal analysis increases the learning curve sharply. In order to re-
verse engineer an RF signal into digital information, several details need to be de-
rived from the captured radio waves.
RF transmissions use a carrier wave at a specific frequency in the RF spectrum.
This can be thought of as a virtual cable or wire carrying the signal. On this carrier
wave, an encoding model known as a modulation is used to transfer the digital
27
42. 4. IMPLEMENTATION ASSESSMENT
data in the form of radio signals. This is very similar to the electric pulses inside
of an ethernet twisted pair cable. This modulation must be known in order to de-
code the signals that are transmitted on the carrier wave. An illustration of this
is a tool called Inspectrum[87] and is shown in Figure 4.3. This shows a captured
RF message from a SimpliSafe disarm signal. Inspectrum takes a file of captured
RF signals and shows it in a format that makes the digital data readable with the
human eye. In Figure 4.3 the thick green dashes indicate digital data where the
absence of these are the lack of data. This allows the receiver to decipher between
individual bits. When only the representation of data is sending and not sending
and they are all the same length this is known as on-off keying (OOK) and is very
common. A change in the length of the thick green dashes indicates another repre-
sentation of data known as pulse width modulation (PWM). These are two of the
most common types of modulation.
With the modulation type deciphered from visual analysis, the data or symbol
rate must be determined. This can be guessed against the time axis in inspectrum
and may require some trial and error. Another item that must be determined is the
sync word. This is a signal to the receiver that the transmitter is about to transmit
data. It is typically a repeating pattern and will show up before each transmitted
message.
4.2.3.6 Data Analysis of RF Protocol
If the RF protocol has been successfully reverse engineered, or PoC code has been
discovered that allows full access to the digital data from the RF capture, additional
analysis can take place. Typically complete access to the digital data will reveal how
nodes communicate and route messaged around the network. This can be useful in
packet crafting, where additional programs are used to generate legitimate traffic
that can be sent without replaying a captured signal. In fact, although the means
may differ, this is the same as sending legitimate traffic from the IoT member nodes
themselves if necessary protections are not in place.
If packet data is, in fact, encrypted, packet addressing and other data in the
packet may not be. This may allow additional details about the ecosystem to be
discovered.
If encryption is in use, there may be a scenario where the central hub may pass
key material in the clear. This is often during node enrollment, especially when
symmetric key encryption is in use. Secure key exchange is complex and IoT nodes
may not have the ability to securely exchange a symmetric key. If this is true, the
symmetric key may be obtained by capturing a new enrollment event. Often, the
symmetric key is the same for all nodes. Capture of a key in that scenario facilitates
many decrypt operations. Another likely scenario is that the ecosystem uses a hard-
coded or shared key across all ecosystems of the same vendor.
Attempts should be made to obtain encryption keys through traffic analysis.
Note that this is only an option if the RF protocol has been reverse engineered
enough to provide digital data level access to the transmitted messages.
28
43. 4.3 INTERNET OF THINGS ASSESSMENT FINDINGS
Figure 4.3: Inspectrum view of an unlock signal from the SimpliSafe key fob remote
4.3 Internet of Things Assessment Findings
Three home automation systems were selected and tested using tools and tech-
niques outlined in section 4.2. This section will outline the findings of the assess-
ments. Risks will be profiled and scored according to impact and complexity using
the US National Vulnerability Database (NVD) Common Vulnerability Scoring Sys-
tem (CVSS), version 2.[58]
There were three ecosystems selected for testing:
29
44. 4. IMPLEMENTATION ASSESSMENT
1. Insteon (findings in section 4.3.2),
2. Samsung SmartThings (findings in section 4.3.3) and
3. SimpliSafe (findings in section 4.3.4).
4.3.1 Equipment Under Testing (EUT)
4.3.1.1 Insteon Hardware
The Insteon was assembled, provisioned and tested as shown in the right side pink
area in Figure 4.4. It included:
1. Hub Pro with Homekit (2243-222),
2. SwitchLinc (2477D),
3. OutletLinc (2472DWH),
4. On/Off Module (2635-222),
5. Wireless Motion Sensor (2842-222),
6. Hidden Door Sensor (2845-222) and
7. Mini Remote (2342-232).
4.3.1.2 Samsung SmartThings Hardware
The Samsung SmartThings ecosystem was obtained as a starter kit focused on
home security. This is illustrated in Figure 4.4 in the center blue area. Devices
included:
1. Home Monitoring Kit (056-16-0043),
2. Aeon Labs Siren Z-Wave (ZW080-A17),
3. Schlage Electronic Deadbold Z-Wave (BE469NX) and
4. GE In-Wall Smart Outlet Z-Wave (12721).
4.3.1.3 SimpliSafe Hardware
The SimpliSafe ecosystem was obtained as a home security focused kit. This can be
seen on the left in the yellow section in Figure 4.4. Including:
1. Simplisafe2 Wireless Home Security System 8-piece Plus Package
(680569237705) and
2. 105 Decibel Auxiliary Siren (B00R3SEV98).
30
45. 4.3 INTERNET OF THINGS ASSESSMENT FINDINGS
Figure 4.4: IoT Ecosystem Organizing Display
4.3.2 Insteon Assessment Findings
4.3.2.1 Standard Operation as Tested
The Insteon ecosystem is controlled through a central hub and facilitates a bridge
between the devices connected over 900Mhz RF and mains power networks and a
wired LAN. Commands are issued on an Apple iOS based device, using the Apple
HomeKit functionality. An Insteon mobile application allows command, control
and configuration. The mobile device must be on the same LAN to communicate
with the Insteon Hub.
Devices connected to the mains power network were able to be paired to the the
hub using the Insteon app, while RF-only connected devices required a physical
momentary button press on both the hub and the device being paired.
4.3.2.2 Remote Access
Remote access is facilitated by forwarding TCP port 25015 through the Internet
router at the edge of the LAN. It does not require a third party external cloud-based
application to communicate.
31
46. 4. IMPLEMENTATION ASSESSMENT
4.3.2.3 Physical Inspection
The Insteon Hub did not provide any tamper evident or tamper deterrence. The
main board inside the hub enclosure appears to be off the shelf hardware pro-
vided by Texas Instruments (TI) and was oddly similar to the low power computing
hobby platform known as the Beagle Bone (also made by TI). The Insteon is on the
left and the Beagle Bone is on the right as illustrated in Figure 4.5. The general pur-
pose input output (I/O) looked very similar on both devices. While the solution on
chip (SoC) does carry a different part number, functionality was very similar. The
hobby board runs a full ARM linux distribution and it as does the Insteon Hub Pro.
A micro sdcard slot was available on the reverse side of the TI controller board.
During normal operation, no sdcard was inserted. The board had four gigabytes of
non-volatile storage that contained the file and operating systems. An sdcard was
imaged with an alternate operating system that is used on the Beagle Bone. The
sdcard was inserted into the Insteon controller board and power was applied with
the boot button depressed. This facilitated booting from the sdcard. Once the board
was booted to Ubuntu linux, the file system contained on the on board storage was
mounted and explored.
With access to the local file system as a privileged user files could be altered
including secure configurations. For example SSH is restricted to certificate and
password based access, neither of which an attacker would have. Altering the SSH
configuration file would allow a user to login without either authorization items.
The controller board also has a web interface that is protected by basic authentica-
tion. This could also be disabled to allow access to a protected resource. Due to the
focus of testing on RF communications, resources were not spent exploiting this
vector of attack.
The daughter card shown attached to the left side of the hub board in Figure 4.5
connects to a second board that provides RF and mains power network connectiv-
ity.
4.3.2.4 RF Analysis
As per the FCC filing test report and verified by GRC and SDR transceiver, the
Insteon RF network communicates at about 915Mhz. Peter Shipley fully reversed
this protocol with additional details as follows:[79]
1. a 914.975Mhz center frequency,
2. modified manchester encoding,
3. inverted frequency shift keying (FSK),
4. a shift of 150khz,
5. 9125 symbols per second and a
6. 2600 bits per second data rate.
Note that the actual communications protocol varies widely from the public
documentation presented in section 3.2.2. Insteon claims security over the air in
32
47. 4.3 INTERNET OF THINGS ASSESSMENT FINDINGS
Figure 4.5: Insteon hub controller compared to a hobby board (Left, Insteon. Right,
Beagle Bone)
their RF network; however, it was determined that several vulnerabilities exist in
the protocol.
Any signal sniffed and captured from the Insteon RF network can be replayed.
This allowed conclusions to be drawn that no proper cryptosystem is in place
to prevent replay, sender forgery, message forgery or message uniqueness. This
would allow an attacker within radio range to carry out replay attacks or jamming
attacks. An attacker could potentially unlock doors and send captured signals from
motion sensors reporting no movement detected. The range at which this could be
carried out varies widely based on hardware, antennas, and amplification in use. It
is conceivable that this attack could happen from quite a distance away (300 meters
or greater).
While Insteon did provide a barrier to full reverse engineering down to the
data level, this was mostly provided by obscurity and obfuscation; full truth is
not presented in the public documentation. Upon closer scrutiny, however, Peter
Shipley was able to fully reverse the data protocol and provided PoC code that
allows data packet capture and data packet crafting with minimal effort.[78]
Shipley’s code and attack methods can be carried out by using several different
SDR tools. For the purposes of this test, a YardStick One (running RFCat) was uti-
lized to listen for data packets transferred over the Insteon RF network as shown in
command snippet 4.1. An Insteon RF standard packet is nine bytes long. Byte zero
is a packet flag to assist in routing. Bytes one through three and four though six are
destination and source addresses, respectively. These three byte addresses are what
Insteon claims is the basis of their security and that they are not revealed to a user
during normal operation. Unfortunately, they are merely encoded in transmission
33
48. 4. IMPLEMENTATION ASSESSMENT
allowing complete disclosure once that encoding has been reversed. Bytes seven
and eight are commands and byte nine is an error checking cyclical redundancy
check (CRC).[79]
The packet crafting and message forgery process requires addressing data from
a data capture. Reversing the addresses allows an attacker to assume a trusted
source address. Since this is the only security control offered by the Insteon pro-
tocol, a valid data command can now be sent to the target network node. The
data packet crafted in command snippet 4.2 is similar data from the data packet
captured in command snippet 4.1. The addressing has been reversed and the com-
mand in byte eight has been changed from 00 to FF. In the case of this command,
this actuates a lighting dimmer to full strength.
1 # ./rf_reciv.py | ./print_pkt.py
2 bandwidth 187500.0
3
4 25 : B0 C9 2C : ED A5 39 : 11 00 90 crc 90
5 21 : B0 C9 2C : ED A5 39 : 11 00 54 crc 54
Listing 4.1: Listening for RF data packets
1 # ./send_comm.py -r 01 : ED A5 39 : B0 C9 2C : 11 FF 5B | ./
rf_send.py
Listing 4.2: Packet crafting and transmit
4.3.3 SmartThings Assessment Findings
4.3.3.1 Standard Operation as Tested
The Samsung SmartThings ecosystem is centrally controlled via the SmartThings
Hub. The hub is provisioned through a mobile application that is available on most
mobile device platforms. The mobile application connects to an external server
that is publicly available. Commands are routed from the mobile application, up to
the external service. A connection is made outbound from the hub to the external
service to retrieve commands and allow a user to interact with it.
The hub can communicate using ZWave and Zigbee. Both have their own ra-
dio transceiver and communicate at 908.42Mhz and 2405-2470Ghz respectively. A
Bluetooth radio is also on the PCB, however, at the time of testing, this was dis-
abled. For the purposes of this project, only the ZWave communications channel
was tested.
4.3.3.2 Remote Access
All access is essentially external access since the only way the mobile application
and the hub communicate are through the external server provided by the vendor.
This eliminates the requirement for a TCP port to be forwarded from the public
network into a user’s LAN. This also introduces a potential ability for an attacker
to gain control of the hub remotely.
A user can communicate with the SmartThings hub using a mobile or web
based application.
34
49. 4.3 INTERNET OF THINGS ASSESSMENT FINDINGS
Vulnerability Ratings - Insteon
CVSS
Score
Description Impact
9.7 RF transmission
capture and
replay
Complete control over system and system
nodes, ability to affect availability and mes-
sage integrity
10.0 RF data message
forgery
Allows an attacker to craft packets to carry
out any command. This does not require
a pre-captured RF signal, only some recon-
naissance to determine network architecture
and available nodes.
7.2 Local file system
access
With local file system access available by
booting a side-loaded operating system, se-
curity configurations can be altered and ad-
ditional details about the device are obtain-
able.
Score Vuln info Impact
Score Vuln info Impact
Table 4.5: Insteon - CVSS Vulnerability Scoring Matrix
4.3.3.3 Physical Inspection
On inspection of the SmartThings hub, a tamper evident sticker is placed atop one
of the screw holes that is required for removal prior to disassembly. The printed
circuit board (PCB) appears to be a custom, purpose built board specific to this ap-
plication. Two antennas are visible in Figure 4.6 on both sides of the bottom of the
board. These are 2.4Ghz antennas and are provided for the Bluetooth Low-Energy
(BLE) radio that is currently dormant and the other for Zigbee communications.
On the reverse side top of the board, the Zigbee daughter board is visible.
4.3.3.4 RF Analysis
The SmartThings hub contains three discrete radios for device communication. The
first is an integral transceiver for communicating with Zigbee devices at 2405-2470
Ghz. This is the native communication method and the one employed by Samsung
marketed network nodes. The second radio is a daughter card that is soldered onto
the reverse of the PCB. Operating at 908.4 Mhz, this hardware allows the hub to
communicate using the Z-Wave [95] protocol. The third and final radio is integral
to the PCB and uses Bluetooth version 4, low energy. This chip is currently inactive
and future use is unknown.
While Z-Wave can be configured to use encryption, most network nodes are not
35
50. 4. IMPLEMENTATION ASSESSMENT
Bluetooth Radio
Zigbee Radio
ZWave Radio
Figure 4.6: SmartThings Hub (Left, bottom of board. Right, top showing Zigbee
radio)
configured to use it. Encryption is optional and it is up to the device manufacturer
whether or not they implement it. As shown in section 3.3.1 of chapter 3 when
encryption is enabled on Z-Wave, vulnerabilities are limited to very specific time
periods and are typically a result of poor implementation.
Several tools have been released in the last three years to analyze and exploit
Z-Wave devices including:
1. Z-Force [5],
36
51. 4.3 INTERNET OF THINGS ASSESSMENT FINDINGS
2. Scapy-Radio [70] and
3. EZ-Wave [30].
Z-Force is targeted at a very specific type of attack and uses hardware that is
not very flexible, thus it is not a good fit for general purpose testing. Scapy-Radio
is more generalized, utilizing standard hardware and a familiar interface to most
security professionals, the Scapy Packet Crafting Library [7]. This is a good tool for
general testing and was used during this assessment.
EZ-Wave goes a step further to provide tools that wrap Scapy-Radio allowing
functions to be more accessible to testers. These tools allow easy detection of the
home ID and node IDs. The GRC file included with the EZWave code library allows
direct decoding of hexadecimal packet data for analysis.
Consider the following decoded packet data:
1 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 01 41 09 0d
2 0010: 05 20 01 ff d8
3
4 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 05 03 09 0a
5 0010: 01 43
6
7 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 01 41 0a 0c
8 0010: 05 25 02 23
9
10 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 05 41 08 0d
11 0010: 01 25 03 ff de
In this transmission, the SmartThings hub is sending a command to an in-wall
GE outlet (part number 12721). SmartThings documentation [80] was used to de-
cipher command bytes and EZWave’s ezstumbler.py [30] tool was used to find the
home ID and node IDs. The home ID is determined to be e2 1c ea ac. This is
the address that uniquely identifies this particular SmartThings network from any
neighboring networks. The first eight bytes serve as the preamble and sync the RF
transmitter and receiver to allow for data to be sent. The home ID follows, then the
source address of the sending device. In the first block of hexadecimal, this is 01
which is the central hub. The next three bytes are a header, data length and request
type, respectively. 05 is the destination address of the outlet.
With the basic packet structure set forth, here are the commands being passed
from the central hub to the in-wall outlet in the first block of hexadecimal:
• 20 tells the target that this is a basic command,
• 01 is the command for a set action,
• then FF tells the target to turn on.
In the next hexadecimal block, the outlet responds with an empty acknowledg-
ment frame. Then in the third block, the hub requests the status of the outlet, which
responds in the fourth block that it is on (FF).
Note that all commands in both directions are sent in the clear with nothing
more than a checksum (the very last byte in each block) verifying that the data is not
corrupt. This allows command replay without decoding of messages. ZWave does
37
52. 4. IMPLEMENTATION ASSESSMENT
not implement source filtering when encryption is not in use. When encryption is
in use, rogue control is not possible.[31]
The preceding was an example of a basic device without encryption. Below
is an example of a secure device, a Schlage Electronic Touchscreen Deadbolt (part
number BE469NX CEN 626) that does employ encryption:
1 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 01 41 07 0c
2 0010: 04 98 40 d0
3
4 0000: 01 00 00 00 00 00 00 00 55 04 04 02 a0 02 00 28
5 0010: 02 00 28 3e 0a a0 80 82 aa aa aa aa aa aa aa af
6 0020: 82 a8 20 20 55 55 55 55 55 55 55 55 f0 55 04 04
7 ...
8 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 04 03 08 0a
9 0010: 01 43
10
11 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 01 03 01 0a
12 0010: 04 4a
13
14 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 01 41 09 21
15 0010: 04 98 81 61 77 a5 ce b0 c6 09 c0 ab e2 c8 a7 f7
16 0020: fb a0 1d 6e 87 5c ac ec 92
17
18 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 01 41 0a 0c
19 0010: 04 98 40 dd
20
21 0000: 01 00 00 00 00 00 00 00 55 04 04 02 a0 02 00 20
22 0010: 02 00 00 3e 0a a0 80 82 aa aa aa aa aa aa aa af
23 0020: 82 a8 20 20 55 55 55 55
24 ...
25 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 01 41 0b 0c
26 0010: 04 98 40 dc
27
28 0000: 01 00 00 00 00 00 00 00 55 04 04 02 aa 02 a0 28
29 0010: 00 a0 0a 3e 0a a0 80 82 aa aa aa aa aa aa aa af
30 0020: 82 a8 20 20 55 55 55 55 55 55 55 55 f0 55 04 04
31 ...
32 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 01 41 0b 0c
33 0010: 04 98 40 dc
34
35 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 04 41 01 14
36 0010: 01 98 80 1c ee f1 4b bf 6b 66 fc 08
37
38 0000: 01 00 00 00 00 00 00 00 e2 1c ea ac 01 41 0c 20
39 0010: 04 98 81 d5 83 14 32 ac 9b 82 14 80 64 2a 1c 41
40 0020: dc 84 ec 17 0e a5 d3 af
In this example, the deadbolt is node ID 04 and is communicating with the cen-
tral hub (still 01). The key option command in this communication is the 98 value
that immediately follows the destination address in each frame. Command code
98 tells the central hub and the device node that all data sent between them should
be encrypted. This is optional and the vast majority of devices do not employ this
feature. The frames that start with 55 after the preamble are encrypted packets and
cannot be replayed or otherwise attacked without breaking or finding an imple-
38
53. 4.3 INTERNET OF THINGS ASSESSMENT FINDINGS
Vulnerability Ratings - SmartThings
CVSS
Score
Description Impact
9.7 RF transmission
capture and
replay
Complete control over system and system
nodes, ability to affect availability and mes-
sage integrity. Note: This finding does not
include devices that employ encrypted com-
munications.
10.0 RF data message
forgery
Allows an attacker to craft packets to carry
out any command. This does not require
a pre-captured RF signal, only some recon-
naissance to determine network architecture
and available nodes. Note: This finding
does not include devices that employ en-
crypted communications.
Table 4.6: SmartThings - CVSS Vulnerability Scoring Matrix
mentation error in the cryptography [5] that is protecting them. ZWave employs
AES 128.[95]
4.3.4 SimpliSafe Assessment Findings
4.3.4.1 Standard Operation as Tested
The SimpliSafe system is designed to be used without a computer or additional de-
vice of any kind. A USB stick allows some configuration parameters to be changed.
This was accessed using a web browser on a computer using an Adobe Flash web
page saved on the USB stick. The USB stick is also remote control that allows the
user to change the mode of the system from off to away and also has a panic button.
Nodes were added to the central hub by putting the system in test mode from
the keypad. The keypad serves as the only integrated user interface for the system.
Once in test mode, devices were added by actuating them, powering them on or
pressing a momentary switch located on the device. In the SimpliSafe ecosystem,
most nodes are transmit only, meaning they do not receive any RF communication.
The keypad and the central hub are the only transceivers; the siren is receive only.
The system is designed to have the ability to be monitored remotely through a
service offered by the vendor for an additional monthly fee. The central hub can
communicate through an analog modem connected to a hardwire telephone line or
through a cellular network connection. The service can alert the user or emergency
services.
The SimpliSafe ecosystem has no known update process, nor are the hardware
integrated circuits capable of a field update.[94] This means when vulnerabilities
are discovered, no means of remediation is available.
39
54. 4. IMPLEMENTATION ASSESSMENT
4.3.4.2 Remote Access
End user remote access is only available with the vendor provided additional mon-
itoring service. It allows control of the system remotely through a mobile applica-
tion. The model of avoiding a broadband Internet connection avoids external net-
work attacks through the Internet. The addition of the cellular modem, however,
introduces an addition potential point of entry.
4.3.4.3 Physical Connection
Very recent research on this ecosystem shows that the keypad can be re-purposed
with the addition of a micro-controller into an attack device.[94] This conversion is
possible because test points on the PCBs of the keypad and the central hub allow
access to the underlying communication on the PCB itself before it gets sent to the
RF transmitter for broadcast.
4.3.4.4 RF Analysis
The SimpliSafe ecosystem contains only two transceivers, the keypad and the cen-
tral hub. All sensors are transmitters only, and the audible siren is a receiver only.
Communications from the keypad are transmitted at 433.920Mhz and the central
hub receives at that frequency. The keypad receives signals from the central hub at
433.920Mhz. All sensors transmit at 433.920Mhz. This is illustrated in Figure 4.7.
The RF Protocol is outlined in the FCC test report with additional details as
follows:
1. 315Mhz and 433Mhz frequencies are in use,
2. amplitude shift keying (ASK) modulated and
3. pulse interval and width modulation (PIWM) encoded.[65]
Command RF transmissions from the keypad and key fob remote were able to
to be sniffed, recorded and replayed successfully. These commands included mod-
ifying the state of the alarm from home to away and even panic mode. While the
keypad requires a personal identification number (PIN) code before transmitting,
the key fob remote does not. Sensors were able to be replayed as well. No cryp-
tographic protections are in place on the RF data transmissions for any devices in
the SimpliSafe ecosystem. An effective replay attack is one where the system is put
into test mode. This disables all the sensors and does not require the PIN.
Sample capture and replay attacks are shown in figures 4.8 and 4.9 respectively.
In Figure 4.8 the block titled ”osmocom Source” is the interface to the SDR hard-
ware, and because it is configured to be the source, this will put the SDR into receive
mode. This allows configuration of the receive frequency and a few other options.
The ”File Sink” block details the capture file options. The block titled ”WX GUI
Scope Sink” allows a visualization of the RF transmission as shown in Figure 4.10.
Full reverse engineering of the SimpliSafe RF data protocol has recently been
achieved[65], however, no PoC tools have been released to date. It was determined
that, aside from using an obscure encoding, no cryptographic protections exist and
RF packet data can be fully read, crafted and delivered to the target system.
40
55. 4.4 ASSESSMENT SUMMARY
Transmit
433Mhz 315Mhz Receive
Door
Sensor
Door
Sensor
Motion
Sensor
Audible
Alarm
SimpliSafe Hub Keypad
SimpliSafe Architecture
Figure 4.7: SimpliSafe Architecture
Alerts upon specific events (system state changes, entering test mode, sensor
actuation if in the away state, etc.) are reported to the user via the remote moni-
toring service via text messaging or mobile application alerts. If the service (which
is an additional fee) is not in use by the end user, these alerts are never received.
Audible feedback is output from the central hub also during these events; however,
if the user is not within audible range or not at home, they will not be alerted.
4.3.4.5 Vulnerability Ratings
4.4 Assessment Summary
There were common themes in the three ecosystems tested in this chapter. All three
were vulnerable to RF message replay. Only a single system tested had an option
for encryption and this was not the default configuration.
While assessment of RF communications required some specialized skills such
as using software defined radio hardware and supporting software, this is becom-
ing much more accessible. More wireless communications protocols are being re-
verse engineered with releases of PoC programs and open sharing of information
and code via public repositories. Almost all information security conferences have
41
56. 4. IMPLEMENTATION ASSESSMENT
Figure 4.8: SimpliSafe Capture GNU Radio Companion Signal Flow Graph
Figure 4.9: SimpliSafe Replay GNU Radio Companion Signal Flow Graph
an area dedicated to learning this skill and many resources are available online to
acquires these skills.[64]
42
57. 4.4 ASSESSMENT SUMMARY
Figure 4.10: GNU Radio Companion FFT Plot Visualization
Vulnerability Ratings - SimpliSafe
CVSS
Score
Description Impact
10.0 RF data message
forgery
Allows an attacker to craft packets to carry
out any command. This does not require
a pre-captured RF signal, only some recon-
naissance to determine network architecture
and available nodes.
9.7 RF transmission
capture and
replay
Complete control over system and system
nodes, ability to affect availability and mes-
sage integrity
10.0 Inability for up-
date
Due to the inability to field update the Sim-
pliSafe hardware, the product effectively is
sold as end of support since support is un-
able to effectively remediate any vulnerabil-
ities.
Table 4.7: SimpliSafe - CVSS Vulnerability Scoring Matrix
43
