[tor-project] LWN on the Internet of Onions

[Nathan Freitas]

A good story went up here: http://lwn.net/Articles/695910/ and is
getting some props on hackernews as well
(https://news.ycombinator.com/item?id=12225998).

****
The Internet of Onions
By Nathan Willis
August 3, 2016

The tension between convenience and security is age-old, but it has,
perhaps, never been as acutely felt as it is in debates about the
Internet of Things (IoT). Smart devices for monitoring and controlling
household and industrial appliances are cheap and near-ubiquitous. But
the cheapness and the near-ubiquity of the commercial IoT products on
the market both come at the cost of exposing one's devices and home
network to eavesdroppers and remote servers. A Tor developer recently
undertook an effort to increase IoT security by routing device traffic
through the Tor network. While the work is, so far, available only in a
single free-software IoT platform, the developers are hoping it will
spread.

Tor developer Nathan Freitas, who is also Executive Director of the
Guardian Project, undertook the the development and testing of
Tor-transport support for the open-source home-automation program Home
Assistant. On July 20, Freitas explained the project in a blog post.

Home invasions

In brief, Home Assistant is a Python-based tool that provides a single
web interface for a wide range of individual IoT devices. Freitas's
contribution is a network configuration that routes Home Assistant's web
interface over a Tor Hidden Service (so that it can only be accessed by
a Tor-enabled browser via a special .onion domain name).

In a demonstration video [YouTube], Freitas calls attention to two
separate concerns about commercial IoT devices. The first is that many
expect to have direct access to the Internet, often for an HTTP
connection to a remote service, and the installation instructions advise
users to enable access by simply opening up ports on their firewall (if,
indeed, they have one to begin with).

The risk is that attackers can easily scan for the signatures
known-to-be-insecure IoT products, log them, and access the devices at
will. This is rather dangerous, when one considers that IP-based video
cameras, climate controls, door locks, and other sensitive devices are
exposed in this manner.

The second concern is that many products enable device operation solely
through a remote web server controlled by the manufacturer; the
addresses of these servers may even be hard-coded into the device's
software. For the curious, Matthew Garrett has recently taken to writing
in-depth reviews of such products on Amazon.com, with both informative
and frightening results.

Some privacy-conscious users may understandably regard the second
concern as the more serious one, since pervasive data logging and user
tracking could be taking place at the remote server (not to mention the
fact that the device could fail to function without an Internet
connection). For many others, however, the first risk is greater.
Stories of webcam and baby-monitor exploits are already commonplace; as
more device classes go online, one can only expect further attacks. As a
result, securing access to the web interfaces of IoT devices has been
the initial focus of Freitas's effort.

Hiding the route

Merely routing the web interface over Tor goes a long way to protect
users from the eavesdropping concern, but if the device's front end is
reachable through its .onion address, it can still be detected and
scanned on the Tor network, as the 2013 paper Trawling for Tor Hidden
Services [PDF] explains. The technique described in the paper involves
running a large set of Tor relay nodes that secretly log the appearance
of hidden service nodes. Although the distributed-consensus model Tor
employs makes it difficult for any attacker to shut out the legitimate
relays (another possible attack), a well-funded attacker could certainly
monitor the availability of hidden services over time and hone in on
their locations using traffic correlation.

The solution is to enable a little-known "stealth" authorization option
in the service's configuration. Setting the HiddenServiceAuthorizeClient
to stealth on the server causes Tor to generate a random authorization
key pair, so that the public key can be copied to each device that
should be allowed to access the service.

>From that point on, the nodes in the Tor network provide additional
security beyond what would be achievable with (say) a standard HTTP
cookie, blocking connection requests from clients without the proper
credentials by reporting that the requested server is unroutable.

This is possible because Tor hidden services announce their presence to
the network by publishing a service descriptor that normally includes
the address of an "introduction point" node. The service descriptors are
tracked in Hidden Service Directory nodes within the Tor network. Other
Tor relay nodes then know how to establish a circuit to the service by
looking up the introduction point, even though those relays cannot peek
beyond the introduction point to find where the service originates.

In stealth mode, however, the introduction-point portion of the service
descriptor is encrypted with the private key from the authorization key
pair; authorized clients will be able to decrypt the descriptor field
because they possess the corresponding key, but other clients will not.
Attempts by unauthorized clients to connect to the introduction-point
node listed in the service descriptor will fail as being unreachable,
making the result indistinguishable from a hidden server that has simply
gone offline.

There is no limit to the number of authorization keys a server can use,
so each client can use a unique key and the keys can be replaced as
frequently as desired. Services are also allowed to publish fake service
descriptors to further obfuscate connection points from eavesdroppers
and trawlers.

Secure all the things

In an email, Freitas noted that there are two challenges to adding Tor
support to a project like Home Assistant. The first is that the
program's network layer has to be able to work using an .onion
address—which, evidently, breaks many assumptions about host-name
formatting and lookup.

The second is that the code dealing with the IoT devices themselves is
prone to unintended connection leakage. For example, he said, "with Home
Assistant there are a lot of outbound connections that it relies on for
access to public data that we also want to tunnel through Tor." As is
the case with HTTPS support, he added, fixing this is typically a matter
of finding developers willing to make sure the Tor routing works. "If we
can build a 'LetsOnion' type script to make that easier," he said, "we
will."

Moving forward, Freitas said he hopes to work on adding Tor support to
openHAB and similar open-source home-automation systems. In the
meantime, however, he said that users can route individual apps over Tor
using the Guardian Project's Orbot proxy for Android. By default, most
consumer IoT devices are paired with a one-shot app (one for each brand
of light bulb, one for the thermostat, one for the security cameras,
etc.). Orbot can tunnel these apps to a Tor endpoint running in the
user's home; the result is not as good as complete anonymity, perhaps,
but it is certainly superior to trusting the Internet unconditionally.
Developers, of course, can also build Tor-routing functionality into the
app directly—the Guardian Project's Netcipher library is designed for
that purpose.

The one remaining piece of the IoT puzzle is what to do about devices
that rely on maintaining a connection to a remote web server in order to
function. Some such devices can still function with only a LAN
connection, which can in turn be routed over Tor. Others, however, fail
to function if they cannot "phone home." At that point, the only
solution may be to avoid the device in question. Freitas said he was
investigating which IoT devices work in LAN-only mode and will try to
ensure that they can function when routed over Tor.

But which devices go into the home will ultimately remain the user's
choice. The security-versus-convenience trade-off has attracted a fair
amount of attention from highly technical users, but it remains to be
seen whether or not the industry as a whole will ever care. Freitas said
he hopes that the Guardian Project's IoT work can demonstrate that the
steps required to secure this class of device are small and easy to
take, if one is interested in the goal.