Commit graph

6 commits

Author SHA1 Message Date
Jouni Malinen
38e24575c1 random: Add support for maintaining internal entropy store over restarts
This can be used to avoid rejection of first two 4-way handshakes every
time hostapd (or wpa_supplicant in AP/IBSS mode) is restarted. A new
command line parameter, -e, can now be used to specify an entropy file
that will be used to maintain the needed state.
2011-05-31 20:07:11 +03:00
Jouni Malinen
d47fa330b8 random: Read /dev/random in the background with eloop read socket
This makes it more likely to be able to fetch the 20 octet seed from
/dev/random in cases where other programs may also be competing for
this.
2011-03-22 23:15:00 +02:00
Jouni Malinen
b993e77b5b Removed unused variable from non-Linux builds 2010-12-14 17:10:39 +02:00
Jouni Malinen
805253d820 random: Fix a compiler warning about unused variable
In CONFIG_NO_STDOUT_DEBUG=y case, the error variable was not used.
2010-11-25 23:32:17 +02:00
Jouni Malinen
08704cd885 hostapd: Verify availability of random data when using WPA/WPA2
On Linux, verify that the kernel entropy pool is capable of providing
strong random data before allowing WPA/WPA2 connection to be
established. If 20 bytes of data cannot be read from /dev/random,
force first two 4-way handshakes to fail while collecting entropy
into the internal pool in hostapd. After that, give up on /dev/random
and allow the AP to function based on the combination of /dev/urandom
and whatever data has been collected into the internal entropy pool.
2010-11-24 13:08:03 +02:00
Jouni Malinen
bbb921daaa Maintain internal entropy pool for augmenting random number generation
By default, make hostapd and wpa_supplicant maintain an internal
entropy pool that is fed with following information:

hostapd:
- Probe Request frames (timing, RSSI)
- Association events (timing)
- SNonce from Supplicants

wpa_supplicant:
- Scan results (timing, signal/noise)
- Association events (timing)

The internal pool is used to augment the random numbers generated
with the OS mechanism (os_get_random()). While the internal
implementation is not expected to be very strong due to limited
amount of generic (non-platform specific) information to feed the
pool, this may strengthen key derivation on some devices that are
not configured to provide strong random numbers through
os_get_random() (e.g., /dev/urandom on Linux/BSD).

This new mechanism is not supposed to replace proper OS provided
random number generation mechanism. The OS mechanism needs to be
initialized properly (e.g., hw random number generator,
maintaining entropy pool over reboots, etc.) for any of the
security assumptions to hold.

If the os_get_random() is known to provide strong ramdom data (e.g., on
Linux/BSD, the board in question is known to have reliable source of
random data from /dev/urandom), the internal hostapd random pool can be
disabled. This will save some in binary size and CPU use. However, this
should only be considered for builds that are known to be used on
devices that meet the requirements described above. The internal pool
is disabled by adding CONFIG_NO_RANDOM_POOL=y to the .config file.
2010-11-24 01:29:40 +02:00