aboutsummaryrefslogtreecommitdiffstats
path: root/hostapd
diff options
context:
space:
mode:
authorJouni Malinen <j@w1.fi>2010-11-23 23:29:40 (GMT)
committerJouni Malinen <j@w1.fi>2010-11-23 23:29:40 (GMT)
commitbbb921daaacccfac0e5e7085143b83fe5bf49294 (patch)
treebc49f6cce1d4666cda5b35f1fb2e9cc55212a264 /hostapd
parente5851439e30a63e10ac98f3c32fc1c00448a22d9 (diff)
downloadhostap-bbb921daaacccfac0e5e7085143b83fe5bf49294.zip
hostap-bbb921daaacccfac0e5e7085143b83fe5bf49294.tar.gz
hostap-bbb921daaacccfac0e5e7085143b83fe5bf49294.tar.bz2
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.
Diffstat (limited to 'hostapd')
-rw-r--r--hostapd/Makefile10
-rw-r--r--hostapd/defconfig25
2 files changed, 35 insertions, 0 deletions
diff --git a/hostapd/Makefile b/hostapd/Makefile
index bb5e387..a99ebc0 100644
--- a/hostapd/Makefile
+++ b/hostapd/Makefile
@@ -646,6 +646,7 @@ endif
ifdef NEED_MD5
ifdef CONFIG_INTERNAL_MD5
OBJS += ../src/crypto/md5-internal.o
+HOBJS += ../src/crypto/md5-internal.o
endif
endif
@@ -686,6 +687,15 @@ OBJS += ../src/crypto/dh_group5.o
endif
endif
+ifdef CONFIG_NO_RANDOM_POOL
+CFLAGS += -DCONFIG_NO_RANDOM_POOL
+else
+OBJS += ../src/crypto/random.o
+HOBJS += ../src/crypto/random.o
+HOBJS += $(SHA1OBJS)
+HOBJS += ../src/crypto/md5.o
+endif
+
ifdef CONFIG_RADIUS_SERVER
CFLAGS += -DRADIUS_SERVER
OBJS += ../src/radius/radius_server.o
diff --git a/hostapd/defconfig b/hostapd/defconfig
index 61793c4..8a87646 100644
--- a/hostapd/defconfig
+++ b/hostapd/defconfig
@@ -179,3 +179,28 @@ CONFIG_IPV6=y
#LIBS += -lbfd -liberty -lz
#LIBS_p += -lbfd -liberty -lz
#LIBS_c += -lbfd -liberty -lz
+
+# hostapd depends on strong random number generation being available from the
+# operating system. os_get_random() function is used to fetch random data when
+# needed, e.g., for key generation. On Linux and BSD systems, this works by
+# reading /dev/urandom. It should be noted that the OS entropy pool needs to be
+# properly initialized before hostapd is started. This is important especially
+# on embedded devices that do not have a hardware random number generator and
+# may by default start up with minimal entropy available for random number
+# generation.
+#
+# As a safety net, hostapd is by default trying to internally collect
+# additional entropy for generating random data to mix in with the data
+# fetched from the OS. This by itself is not considered to be very strong, but
+# it may help in cases where the system pool is not initialized properly.
+# However, it is very strongly recommended that the system pool is initialized
+# with enough entropy either by using hardware assisted random number
+# generatior or by storing state over device reboots.
+#
+# 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.
+#CONFIG_NO_RANDOM_POOL=y