Copyright © 2010 jsd

Improving Security when Booting from Read-Only Media

*   Contents

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:

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:

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:
  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.

Copyright © 2010 jsd