Commit Graph

6 Commits

Author SHA1 Message Date
Jouni Malinen
0f3d578efc Remove the GPL notification from files contributed by Jouni Malinen
Remove the GPL notification text from the files that were
initially contributed by myself.

Signed-hostap: Jouni Malinen <j@w1.fi>
2012-02-11 19:39:36 +02:00
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
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
Jouni Malinen
3642c4313a Annotate places depending on strong random numbers
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.

The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
2010-11-24 01:05:20 +02:00