[OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon

Discussion:

[OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package

Olipro

2012-01-12 11:29:36 UTC

Haveged is an entropy gathering daemon which refills the kernel's entropy
pool by timing the nanoseconds a CPU takes to complete a loop. The existing
haveged only supports a few architectures - I have added support for any
given architecture by utilising the CLOCK_MONOTONIC_RAW introduced in
kernel 2.6.28 - no doubt this does incur a performance penalty since the
architecture specific code uses assembler. unfortunately reading r9 from
cp0 on mips requires the cpu to be in kernel or supervisor mode.

Unlike rng-tools, using haveged ensure the entropy pool is not simply
refilled from /dev/urandom - thus ensuring that evicted entropy is not
recycled into the secure pool.

however, I'm not entirely sure what dependencies I should be making this
rely on to ensure people on say... brcm2.4 don't get it, thus if someone
could take a look at it, I'd be most appreciative - the package itself
works just fine, I'm using it on my WNDR3800.

Florian Fainelli

2012-01-12 12:53:47 UTC

Permalink

Hello,

Post by Olipro
Haveged is an entropy gathering daemon which refills the kernel's entropy
pool by timing the nanoseconds a CPU takes to complete a loop. The existing
haveged only supports a few architectures - I have added support for any
given architecture by utilising the CLOCK_MONOTONIC_RAW introduced in
kernel 2.6.28 - no doubt this does incur a performance penalty since the
architecture specific code uses assembler. unfortunately reading r9 from
cp0 on mips requires the cpu to be in kernel or supervisor mode.
Unlike rng-tools, using haveged ensure the entropy pool is not simply
refilled from /dev/urandom - thus ensuring that evicted entropy is not
recycled into the secure pool.
however, I'm not entirely sure what dependencies I should be making this
rely on to ensure people on say... brcm2.4 don't get it, thus if someone
could take a look at it, I'd be most appreciative - the package itself
works just fine, I'm using it on my WNDR3800.

Though I am not against adding this daemon, rather, I think that we
should make some network drivers interrupts fill the kernel entropy pool
like it used to be, this should solve the entropy problem on most platforms.
--
Florian

Roman Yeryomin

2012-01-12 15:52:36 UTC

Permalink

Post by Florian Fainelli
Hello,

Though I am not against adding this daemon, rather, I think that we should
make some network drivers interrupts fill the kernel entropy pool like it
used to be, this should solve the entropy problem on most platforms.
--

If I remember correctly there were some security reasons of removing
it from the kernel.
Although I've done this on ramips platform and didn't face any issues
I think that, potentially, a better source or entropy would be radio
noise. Of cause if it's possible to get.

Regards,
Roman

Florian Fainelli

2012-01-12 16:02:05 UTC

Permalink

Post by Roman Yeryomin

Post by Florian Fainelli
Hello,

Though I am not against adding this daemon, rather, I think that we should
make some network drivers interrupts fill the kernel entropy pool like it
used to be, this should solve the entropy problem on most platforms.
--

If I remember correctly there were some security reasons of removing
it from the kernel.

Yes, and the reason why you get less interrupts at high rates is because
of NAPI which limits the number of interrupts and prefers polling the
network adapter for new packets, though I don't think it will be a
problem for the SOHO router case routing at most 100Mbits or 1Gbits of
trafic in the best case. This should still generate enough interrupts.

Post by Roman Yeryomin
Although I've done this on ramips platform and didn't face any issues
I think that, potentially, a better source or entropy would be radio
noise. Of cause if it's possible to get.

Indeed, using entropy from Wi-Fi cards would also be a good idea since
it's less predictable. As you say, using radio noise would be even better.
--
Florian

Roman Yeryomin

2012-01-12 16:29:26 UTC

Permalink

Indeed, using entropy from Wi-Fi cards would also be a good idea since it's
less predictable. As you say, using radio noise would be even better.
--

So, the question is if it's possible to get some noise signals/info
from the wireless chips. Maybe anyone have done this before?

Regards,
Roman

Olipro

2012-02-13 15:00:49 UTC

Permalink

Hi Florian et Mailing List,

The author of haveged has now updated the package to 1.4 - it is now
multithreaded and incorporates my generic code that uses the raw monotonic
clock. If you're still inclined to add this package to OpenWRT, let me know
and I'll update patchwork for the latest version in a package, otherwise,
I'd rather save the effort if the concensus is to go down this WiFi noise
route.

Roman Yeryomin

2012-02-13 19:56:39 UTC

Permalink

On 13 February 2012 17:00, Olipro

Post by Olipro
Hi Florian et Mailing List,
The author of haveged has now updated the package to 1.4 - it is now
multithreaded and incorporates my generic code that uses the raw monotonic
clock. If you're still inclined to add this package to OpenWRT, let me know
and I'll update patchwork for the latest version in a package, otherwise,
I'd rather save the effort if the concensus is to go down this WiFi noise
route.

I think you should do it. First of all because it's a
known-to-be-working way. Second wifi noise way is pretty unclear and
needs intensive testing on various hw. And, at last, it can serve as
something to compare with.

Regards,
Roman

Oliver

2012-02-14 08:56:22 UTC

Permalink

Post by Roman Yeryomin
I think you should do it. First of all because it's a
known-to-be-working way. Second wifi noise way is pretty unclear and
needs intensive testing on various hw. And, at last, it can serve as
something to compare with.
Regards,
Roman

Done.

Signed-off-by: Oliver Smith <***@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa>

g***@free.fr

2012-01-12 14:54:36 UTC

Permalink

----- Mail original -----

Envoyé: Jeudi 12 Janvier 2012 13:53:47
Objet: Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package
Hello,

I was one that try to advocate in 2008 for the non removal of IRQF_SAMPLE_RANDOM.
http://marc.info/?l=linux-kernel&m=121096875505040&w=2
This look to be a dead cause.
It's true there is some good technical reason why IRQF_SAMPLE_RANDOM may not be a good entropy source.
First issue is that with modern drivers, interrupt number decrease when traffic increase (I forgot the technical details but that could be found in the quoted thread).

HLFS had another solution than a user-space daemon (everything could help) but not for crypto purpose using frandom kernel module.
That create /dev/{e,f}random devices. In case of HLFS, /dev/erandom is plugged to glibc in place of /dev/urandom.

http://www.linuxfromscratch.org/hlfs/view/development/chapter08/kernel.html
http://www.linuxfromscratch.org/hlfs/view/development/chapter06/glibc.html
http://www.billauer.co.il/frandom.html

Testing user-space and module solution is still on my todo list.

Gilles

g***@free.fr

2012-01-12 17:07:21 UTC

Permalink

----- Mail original -----

Envoyé: Jeudi 12 Janvier 2012 17:29:26
Objet: Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package

Indeed, using entropy from Wi-Fi cards would also be a good idea since it's
less predictable. As you say, using radio noise would be even better.
--

So, the question is if it's possible to get some noise signals/info
from the wireless chips. Maybe anyone have done this before?
Regards,
Roman

I find only this old example
http://www.freewebs.com/pmutaf/iwrandom.html

Gilles

Jonathan Bither

2012-01-12 17:13:09 UTC

Permalink

That's a pretty neat example and idea behind it. Perhaps it would be
beneficial to apply the same concept to the mac80211 stack that once
loaded would expose /dev/iwrandom?

Jonathan,

Post by g***@free.fr
----- Mail original -----

Envoyé: Jeudi 12 Janvier 2012 17:29:26
Objet: Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package

Indeed, using entropy from Wi-Fi cards would also be a good idea since it's
less predictable. As you say, using radio noise would be even better.
--

So, the question is if it's possible to get some noise signals/info
from the wireless chips. Maybe anyone have done this before?
Regards,
Roman

I find only this old example
http://www.freewebs.com/pmutaf/iwrandom.html
Gilles
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

g***@free.fr

2012-01-12 17:43:29 UTC

Permalink

----- Mail original -----

Envoyé: Jeudi 12 Janvier 2012 16:52:36
Objet: Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package
If I remember correctly there were some security reasons of removing
it from the kernel.

There is 2 reasons:
First, network could be sniffed and one could use that knowledge to know what have been added to the entropy pool at which exact time. Very hard to do and much much harder when there is multiple networks as usually you are not able to sniff all networks at the same time.
Secondly, dev/random content is supposed to count only first class entropy for crypto purpose, so if you add content that is not of the first class quality, you lie on the size of available entropy.

I think the real reason is that mostly programmers are paid to make big server work in a secure way.
If a server has only one network card active and that card feed the entropy pool, that would be bad for security if able to sniff that network. So from an audit point of view, it is better to remove an uncertain entropy source.
Secondly, big server this day have hardware noise generator to feed the entropy pool.

Although I've done this on ramips platform and didn't face any issues
I think that, potentially, a better source or entropy would be radio
noise. Of cause if it's possible to get.

As network traffic from cable, radio noise could be sniffed, on the radio case even without physical access.
So that may not be better, maybe even worst.

Gilles

Florian Fainelli

2012-01-12 17:47:30 UTC

Permalink

Post by g***@free.fr
----- Mail original -----

First, network could be sniffed and one could use that knowledge to know what have been added to the entropy pool at which exact time. Very hard to do and much much harder when there is multiple networks as usually you are not able to sniff all networks at the same time.
Secondly, dev/random content is supposed to count only first class entropy for crypto purpose, so if you add content that is not of the first class quality, you lie on the size of available entropy.
I think the real reason is that mostly programmers are paid to make big server work in a secure way.
If a server has only one network card active and that card feed the entropy pool, that would be bad for security if able to sniff that network. So from an audit point of view, it is better to remove an uncertain entropy source.
Secondly, big server this day have hardware noise generator to feed the entropy pool.

Although I've done this on ramips platform and didn't face any issues
I think that, potentially, a better source or entropy would be radio
noise. Of cause if it's possible to get.

As network traffic from cable, radio noise could be sniffed, on the radio case even without physical access.
So that may not be better, maybe even worst.

Sure you can sniff noise, but you won't see the same noise as a sniffer
than as a receiver using it for entropy anyway due to the nature of the
physical medium.
--
Florian

Roman Yeryomin

2012-01-13 09:48:52 UTC

Permalink

Post by g***@free.fr

As network traffic from cable, radio noise could be sniffed, on the radio
case even without physical access.
So that may not be better, maybe even worst.

Sure you can sniff noise, but you won't see the same noise as a sniffer than
as a receiver using it for entropy anyway due to the nature of the physical
medium.
--

I agree with Florian, you'll most likely have completely different
noise on the sniffer 10 meters away from your attack target. It also
depends on radio circuit which will probably be different on the
sniffer. And even if you'll take the same device for sniffing it's
very difficult to have two completely identical radios. As far as I
know (from radio engineers I've talked to) every radio is unique (and
this is the reason why you need to calibrate every device).
The best noise source would probably be radial mse parameter which
will include radio noise and circuit noise. So, potentially, it's even
better than hardware random generators (which take only circuit
noise).
I didn't look into the wireless drivers yet but mse should be pretty
standard value and should be available in most socs.

Regards,
Roman

Steffen Hoffmann

2012-01-13 14:21:02 UTC

Permalink

Post by Roman Yeryomin
The best noise source would probably be radial mse parameter which
will include radio noise and circuit noise. So, potentially, it's even
better than hardware random generators (which take only circuit
noise).

Silently watching here for a long time now. But I can't resist any longer.

What you tell here is essentially a use case for every IT security
conscious person, that i.e. would not switch from wire to wlan devices
for good measure. Anyone could profit from a high output random number
generator. Even using the wlan nic for /dev/urandom exclusively would be
great.

You wonder why? I remember waiting for more than 6 hours to fill a
300+GB hard disc with random bytes when initializing a LUKS partition.
CPU was at max, any I/O towards the disc certainly not. If this is
really that good, and it seems like that, I don't know, why it hasn't
been done before. I would see this implemented rather sooner than later
and pushed upstream to be used by anyone on desktop and servers too.

Keep-up the good, ambitious work.

Steffen Hoffmann

Roman Yeryomin

2012-01-19 10:57:38 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Silently watching here for a long time now. But I can't resist any longer.
What you tell here is essentially a use case for every IT security
conscious person, that i.e. would not switch from wire to wlan devices
for good measure. Anyone could profit from a high output random number
generator. Even using the wlan nic for /dev/urandom exclusively would be
great.
You wonder why? I remember waiting for more than 6 hours to fill a
300+GB hard disc with random bytes when initializing a LUKS partition.
CPU was at max, any I/O towards the disc certainly not. If this is
really that good, and it seems like that, I don't know, why it hasn't
been done before. I would see this implemented rather sooner than later
and pushed upstream to be used by anyone on desktop and servers too.
Keep-up the good, ambitious work.

I took a quick glance at wireless drivers and few datasheets I've
found in the Internet.
As far as I understand the main problem here is lack of good
information from the chip. Noise level which is available (on probably
all wifi chips) seems to be 0.5 dbm precise at best, so it may change
very rarely.
Although, as noted, Pars Mutaf
(http://www.freewebs.com/pmutaf/iwrandom.html) already did this, it
may not be enough to be TRNG.
There are PHY error counters (as I understand usually they are
available) for OFDM and CCK modulation errors. But, again, they may
not change (as I understand it) if you are alone in the air.
I'm going to play with phy counters and test it in usual and wifi
silent environment and see how good is that.
BTW, seems that there are wifi cards which already give ready to use
random bits (see CONFIG_CARL9170_HWRNG). It would be interesting to
see how good is the distribution of random bits generated by those
cards.

Regards,
Roman