[Etherboot-developers] RFC: Safe booting concept

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

Dear list,

after reading several posts about the upcoming
  ---)World Domination Of Etherboot(---
I had some thoughts about a safe booting concepts. As I just have some
minutes, I'd like to dig into it, but first I'd like some opinion
about this concept:

In a safe-boot environment, we must assume
 - boot rom can be read out (but not modified) by an attacker
   Why this? Because on my machines there is also a local dos. Users
     cannot open the machines and cannot disable bootrom (as the next
     user would notice), but can read it into a file.
   Consequences? We cannot store a *symmetric* key on the bootrom.
 - all network traffic can be overheard & modified by an attacker
   Why this? Because one lab is cabled BNC/10MBit, so anyone could
     attach a laptop
 - Files in /tftpboot on the server cannot be modified by an attacker

Assumption:
  dhcp: option 159 now reserved for "secure boot file digest signature",
  fixed length 32 bytes, example

  |  option option-159 code 159 = string;
  |  filename "/vmlinuz.ltsp";
  |  option option-159 73:f7:e2:03:e8:0f:c4:61:25:c3:da:28:da:4c:52:a7:18:be:70:67:8f:83:84:c9:f5:f3:85:96:52:44:43:e0;

So what do you think about the following procedure?

Boot ROM contains the server's public RSA key + corresponding software
On bootup, when etherboot gains control (which on many architectures
can be forced by the administrator, so that users cannot manipulate
without changing hardware), it gets a dhcp address+information block
as usual. This one need not be verified in my concept, it is just
trusted. Inside this packet, a filename is specified. If it's
localboot (harddisk, floppy, whatever), it proceeds. If it's a
network filename (so, "slam://10.3.4.1/slam-boot/image" would be, as
"/vmlinuz.ltsp"), it is retrieved while the md5 checksum is built over
it ( "This implementation is copyright 1997 by M. Gutschke" ). After
that, option-159 is decoded with the server's public key (which then
must have been burnt into the bootrom) and compared with the md5
digest. If it does not match, the etherboot machine refuses to boot.

This setup is designed so that without a ROM change other files could
be downloaded. A menu system would have not only to modify "filename",
but also to enter another value for option-150, but that is possible,
I did this (modifying an option string from a menu system) in a test
setup just some days ago. As the menu has been verified before, it
would be "safe", as any other loaded file would be checked again.

Can this setup be tricked? Is it "safe"? Any interest in something
like it?

Ready to code, waiting for comments.

Best regards,
  Anselm Martin Hoffmeister
  Stockholm Projekt Computer-Service
  <an...@ho...>