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

[Anselm M. H. <an...@ho...>]

Hello Ken,

Saturday, April 26, 2003, 4:25:04 PM, you wrote

- the first answer. Had been waiting in front of my monitor :-)

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

OK. That's what I though about when finishing the mail (I wrote some
minutes on it, though along and forgot to remove that). Of course,
exchanging files can only break booting, but not safety. Stopping the
ability of people to interrupt booting is no aim of SafeBoot - that
could even be managed by pulling the network cable. So it doesn't
really touch us here, you're right.

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

Noticed.

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

Problem of this is that the data has to be examined not only in
checksum generation process (which is easy, with MG's md5.c from
etherboot 5.0), but also more intense. I'll have a look into ELF
format later.
Could just prepending a 128-byte-block to any image (yet on harddisk)
be accepted? This would break compatibility to non-SafeBoot-clients,
but perhaps this would even be reasonable...

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

That was aimed at anyway. I was not yet so far to specify if PGP or
GPG or even openssl-based stuff, but YES, I want this. Good point
anyway, I could have said so right from the beginning.

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

OK, no problem. I had planned to have an (#ifdef'ed) call to
safeboot_verify(...) after tftp download finishes. In case the cerify
fails, it's at the coder's option (well, anyone of us could change it
as he wants) to have a prompt or just a "cryptography exception fault
[blue screen] - system has been halted" message.

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

I'm not too sure (yet) how to specify something to be put in an
"unused" portion of ROM, but I will have a look at it.
Having a (lateron #ifdef'ed) call to safeboot_loadpublickey() would be
what you want, right? Perhaps even something like keyboard-interactive
as a fallback-method - I think I will initially only need /rom and
/keyboard support.

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

I don't understand your point. At any time, any client could boot the
image if it's not encrypted. If you don't want that client to boot the
image, just specify another dhcp filename... *ouch*, I see, as I wrote
DHCP shall not be secured. BUT: This could be solved by embedding an
ELF section with allowed MAC addresses (or MAC-prefix/bitmask stuff).
Of course that's only reasonable after SafeBoot is up, but then it
should be kind of kindergarten game to have it. I think that's one of
the ideas I do not plan to implement at the beginning. Perhaps someone
else will later, if there's need for it.

One last thing: Is there anything to notice with using digital
signature stuff? That's *not* cryptography, but sourceforge's hosted
in US and I don't want to be hanged for doing some forbidden crypto
stuff transfer. AFAIK, Germany's more liberal :-\

Thanks for your comments, any more welcome.
I'll let y'all know where I get to.

Best regards,
 Anselm                            mailto:an...@ho...