Most IoT systems consist of three components:
1) The "smart" device itself, capable of communicating via a protocol
such as Z-Wave, Zigbee, Bluetooth or IEEE 802.11, running either a
full operating system (commonly based on the kernel Linux) or an
embedded OS designed for this purpose.
2) A remote service provided by the device manufacturer. The smart device
communicates with this service in order to provide information about its
current state and in order to provide an interface for users to control
the device.
3) An application designed for mobile platforms which interacts with the
remote service and allows control of the smart device regardless of
whether the user is currently located near the device or not.
Devices that use the Zigbee or Z-Wave protocols also typically require a
local "hub," a device running interface software that bridges the
devices to the remote service.
There are multiple significant security concerns around this design
pattern. The first is that either the smart devices themselves or the
hub that they communicate with require Internet access. Depending on
local network configuration, this may result in the devices being
visible to the public Internet. These devices inherently provide a
service of some description in order to permit their integration with
the remote services, but frequently also provide additional services
for directly local communication and often include further unnecessary
services used for diagnostics during the design and production stage
(such as MicroCell -- the same backdoor was present on a series of
baby monitors shipped by a major manufacturer).
These devices are often locked down in such a way that it is impossible
for the user to replace the software that they run. These devices are
also often abandoned by their manufacturers after a short space of time
due to them being either discontinued or replaced by newer devices.
Users who continue using these devices are thus at significant risk,
without any real chance of security updates being made available and
frequently without any notification that any security issues have been
identified. If any issues are identified, then without the permission of
the manufacturer it is impossible for any third party to provide aid to
said users.
This concern is frequently mitigated by typical home network setups that
restrict external access to internal devices. But smart devices
inherently require external access to be possible, and this
functionality is provided by the remote service. The smart device
connects to the remote service and awaits commands -- users in turn
connect to the remote service and send commands.
These remote services are themselves frequently insecure. Authentication
details are often sent in plaintext, allowing anyone who can observe
network traffic to obtain credentials. Some systems involve no
authentication at all (for instance). This makes it possible for a
malicious individual to gain control over home devices, in some cases
potentially even being able to execute arbitrary code on said devices
and gain access to the internal network.
If vendors are unwilling or unable to fix these security issues, users
are left in an unfortunate position. They can either retain the
convenience provided by the smart devices they paid for, or they can
remove them and attempt to obtain a refund. The worst case scenario is
perhaps when the vendor unilaterally decides to shut down the remote
service, rendering the devices useless.
Another consideration is the behavior of the manufacturer itself.
Manufacturers may not always act in the interests of their customers,
doing things ranging from invasive collection of personal data to
intrusive advertising or even disabling device functionality remotely.
Even if ostensibly permitted by terms of service, users should be able
to protect themselves against such scenarios.
There is an alternative. Third-party free software alternatives to the
pre-installed software are common in certain market segments, such as
home routers (libreCMC, OpenWrt and DD-WRT, for instance).
Security vulnerabilities can be mitigated by replacing the original
software with a functional equivalent provided by a third party.
Unfortunately, many IoT devices are designed such that the software can
only be replaced by the manufacturer. The software will only communicate
with the manufacturer's remote service -- no third party can provide a
functional equivalent.
To ensure that users do not end up in a situation where they are left
choosing between security and convenience, or left with no ability
whatsoever to use the devices they bought, it is vital that these
devices be ultimately under the control of the user. The user should be
able to replace the software on the device in order to fix security
vulnerabilities. The user should be able to modify the software on the
device such that it communicates with a different remote service that
provides strong security guarantees. The user should not be left with no
option other than to discard the device and replace it with a new
version.
In order for this to be possible, it is necessary to know how the
devices communicate with the remote server. Unfortunately this is
frequently in the form of a proprietary protocol that lacks any public
documentation, and as such it is a significant engineering effort for
anyone to implement a replacement service. Several well-known protocols
exist for controlling remote devices (such as MQTT) and re-using
these rather than proprietary protocols makes it easier to both
identify whether any security issues exist (being forced to reverse
engineer a protocol may result in missing subtle aspects that cause
security issues) and provide alternative implementations in the event of
significant security flaws being discovered or the vendor choosing to
cease support of the remote services.
To that end, we encourage the adoption of practices that:
a) Ensure that documented and freely-implementable (rather than
patent-encumbered) protocols be used for communication between smart
devices and remote services, and
b) Ensure that owners of smart devices are able to replace their
software with implementations provided by either themselves or third
parties in order to prevent the vendor being a single point of failure
in either service
c) Strongly encourage the use of free "as in freedom" software
throughout the entire stack, making it easier for security researchers
to identify issues, third parties to provide alternative
implementations and users to retain as much control as possible over
devices that will become increasingly integrated into their homes and
lives.
Matthew Garret is a member of the FSF's board of directors.
This was submitted in response to the Commission on Enhancing National Cybersecurity request for information about current and future states of cybersecurity in the digital economy.
]]>
