Project

General

Profile

Feature #11897

Create random seed at installation time with Tails Installer

Added by bertagaz over 1 year ago. Updated 3 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Start date:
11/04/2016
Due date:
% Done:

0%

QA Check:
Info Needed
Feature Branch:
feature/11897-improve-random-seed-file
Type of work:
Code
Starter:
No
Affected tool:
Installer

Description

Given I just installed Tails on a USB stick
When I boot it for the first time
Then I want to have good entropy to create the persistent storage
Given I boot Tails from a USB stick
When I do not activate my persistent volume in the Tails Greeter
Then I still want to have good enough entropy from a random seed

For that, it is necessary to have the Tails Installer create a random seed in the system FAT partition at installation time.


Related issues

Related to Tails - Feature #7642: Investigate whether we should resume shipping a static random seed In Progress 09/02/2016
Related to Tails - Feature #7675: Persist entropy pool seeds Confirmed 11/04/2016

History

#1 Updated by bertagaz over 1 year ago

At the November 4th meeting, we decided that this was a ticket we could start to work on.

We also decided to ask to tickets' assignee to write down a small presentation of the goal of their ticket, to be included in the blueprint that we'll show publicly. So it needs to be clear the ticket is about, what it will implement and why. There's already bits written in the blueprint dedicated paragraph, but it probably needs to be clarified for external readers. Please check and enhance it!

#2 Updated by kurono over 1 year ago

Use the Tails installer to create a better seed #11897

When Tails is installed the first time, the most common used method is downloading the Tails ISO image, verifying it is legitimate and then copying its content to create a running system. That means that every single user has exactly the same copy of Tails. This is good for verification, but also means that every user has the same initial random seed for CSPRNG operations, used to initialize the some of the most important cryptography functions such as TLS and disk encryption (Persistence), such that they may become predictable.
To solve this problem we plan to use the Tails installer, to initialize the random seed file on every new Tails. This should be a post installation mechanism, after verifying the ISO/disk image hash/signature. We plan to use the strongest random source available in the system where Tails Installer is running from, by Python's os.urandom [1].

[1]https://docs.python.org/2/library/os.html#os.urandom

#3 Updated by kurono over 1 year ago

  • Status changed from Confirmed to In Progress

#4 Updated by u 11 months ago

  • Subject changed from Create ramdom seed at installation time with Tails Installer to Create random seed at installation time with Tails Installer

#5 Updated by BitingBird 9 months ago

  • Related to Feature #7642: Investigate whether we should resume shipping a static random seed added

#6 Updated by BitingBird 9 months ago

  • Target version changed from 2017 to SponsorT_2016_Internal

#7 Updated by BitingBird 9 months ago

  • Target version changed from SponsorT_2016_Internal to 2017

#8 Updated by kurono 8 months ago

  • Feature Branch set to feature/11897-improve-random-seed-file

#9 Updated by kurono 8 months ago

  • Assignee deleted (kurono)
  • QA Check set to Info Needed
  • Starter set to No

I have implemented a first draft solution for this ticket.
I have modified tails-installer as shown in the feature branch:

and Tails (including the blueprint) as shown in:

please review the updated blueprint for the detailed changes.
One question I have is if the changes to Tails itself should be in another ticket, or even in the "Persist entropy pool seeds" one #7675.

#10 Updated by intrigeri 8 months ago

  • Assignee set to bertagaz

(as per roadmap)

#11 Updated by kurono 5 months ago

#12 Updated by u 4 months ago

  • Target version changed from 2017 to 2018

2017 is over.

#13 Updated by intrigeri 4 months ago

FYI this implementation option will stop working if/once we ship Tails as a bootable USB disk image and skip the Tails Installer part of the installation process (#11679, https://tails.boum.org/blueprint/usb_install_and_upgrade/usb_bootable_disk_image/).

#14 Updated by segfault 3 months ago

  • Assignee changed from bertagaz to kurono

As discussed with kurono at the 34c3, I take over reviewing this.

I looked at your solution and I like it. Copying the seed in initramfs seems like a good solution to get the seed ready for use as soon as possible during boot. And using the systemd random seed also seems like a nice solution. I have two questions/remarks:

1. Did you verify that systemd doesn't read the random seed before the init-bottom stage? IIRC, at least parts of systemd are already executed in initramfs, so it's possible that the seed is not actually used during first boot.

2. I think it might be even better if, instead of storing the seed on the filesystem, we would store it in an unused sector on the device. This way we don't have to remount the filesystem in order to update the seed, and verification of the filesystem will be easier. This would also allow us to copy the seed during an earlier initramfs stage, because the filesystem doesn't have to be mounted yet (which might be necessary in case that systemd already read the seed before the init-bottom stage).

The Tails Installer creates a GPT, which means that the first available sector is sector 2048. The MBR and GPT only use sectors 1 to 33 [1], so we have a lot of unused 512-Byte sectors available for this.

[1] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_entries_(LBA_2-33)

Regarding the code review: Both your patches to the Tails Installer and the initramfs scripts look good to me. (The Tails branch was a bit hard to review, because you merged both devel and master into it. I therefore reviewed d6d504a049006b9839ffcf5e8b64c652d265226d against devel.)

Regarding the blueprint update:
You state that it remains an open question whether this solves or complements the persist entropy pool seeds solution. IIUC, this solution persists the random seed of systemd to the next session, so how does this remain an open question?

The rest of the blueprint diff looks good to me.

#15 Updated by segfault 3 months ago

intrigeri wrote:

FYI this implementation option will stop working if/once we ship Tails as a bootable USB disk image and skip the Tails Installer part of the installation process (#11679, https://tails.boum.org/blueprint/usb_install_and_upgrade/usb_bootable_disk_image/).

True, with #15292 we would sadly lose the increased entropy during first boot. But we could still use the same solution to persist the random seed between subsequent boots.

#16 Updated by segfault 3 months ago

1. Did you verify that systemd doesn't read the random seed before the init-bottom stage? IIRC, at least parts of systemd are already executed in initramfs, so it's possible that the seed is not actually used during first boot.

I looked into this now. systemd-random-seed.service is not part of the initramfs setup we currently use in Tails, so running the script in init-bottom is fine.

#17 Updated by segfault 3 months ago

After reading systemd/random-seed.c and this comment in linux/random.c, I think we should also update the random seed in the bootup script, to make sure that we always use a different random seed (even if our shutdown script doesn't get executed, because the system crashed). But then we can't use systemd-random-seed.service, because we will need to update the random pool directly, to be able to read random bytes from it immediately. Instead, we could simply use the sample script from the linux/random.c comment:


 *    echo "Initializing random number generator..." 
 *    random_seed=/var/run/random-seed
 *    # Carry a random seed from start-up to start-up
 *    # Load and then save the whole entropy pool
 *    if [ -f $random_seed ]; then
 *        cat $random_seed >/dev/urandom
 *    else
 *        touch $random_seed
 *    fi
 *    chmod 600 $random_seed
 *    dd if=/dev/urandom of=$random_seed count=1 bs=512

Also available in: Atom PDF