Internet DRAFT - draft-farrell-iotsu
draft-farrell-iotsu
Network Working Group S. Farrell
Internet-Draft Trinity College Dublin
Intended status: Informational May 20, 2016
Expires: November 21, 2016
Some Software Update Requirements
draft-farrell-iotsu-00
Abstract
The importance of software update as a mitigation for vulnerabilities
discovered after deployment is widely recognised for both desktop and
data centre applications and infrastructure. However, in the case of
smaller devices, whether running on challenged networks or platforms
or not, the situation is much worse, perhaps a decade or more behind
that in better developed contexts. This memo proposes requirements
for software update in situations where none is currently deployed,
argues that that is the right target. In doing this, and perhaps
somewhat in contrast to a vendor-driven approach, the interests of
the individual device owner are emphasised.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 21, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Farrell Expires November 21, 2016 [Page 1]
Internet-Draft Some Software Update Requirements May 2016
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Arguments for some infrastructure . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Informative References . . . . . . . . . . . . . . . . . 8
8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This is a contribution to the IoTSU workshop. [1] It is not expected
to ever become an RFC, but who knows?
The context for this memo is software update for devices that today
lack a workable software update mechanism. That includes many or
perhaps most very small (sometimes so-called "IoT") devices such as
sensors and actuators, but also larger devices, such as printers,
hubs and switches, WiFi access points and home routers. While there
will be some implementation and deployment differences between
different classes of device (e.g. very tiny devices might struggle
with more onerous cryptography or network connectivity requirements),
we believe many similar requirements apply in all these cases so
considering common solutions and frameworks should be technically
tractable.
All code has bugs that will need fixing, and all systems of whatever
size will run code that includes bugs. (The author would welcome a
better reference than this blog. [2] ) And some bugs will make a
system vulnerable to failure. So the base requirement is to be able
to update code to fix bugs and make systems less vulnerable. In
addition to inadvertent bugs however, there are also bad actors on
the Internet, who will search for and exploit vulnerabilities
wherever those are found. Devices deployed for any extended duration
will inevitably be subject to such attack.
Farrell Expires November 21, 2016 [Page 2]
Internet-Draft Some Software Update Requirements May 2016
It is important to recognise that the searching-for part of that is a
solved problem for the public IPv4 Internet [zmap] and is likely to
be solved for the public IPv6 Internet. [RFC7707] And even if some
devices are not directly accessible from the public Internet, many
are, [secconsult] and transitioning "sideways" inside a breached
network is a standard mode of operation for attackers and can be
automated.
One might object that some smaller devices are not really sensitive,
e.g. that a bad actor taking over a single thermostat, while
possible, could be harmless. Such bad actors may however be
attempting to leverage one vulnerabilitiy as a lauch-pad to attack
other systems, as was the case with the Heating, Ventillation and Air
Conditioning (HVAC) system used to start a major recent breach,
[target] or as part of a pervasive monitoring [RFC7258] attack.
If we do manage to get a software update mechanism deployed, that
system may itself include vulnerabilities. So if, as seems likely,
cryptography is used to authenticate updates, then the signing keys
used will be a very tempting target to attack. [update-msc] Such
attacks are also more likely to succeed if there are very many such
signing keys maintained by many vendors, some of whom will not be
particularly well qualified to do that particular job. Some other
vendors might even try to use a software update mechanism as part of
a strategy to lock-in their customers. While no software update
mechanism is likely to be able to counter such business choices, from
the device owner perspective a vendor acting in that way is yet
another bad-actor, and ought be treated as such. Both of these
issues point towards considering a set of requirements and solutions
where it is possible for some third parties to be involved in
software update for many developers of devices.
One conclusion to reach here is that all devices are currently
vulnerable to attack. If we select a random device, it may be that
nobody knows the currently viable attacks that would work today, but
we certainly know that some vulnerabilities are known, or will be
found, for that device, once effort is expended on finding those. It
is therefore, in the author's opinion, irresponsible to deploy
devices for extended durations that we know have vulnberabilities,
even if those are currently unknown, without some workable form of
software update. It follows that all devices require software
update.
2. Arguments for some infrastructure
Earlier, we described the context here as relating to those devices
deployed on the Internet for which no working software update
mechanism is deployed. That is a little different from the scope of
Farrell Expires November 21, 2016 [Page 3]
Internet-Draft Some Software Update Requirements May 2016
the workshop call for papers, which focused only on the so-called
"IoT" space. In this section, we provide arguments for why that
broader scope is the better one.
So long as there are any widely deployed devices with no software
update, those will be exploited. It therefore makes sense to at this
stage consider a broader range of devices than only those that are
most-constrained. "Solving" the problem for only a specific class of
device or network does not solve the problem.
The existence of open-source software and hardware, as well as
"mixed" products (e.g. closed-hardware running some variety of
almost-all GPL'd linux code), together with the number and size of
the vendors of such equipment, means that such vendors and specific
device deployments will not be of sufficient scale to by themselves
support a specific software update infrastructure. Some sharing of
infrastructure is therefore required, and that means that it's very
unlikely that such infrastructure will be completely specific to one
class of device or network.
Even where a vendor has found or been informed of a vulnerability,
and has developed a patch or update, there are still many issues
around the distribution of that. (Here's [3] a timely case in
point.) Arguably, announcing but then failing to effectively
distribute updates is worse than doing nothing, as patches themselves
can be a source for malware developers. There is also a major
difficulty with locating patches and with typing of update containers
(tarball, zip, OS-specific executable, etc) that needs to be
addresses in a more scalable manner over many vendors.
Devices in homes that benefit from software update will likely need
to connect to some service on the public Internet in order to poll
for updates. Let's assume all such traffic is encrypted as is
proper, typically via use of TLS with server authentication. We need
ways in which we can distinguish that traffic from potentially
nefarious spying being done by devices. If many devices poll some
pieces of shared infrastructure that only support software update
then the probability that we engineer that well, and that workable
control features are developed for end-user or home networks
increases.
Vendors buy and sell one another, and cease to exist and products are
end-of-life'd. Open-source projects can wither away over time. All
of those mean that we need some form of infrastructure that will
still be present despite such changes.
Device owners cannot be expected to know much or anything about
software update, so any measures of quality or attempts to detect
Farrell Expires November 21, 2016 [Page 4]
Internet-Draft Some Software Update Requirements May 2016
misbehaviours will require some form of observatory or audit. That
means that we need there to be an auditable number of sources for
distributing software updates. Wth O(10^3) or fewer sources, that
seems quite doable. With O(10^6) sources, that would appear to be
significantly harder.
3. Requirements
In this section we posit some requirements for software update. We
do not intend this to be an exhaustive list, but rather to be a list
that captures key requirements for systems that do not currently have
a working software-update mechanism.
We also make no claim that this is an authoritative list, rather this
is a list to try start a discussion with those who implement and
deploy devices and the software update infrastructure those will
need.
In the author's opinion, the actual deployment of some software
update scheme is far more important than meeting any specific subset
of these requirements - once we can update a system then we can fix
anything, given enough time and interest. (That seems to indicate
there will be value in trying to construct a minimal list of
requirements.)
Requirements posited below are numbered for ease of reference.
R1 All devices that have software or firmware that can be updated
should be able to use a software update infrastructure developed
to meet these requirements, regardless of whether that device is
open- or closed-source, is made by a for-profit vendor or a
community or academic projecct.
R2 One device can require software update from multiple sources,
e.g., there can be different chips on a single board from
different vendors. Or a larger device might have a "native"
operating system inside which various containers are used to run
applications, possibly with entirely different operating systems.
R3 Those update systems might need to co-operate, e.g. so that
only one object needs to be downloaded to update multiple
subsystems within the device.
R4 That co-operation might simply involve some kind of
packaging of different otherwise indpendent sofware
update objects so that co-ordination is mostly around
transport and some form of meta-packaging.
Farrell Expires November 21, 2016 [Page 5]
Internet-Draft Some Software Update Requirements May 2016
R5 Co-operation might require that one system under the
device owner's control act as a local server for software
update. In the case of a device with a "native" and
several "guest" OSes, one of these might be seen by the
others as the source of software updates.
R6 In other cases, the device can take part in multiple
independent software update schemes, with no co-ordination
being needed.
R7 Data origin authentication is required, and overwhelmingly likely
to be provided via a digital signature mechanism.
R8 There may be some systems where signature verification does
not happen on the device to be updated but instead on some
other upstream device - this can be because of algorithm
implementation issues, or due to issues with Public Key
Infrastructure (PKI) if say signature verification requires
certificate status checking, which requires support for HTTP,
which can again be too onerous for some systems.
R9 More than one PKI may need to be supported in updating even
one device. There are widely deployed systems based on an
X.509 PKI, others based on OpenPGP and perhaps others based
on home-grown concepts similar to a PKI. [update-msc]
R10 It is very likely that multiple signers may need to be part
of a solution, e.g. authenticating the orgin of the software
separately from the download repository or perhaps separately
authenticating the origin of a collection of updates from
that for each member of a collection.
R11 It needs to be possible for sources of software to change, under
the control of the device owner. The relevant software sources
may or may not be co-operating with such changes.
R12 In the case of end-of-life devices, if there is a (typically
open-source) community who could manage future updates then
it is important to enable this without the device owner
having to hack into ("root") their own device. (That last
should be considered an anti-pattern in this context.)
R13 There may be devices where a choice of software sources
exist. While there may be challenges in how to offer a user
interface to allow the device owner such a choice, it must be
possible to offer such choices where they exist.
Farrell Expires November 21, 2016 [Page 6]
Internet-Draft Some Software Update Requirements May 2016
R14 Devices will need to poll for software update. It seems unlikely
that most devices can act as a server listening for incoming
connections from software sources. That means that devices will
need to establish a way to connect to a software source, or some
entity who can distribute updates.
R15 When the device is in the home, or carried on a person, then
there are significant privacy issues that arise. While in
those cases, encrypting the interactions may be required, it
may also be required that it is clear to the person (or their
home network) that all that is happening is software update.
To give a concrete example, the author would be happy if a
television called home to check for a software update, but
very unhappy if the same device called home to tell someone
what channel changes are occurring.
4. Security Considerations
While software update does mitigate vulnerabilities, it also creates
new vulnerabilities. First, software signing private kes are a
hugely attractive target, and have subject to real attacks in the
past. [flame]
The software updates that are distributed are also usable to re-
create the vulnerabilities that are being fixed, so that unpatched
systems are put at further risk once the patch details reach a bad
actor, which is impossible to prevent. Automation of attack-
generation code is also possible, [auto] though still difficult.
That could allow bad actors to exploit the time window during which
updates propogate to the deployed base. There are therefore good
reasons to try to minimise this duration.
Patches can also include new vulnerabilities. While this is true,
that is out of scope for this document which considers the software
update mechanisms and not the quality of the software being updated.
5. Privacy Considerations
If the software update mechanism exposes any correlatable identifier
then it becomes a useful way to track people who carry devices that
poll for updates.
Devices within homes or vehicles or other sensitive locations can
also expose privacy sensitive information via the software update
mechanism. For example, if the device polls the update server on
power-on, and if power-on is associated with some event such as a
homeowner arriving home, then the existence of the packets
Farrell Expires November 21, 2016 [Page 7]
Internet-Draft Some Software Update Requirements May 2016
(regardless of encryption) leaks some possibly privacy sensitive
information.
We will likely want to use a confidentiality service in order to not
expose identifiers to network attackers. That creates the potential
for the device to use the software update channel (or any other
indistinguishable channel) as a covert channel. Devices have been
known to exfiltrate privacy sensitive data for the benefit of the
device maker [refs] so if we can provide some way to increase
confidence that only software update is happening, then that can be
beneficial for all concereed (except bad actors). It may help if
many devices poll some well-known services/hosts on the Internet and
do not call-home to the device maker's network.
6. IANA Considerations
This document makes no requests for IANA action. This section would
be removed except it won't be as we're not aiming for publication as
an RFC.
7. Acknowledgements
TBD - your name here for comments or beer! But that assume there'll
be another revision of this which may not happen.
8. References
8.1. Informative References
[auto] Brumley, D., Poosankam, P., Song, D., and J. Zheng,
"Automatic patch-based exploit generation is possible:
techniques and implications", 2008,
<http://ieeexplore.ieee.org/xpls/
abs_all.jsp?arnumber=4531150>.
[flame] Sotirov, A., "Analyzing the md5 collision in flame", 2012,
<http://citeseerx.ist.psu.edu/viewdoc/
download?doi=10.1.1.675.2256>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<http://www.rfc-editor.org/info/rfc7707>.
Farrell Expires November 21, 2016 [Page 8]
Internet-Draft Some Software Update Requirements May 2016
[secconsult]
Viehbock, S., "House of Keys: Industry-Wide HTTPS
Certificate and SSH Key Reuse Endangers Millions of
Devices Worldwide.", 2015, <http://blog.sec-
consult.com/2015/11/
house-of-keys-industry-wide-https.html>.
[target] Weiss, N. and R. Miller, "The target and other financial
data breaches: frequently asked questions", 2015.
[update-msc]
Ruissen, P. and R. Vloothuis, "Insecurities within
automatic update systems v1. 16", 2007,
<https://staff.science.uva.nl/c.t.a.m.delaat/rp/2006-
2007/p32/report.pdf>.
[zmap] Durumeric, Z., Wustrow, E., and J. Halderman, "Zmap: fast
internet-wide scanning and its security applications.",
2013.
8.2. URIs
[1] https://down.dsg.cs.tcd.ie/iotsu/
[2] https://amartester.blogspot.ie/2007/04/bugs-per-lines-of-
code.html
[3] http://arstechnica.com/security/2016/05/foul-mouthed-worm-takes-
control-of-wireless-isps-around-the-globe/
Author's Address
Stephen Farrell
Trinity College Dublin
Dublin 2
Ireland
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie
Farrell Expires November 21, 2016 [Page 9]
