summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/randomness_seeding.mdwn
diff options
context:
space:
mode:
authorbertagaz <bertagaz@ptitcanardnoir.org>2017-08-16 12:22:18 +0200
committerbertagaz <bertagaz@ptitcanardnoir.org>2017-08-16 12:22:18 +0200
commit570a10f8082adf62cf27bf892389762106b14b9e (patch)
treef7e0a1ae017ae32ca134ecfdb9cde653e24f42c2 /wiki/src/blueprint/randomness_seeding.mdwn
parentdc8312d3df4d80c642895a9ae77637cb9b5fcc5a (diff)
Refine a bit the randomness seeding blueprint.
Diffstat (limited to 'wiki/src/blueprint/randomness_seeding.mdwn')
-rw-r--r--wiki/src/blueprint/randomness_seeding.mdwn119
1 files changed, 61 insertions, 58 deletions
diff --git a/wiki/src/blueprint/randomness_seeding.mdwn b/wiki/src/blueprint/randomness_seeding.mdwn
index 28d4d87..0838f66 100644
--- a/wiki/src/blueprint/randomness_seeding.mdwn
+++ b/wiki/src/blueprint/randomness_seeding.mdwn
@@ -1,51 +1,51 @@
# /dev/random and /dev/urandom radomness seeding in Tails
/dev/random and /dev/urandom are special Linux devices that provide access from
-user land to the Linux kernel Pseudo Random Number Generator (PRNG). This
-generator is used for almost every security protocol, like TLS/SSL key
-generation, choosing TCP sequences, ASLR offsets, and GPG key generation [1]. In
-order for this seed to be cryptographically secure, a source with 'good'
-entropy must be used. The Linux kernel collects entropy from several sources,
-for example keyboard typing, mouse movement, among others.
-
-## Problem
-
-Because of the Tails nature of being amnesic, and run from a (USB) live device,
-care must be taken to ensure the system still gets enough entropy and boots with enough randomness. For example by providing a random seed through different means.
-
-Although these problem have been documented since a long time (see [7] and [8]),
-there's not much done to tackle the problem. We looked at notes and research from LiveCD OS's and supply them here for completements sake. Whonix has a [wiki
-page](https://www.whonix.org/wiki/Dev/Entropy) with some notes, and Qubes has tickets
-about this.
-
-The Qubes tickets can be found at footnotes [3],[4],[5] and [6] for more information.
+user land to the Linux kernel Cryptographically Secure Pseudo Random Number
+Generator (CSPRNG). This generator is used for almost every security protocol,
+like TLS/SSL key generation, choosing TCP sequences, ASLR offsets, and GPG key
+generation [1]. In order for this CSPRNG to be really cryptographically secure,
+it's recommended to seed it with a 'good' entropy source, even though The Linux
+kernel collects entropy from several sources, for example keyboard typing,
+mouse movement, among others.
+
+Because of the Tails nature of being amnesic, and run from different type of
+live devices (from DVDs to USB sticks), special care must be taken to ensure
+the system still gets enough entropy and boots with enough randomness. This is
+not easy in the Tails context, where the system is almost always booting the
+same way. Even the squashfs file is ordered to optimize boot time.
+
+Although these problem have been documented since a long time (see [7] and
+[8]), there's not much done to tackle the problem. We looked at notes and
+research from LiveCD OS's and supply them here for completements sake. Whonix
+has a [wiki page](https://www.whonix.org/wiki/Dev/Entropy) with some notes, and
+Qubes has tickets about this ([3],[4],[5] and [6]).
## Current situation
See the related [[design document|contribute/design/random]]
-Tails has stopped shipping /var/lib/urandom/random-seed, since it is a fixed known value
-for every Tails installation which means its entropy contribution is zero.
+Tails do not ship /var/lib/urandom/random-seed in the ISO, since it means
+shipping a fixed known value for every Tails installation which means its
+entropy contribution is zero, and breaks reproducibility of the ISO image.
-Without this random seed, systemd-random-seed load won't write anything to
-/dev/urandom (so we rely purely on the kernel and current system entropy to get
-/dev/urandom). This new behavior can't be much worse, and the fact it's the new
-debootstrap and systemd default behavior tends to be reassuring.
+Without this random seed, systemd-random-seed won't write anything to
+/dev/urandom, so we rely purely on the kernel CSPRNG and current system entropy
+to get /dev/urandom. It's commonly admitted to be quite good, but given the
+Live nature of Tails, and the fact that good cryptography is a must, we may
+want to add additional measures to ensure any Tails system has enough entropy.
-Tails also ships Haveged since a while, and rngd since 2.6. Note that in
-Stretch, Haveged will be started very early at boot time (after the apparmor
-profiles loading), before any userland application needs randomness. Still there
-are concerns about Haveged's reliability to provide cryptographically secure
-randomness.
+Tails ships Haveged and rngd since a while. Still there are concerns about
+Haveged's reliability to provide cryptographically secure randomness, and rngd
+is only really useful when random generator devices are used.
-So the situation may not be that bad, but given the Live nature of Tails,
-and the fact that good cryptography is a must, we may want to add additional
-measures to ensure any Tails system has enough entropy.
+Taking other measures to seed the Linux Kernel CSPRNG with good material is
+something worst spending efforts on.
## Use cases
-We have several use cases, which may require different solutions, depending on
-how the Tails OS is installed.
+Tails is used in different ways with different live devices. That requires
+different solutions, depending on how and what the Tails OS is installed.
### DVD
@@ -62,7 +62,7 @@ So we may eventually just document somewhere to users that they MUST NOT use
this type of installation if they want to rely on good cryptograpy for their
communications and key generation, or that they should wait after having
interacting a long (but hard to define) time with the system so that it had time
-to collect entropy, and does not rely on Haveged + rngd only.
+to collect entropy, and does not rely on the CSPRNG, Haveged and rngd only.
We could also add some kind of notification to users when entropy gets too low,
or just saying them that the way they use Tails is not compatible with strong
@@ -81,16 +81,16 @@ seed, and adding one is very difficult if not impossible (except with the
Windows installation where we may ask upstream to implement that in the
Universal USB Installer, but well...).
-That's also not really the way we push to users to use Tails, so as with DVD
+That's also not really the way we encourge users to use Tails, so as with DVD
there's maybe no point to fix the situation here, and the same workaround could
-may apply.
+be applied (document it).
### Final USB
That's supposed to be the standard way to use Tails.
-Note that in this case, there are two situations: using this installation with
-persistence enabled, and without.
+Note that in this case, there are two situations: booting this installation
+with persistence enabled, and without.
It is worth noting too that the first time this Tails installation is booted,
most of the time the first step is to configure persistence, which means
@@ -99,7 +99,7 @@ probably very little entropy, so this may weaken the LUKS volume encryption.
### Virtual Machines
-That's a way to use Tails, and one of the worste cases: it is of public
+That's a way to use Tails, and one of the worst cases: it is of public
knowledge that entropy in VMs is very poor. It's not really clear how the
entropy gathering daemons we have would help, but there are mechanisms now in
libvirt to pass randomness from the host using the Virtio RNG feature (even if
@@ -109,37 +109,37 @@ it may not be enough by itself).
### Persist entropy pool seeds [[!tails_ticket 7675]]
-We hope to improve this situation for users who enable the persistence storage
-option using some randomness from the previous session to help bootstrap with
-some "well" generated randomness.
+We hope to improve this situation for users who enable the persistent storage
+option by storing a seed from the previous session to help bootstrap
+with some "well" generated randomness.
Storing it in the persistent partition will be implemented using a default
-hidden persistence setting. But it does not solve the problem for the first time
-Tails is booted, which is likely when the encrypted persistence partition is
-created.
+(hidden to the user) persistence setting. But it does not solve the problem for
+the first time Tails is booted, which is likely when the encrypted persistence
+partition is created.
### Use the Tails installer to create a better seed [[!tails_ticket 11897]]
Tails installer can be used on Debian and Ubuntu, and is the tool people
running OSX or Windows are told to use to install their final Tails
-USB stick with.
+USB stick with, by using an intermediary Tails to create the final USB.
Tails installer could store a seed in the FAT filesystem of the system
partition. That would workaround this first boot problem not handled by the
persistence option.
We can't sadly update this seed while running Tails, as mounting RW the system
-FAT partition at that moment does not work. So we'll have to update it at the
-system shutdown. This will mean remount this partition, write the new random
-seed, then unmount it and start the shutdown of the system. Obviously we can
-do this only in normal shutdown process, and will have to avoid it in emergency
-shutdown mode.
+FAT partition during a Tails session does not work. So the question whether updating it
+or not is open.
-Using this in addition to the persistent seed mentionned above may thus be the
-way to go.
+If we want to do so, we'll have to update it at the system shutdown. This will
+mean remount this partition, write the new random seed, then unmount it and
+start the shutdown of the system. Obviously we can do this only in normal
+shutdown process, and will have to avoid it in emergency shutdown mode.
-This solution is partial since it only works for Tails Installer+USB stick, and
-we don't know if and how we will use the Tails installer in the future (see [[!tails_ticket 11679]]).
+We may alternatively not update it, and use it only when the persistence is not
+enabled. That would still be a unique source of entropy per Tails installation,
+so that would be a better situation that the current one.
One drawback: this would break the ability to verify this system partition with
a simple shasum operation.
@@ -161,7 +161,8 @@ already](https://volumelabs.net/best-random-data-software/)
Possible candidates:
* [entropy gathering daemon](http://egd.sourceforge.net/): not packaged into Debian.
-* [twuewand](http://www.finnie.org/software/twuewand/): used by Finnix LiveCD, packaged into Ubuntu only.
+* [twuewand](http://www.finnie.org/software/twuewand/): used by Finnix LiveCD
+ (so made for this kind of environment), packaged into Ubuntu only.
* [timer entropy daemon](https://www.vanheusden.com/te/): not packaged into Debian
* randomsound: probably a bad idea in the Tails context as we're discussing a
Greeter option to deactivate the microphone.
@@ -185,7 +186,9 @@ on average how much time that blocking would last. [Sycamoreone] [[!tails_ticket
An idea that has been mentioned several time is to have a service that
check if the available entropy is high enough, and notify the user if
-it's not the case.
+it's not the case. One downside, is that observing the entropy pool costs
+randomness, so this may have to be implemented with care or is worth
+discussing/researching the costs/benefits.
## Related tickets