Re[2]: [Etherboot-developers] RFC: Safe booting concept
Brought to you by:
marty_connor,
stefanhajnoczi
|
From: Anselm M. H. <an...@ho...> - 2003-04-26 14:50:07
|
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... |