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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
