Improving Security when Booting from Read-Only Media

*   Contents

• 1  Background and Rationale
• 2  Procedure
• 3  Miscellaneous Notes

1  Background and Rationale

There are many situations where you might want to boot a computer from read-only media such as “Live CD” or memory stick or whatever. You ought to be concerned about security, especially if the computer is connected to a network.

Most modern security algorithms rely on a source of random numbers. It is recommended that these come from a HRNG (hardware random number generator) ... but in this document we focus on the less-than-ideal case where you do not have confidence in the computer’s ability to generate adequate amounts of real entropy.

The solution given here is significantly better than the prior art, although we again emphasize that it is less than ideal, and again recommend using a good HRNG whenever possible.

Here’s the idea: Seed /dev/random with two contributions: (a) the time-of-day, and (b) a random-seed file that is unique to this boot image.

These to contributions together are far more powerful than either one separately. That is:

• Consider the case of (a) without (b). That is, suppose every Live CD out there initializes /dev/random the same way. The attackers will know this. Since they also know the time of day, or can narrow it down to a modest number of guesses, they can do a good job of predicting the output of /dev/random, which means that your so-called random numbers are not random at all.
• Consider the case of (b) without (a). That is, suppose we have a random-seed file that is unique to this CD, but we don’t have any time-dependent contributions to the initialization of /dev/random. Then the problem is that every time you reboot, /dev/random replays the same sequence of numbers. If you reboot enough times, the attackers will figure this out.

Note that the Linux kernel makes some effort to collect entropy from various sources. However, there is no guarantee as to how effective these efforts are going to be. For an unattended machine booting from read-only media, the effectiveness is particularly open to question.

So, the goal is to make each Live CD (or memory stick etc.) have its very own private random.seed file, and to make it initialize /dev/random using that file and the time of day.

I have created some software to help with this. The top-level program is a shell script, and it is supported by two Perl programs.

2  Procedure

If you want to make N disks:

• Download the main script ../fixup-live-cd and the supporting programs ../isofs and ../update-md5
• Download the ISO 9660 image of the "Live CD", according to the instructions at http://www.ubuntu.com/desktop/get-ubuntu/download
• Apply the fixup-live-cd script to the downloaded image, to produce a new “private” image. This takes about a minute on a moderately fast modern machine. Burn the private image to disk. This is the first disk.
• For each of the remaining N−1 disks, apply the fixup-live-cd script to the private image, updating it in place. This takes only a fraction of a second. Then burn the updated private image to disk. Repeate the update / burn cycle for each of the remaining disks.

For additional details, download the aforementioned programs and read their usage messages.

Note that if the Ubuntu folks made a modest change to their downloadable image, the process for the first disk would be two orders of magnitude quicker.

3  Miscellaneous Notes

1. As soon as the “Live” image boots up, hit any key on the console. (Space works nicely for this, since it is otherwise inert.) This will offer a lot of options that will become unavailable later:
   • F6 allows you to edit the kernel command-line for the Live system.
     • It may be useful to add systemd.log_level=debug
     • Add break=... to spawn a debug shell in the initramfs image at the chosen phase (top, modules, premount, mount, mountroot, bottom, init). Seehttps://wiki.debian.org/InitramfsDebug or "man initramfs-tools".

       Reat the init script at the top of the intramfs image for details on where the breaks occur.

     • From: /root/cdrom/boot/whatever To: /root/var/lib/systemd/random-seed and/or: /root/var/lib/urandom/random-seed

       Could stick some code in the local_bottom() function within the initrd//scripts/local file.

     • http://serverfault.com/questions/617398/is-there-a-way-to-see-the-execution-tree-of-systemd
     • cryptsetup.target evidently doesn’t require systemd-random-seed.service. Good thing to investigate.

       apt-file search /systemd-random-seed.service systemd: /lib/systemd/system/sysinit.target.wants/systemd-random-seed.service systemd: /lib/systemd/system/systemd-random-seed.service systemd: /usr/share/man/man8/systemd-random-seed.service.8.gz

2. The vestigial /var/lib/urandom is created because it is present (as an empty directory) in casper/filesystem.squashfs

   Also note that it is mentioned in /mnt/squash/var/lib/dpkg/info/initscripts.list

   Also it’s odd that the Live system ships init.d/urandom, since AFAICT it doesn’t get run ... and running it has no discernible effect.