Re: [Etherboot-developers] RFC: Safe booting concept

[<ke...@us...>]

Sounds reasonable for a first cut. Some comments.

> - Files in /tftpboot on the server cannot be modified by an attacker

You don't need to assume this. You only need to assume that it's
infeasable for the attacker to modify it and yet pass the check.

What you call server keys I would call publisher key. Multiple servers,
sites sharing images etc.

Rather than sending the signed hash in the DHCP reply, incorporate it in
the image. That is, all files are signed, including menus. Eric has
already used ELF note sections to hold a checksum.  You can define
another type to hold a signed hash. Modifying dhcpd.conf is a hassle,
you have to restart the server afterwards. One less service to worry
about. Also no limit on hash length.

It would be good if you could use existing GPG programs to manage the
publisher keys, there are already facilities to protect the private keys
with a passphrase. When building the image with mkelf-linux, the key
would be unlocked to hash and sign the image in one go.

There may need to be a way to override the requirement for signed images
from the client for some purposes, e.g. testing. An option that says ok,
I will accept the risk of loading and running an unsigned image, because
I'm servicing the machine.

It would be preferable if the public key were not put in the body of the
Ethernet code, but rather written into an unused part of the ROM. This
allows the key in the ROM image to be changed without a recompile. Also
define a layer of access routines so that other technolgies can be used
later to provide the key, e.g. smart card, USB dongle, etc.

The authentication the other way might be worth thinking about, how to
make sure that the appropriate clients are booting the image (not
reading, you can't stop clients from TFTPing the image). Perhaps a
client key (which might be a group key to reduce the number of distinct
keys) might be used to verify a different signed hash in the image. Not
sure if this is useful.