added section RNGs which was written by Ralf Schlatterbeck.
authorAaron Kaplan <aaron@lo-res.org>
Thu, 28 Nov 2013 14:23:46 +0000 (15:23 +0100)
committerAaron Kaplan <aaron@lo-res.org>
Thu, 28 Nov 2013 14:23:46 +0000 (15:23 +0100)
Pls. review

src/RNGs.tex
src/applied-crypto-hardening.tex

index 8e19e00..6f217ea 100644 (file)
@@ -1,4 +1,105 @@
 \section{Random Number Generators}
 \label{section:RNGs}
 
-\todo{still write this section}
+% This section was authored by Ralf Schlatterbeck (Ralf Schlatterbeck <rsc@runtux.com>)
+
+A good source of random numbers is essential for many crypto
+operations. The key feature of a good random number generator is the
+non-predictability of the generated numbers. This means that hardware
+support for generating entropy is essential.
+
+\todo{Other architectures, BSD, Windows?}
+
+Hardware random number generators in operating systems or standalone
+components collect entropy from various random events mostly by using
+the (low bit of the) time an event occurs as a entropy source. The
+entropy is merged into an entropy pool and in some implementations there
+is some bookkeeping about the number of random bits available.
+
+\subsection{When random number generators fail}
+
+Random number generators can fail -- returning predictable non-random
+numbers -- if not enough entropy is available when random numbers should
+be generated.
+
+This typically occurs for embedded devices and virtual machines.
+Embedded devices lack some entropy sources other devices have, e.g.:
+
+\begin{itemize}
+\item No persistent clock, so boot-time is not contributing to the
+    initial RNG state
+\item No hard-disk: No entropy from hard-disk timing, no way to store
+    entropy between reboots
+\end{itemize}
+
+Virtual machines emulate some hardware components so that the
+generated entropy is over-estimated. The most critical component that
+has been shown to return wrong results in an emulated environment is the
+timing
+source\footnote{\url{http://jakob.engbloms.se/archives/1374},\url{https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2011-02}}.
+
+Typically the most vulnerable time where low-entropy situations occur is
+shortly after a reboot. Unfortunately many operating system installers
+create cryptographic keys shortly after a
+reboot\footnote{\url{https://factorable.net/weakkeys12.extended.pdf}}.
+
+Another problem is that OpenSSL seeds its internal random generator only
+seldomly from the hardware random number generator of the operating
+system. This can lead to situations where a daemon that is started at a
+time when entropy is low keeps this low-entropy situation for hours
+leading to predictable session
+keys\footnote{\url{https://factorable.net/weakkeys12.extended.pdf}}.
+
+\subsection{Linux}
+
+On Linux there are two devices that return random bytes when read, the
+\verb+/dev/random+ can block until sufficient entropy has been collected
+while \verb+/dev/urandom+ will not block and return whatever (possibly
+insufficient) entropy has been collected so far.
+
+Unfortunately most crypto implementations are using \verb+/dev/urandom+
+and can produce predictable random numbers if not enough entropy has
+been
+collected\footnote{\url{https://factorable.net/weakkeys12.extended.pdf}}.
+
+Linux supports the injection of additional entropy into the entropy pool
+via the device \verb+/dev/random+. On the one hand this is used for
+keeping entropy across reboots by storing output of /dev/random into a
+file before shutdown and re-injecting the contents during the boot
+process. On the other hand this can be used for running a secondary
+entropy collector to inject entropy into the kernel entropy pool.
+
+\subsection{Recommendations}
+
+To avoid situations where a newly deployed server hasn't enough
+entropy it is recommended to generate keys (e.g. for SSL or SSH) on
+a system with enough entropy available and transfer the generated keys
+to the server.  This is especially advisable for small embedded devices
+or virtual machines.
+
+For embedded devices and virtual machines deploying additional userspace
+software that generates entropy and feeds this to kernel entropy pool
+(e.g. by writing to \verb+/dev/random+ on Linux) is recommended. Note
+that only a process run as root can update the entropy counters in the
+kernel, each non-root user-process can feed entropy to the pool but
+cannot update the
+counters\footnote{\url{https://en.wikipedia.org/wiki/dev/random}}.
+
+For Linux the \verb+haveged+
+implementation\footnote{\url{http://www.issihosts.com/haveged/}} based on the
+HAVEGE\footnote\url{http://www.irisa.fr/caps/projects/hipsor/scripts/down.php?id=13781296\&ext=.pdf}
+strong random number generator currently looks like the best choice. It
+can feed its generated entropy into the kernel entropy pool and recently
+has grown a mechanism to monitor the quality of generated random
+numbers\footnote{\url{http://www.issihosts.com/haveged/ais31.html}}. The
+memory footprint may be too high for small embedded devices, though.
+
+For systems where -- during the lifetime of the keys -- it is expected
+that low-entropy situations occur, RSA keys should be preferred over DSA
+keys: For DSA, if there is ever insufficient entropy at the time keys
+are used for signing this may lead to repeated ephemeral keys. An
+attacker who can guess an ephemeral private key used in such a signature
+can compromise the DSA secret key.
+For RSA this can lead to discovery of encrypted plaintext or forged
+signatures but not to the compromise of the secret
+key\footnote{\url{https://factorable.net/weakkeys12.extended.pdf}}.
index d3a4043..b56f18a 100644 (file)
@@ -166,7 +166,7 @@ morekeywords={__global__, __device__},  %
 
                                        \author{Wolfgang Breyha, David Durvaux, Tobias Dussa, L. Aaron
                                        Kaplan, Christian Mock, Manuel Koschuch, Adi
-                               Kriegisch, Ramin Sabet, Aaron Zauner, Pepi Zawodsky}
+                               Kriegisch, Ramin Sabet, Ralf Schlatterbeck, Aaron Zauner, Pepi Zawodsky}
 %\institute{
 %FH Campus Wien
 %\and
@@ -181,7 +181,7 @@ morekeywords={__global__, __device__},  %
 \setlength{\parindent}{0cm}
 
 \postauthor{\footnotesize \usefont{OT1}{phv}{m}{sl} \color{Black} 
-\\ \vskip 0.5em  (University of Vienna, CERT.be, KIT-CERT, CERT.at, coretec.at, FH Campus Wien, VRVis, A-Trust, azet.org, maclemon.at)
+\\ \vskip 0.5em  (University of Vienna, CERT.be, KIT-CERT, CERT.at, coretec.at, FH Campus Wien, VRVis, A-Trust, Runtux.com, azet.org, maclemon.at)
                                        \par\end{flushleft}\HorRule}
 
 \date{\today}