[tor-talk] Tor relay on small and cheap devices

[Mike Perry]

Thus spake Mirko Vogt (mirko at openwrt.org):

> On 01/18/2013 01:46 PM, Okhin wrote:
> > However, given the relatively limited capability of those devices, 4il wondering if they can have enough entropy to run Tor safely, and if it won't endanger the network.
> > So,before going further on the step of propagating those Tor small boxes, I need advices about this entropy. Is it an issue? Is there a way to work around it (generating keys and certificates on a different computer maybe? but then, how?)
> 
> Yes, there is definitely an issue with entropy which should be kept in
> mind. Lot's of embedded devices / SoCs do not have enough entropy
> sources (or software/drivers which could at least make the most out of
> what's there) to ensure cryptographically secure keys.
> 
> You might be surprised how often dropbear (an lightweight SSH server -
> used by e.g. OpenWrt) generates the _exact very same_ SSH host keys
> during the first boot on some devices. I ran into this issue several
> times when I had to flash bunches of devices.
> 
> And that wasn't even the AR7240. The AR7240 - in this manner - is the
> worst SoC I've ever seen. They cut it down to its basics, dropping every
> kind of source where entropy could be gathered from.
> Take a look at /proc/sys/kernel/random/entropy_avail right after boot to
> get an idea (and it might be actually higher than it would have been
> without you looking at it :)). It might be even 0(!) right after boot[2].
> 
> There's also this haveged[1] using the havege algorithm. However to me,
> as a non-mathematician, this sounds a bit like "we make a lot [of
> entropy] out of little". Maybe somebody could shed some light on this..

Disclaimer: I haven't read either the source or the research paper
behind haveged.

However, based on
http://www.irisa.fr/caps/projects/hipsor/misc.php#exectime, it sounds
like the underlying assumption is that *any* externally driven interrupt
that happens on your system will alter the internal state of the CPU and
caches such that a measurement codepath will actually end up taking a
variable number of clock cycles, which they then use as their source of
entropy.

If they're right (critically: their assumption also applies as well to
MIPS or ARM CPUs as it does to x86, SPARC, and DEC CPUs. Their docs
don't mention interrupt uncertainty stats for ARM or MIPS), then
anything that causes an external interrupt on your machine should
effectively provide entropy to haveged.

But, even with this, it would seem that if you're booting your SoC
without any enabled devices from readonly boot media, I would still
expect there is a high likelihood that the internal CPU state will still
be identical through the boot process, unless you have thermal sensors
or a battery monitor or something.

On the other hand, if their assumption holds equally well for these
CPUs, I would also guess that the interrupts even from passively
scanning WiFi should provide enough entropy even without driver support,
though. From the table in that that url, it looks like the least amount
of entropy they could extract per interrupt was 8Kbit (Itanium I)?

Certainly is an interesting idea.

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20130120/5e7b9df5/attachment.pgp>