Re: [tor-talk] Thoughts on Tor router hardware

[Jason Cooper <tor@xxxxxxxxxxxxxx>]

Hi Rob,

On Tue, Feb 23, 2016 at 09:46:53PM +0100, Rob van der Hoeven wrote:
> The last month I have been playing with cheap Tor router hardware. This
> turned out to be quite a nice experience and it got me thinking about
> the benefits of running Tor on the router. 

There are many benefits, but see below...

> My conclusions are that running Tor on the router can enhance both
> security and usability.

I agree, with caveats.  Usability, yes.  Security is a bit more
complicated.

While there are definite, obvious improvements in security posture, such
as ease of configuration, isolation, and leak prevention; there are a
few landmines about.

The first problem is a good source of random numbers.  See some
discussion on the cryptography mailinglist, here [1].  Embedded systems
don't have RDRAND or RDSEED like x86 does.  Additionally, most lack
high-resolution timers.  Which are essential for extracting entropy from
interrupt timings and such.

Newer hardware has hwrngs, but their robustness leaves something to be
desired.  Additionally, Tor users tend to be a paranoid lot, and are
prone to avoid hwrngs that are opaque and unverifiable.  :-)

While mixing seeds from multiple sources doesn't academically solve the
entropy starvation problem, it does make it orders of magnitude more
difficult for an attacker to guess the inputs in order to predict the
output of Linux's prng.  This is most likely where a practical solution
lies.

Any embedded Tor router is going to need to address the above problem in
order to avoid weak ephemeral keying.  Personally, I pre-load my
firmware images with /var/lib/misc/random-seed.  It's the result of
pulling seeds from multiple x86 boxes with long uptimes and then xor'd
together.  *Then*, I turn the box on for the first time.  But that
doesn't scale for a product.

The second concern is a lot less critical.  arch/arm/ doesn't support
KASLR yet, and even if it did, you have the above-mentioned entropy
problem.

Last is updates.  A critical piece of any successful security product is
a secure, and hopefully automated update process.  I've not checked the
current status of OpenWRT, if they don't offer it, it would need to be
added.  Users rarely, if ever, update systems.  It's even worse for
printers, routers and other embedded devices.

> It further opens new possibilities for expanding the Tor-network and
> can provide a stable source of income for the Tor-project.

I certainly agree, especially if the default configuration includes "Is
your bandwidth capped?"  If not, it's configured and a low-prio relay.

I definitely think the project is worth pursuing.  But the quality of
randomness, especially at first boot, needs to be addressed before
releasing the first version.  Auto-update, ideally should also be in the
first version, or shortly after.  Before reaching critical mass.

Just some thoughts.

thx,

Jason.

[1] http://article.gmane.org/gmane.comp.encryption.general/26020/match=trng+related+review+rngd+dev+random
     Top of thread:
    http://article.gmane.org/gmane.comp.encryption.general/26012/match=trng+related+review+rngd+dev+random

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk