Thread: Re: Re[2]: [Etherboot-developers] RFC: Safe booting concept
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: <ke...@us...> - 2003-04-26 15:06:45
|
>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. Eric already has code in 5.1 that will call the checksum routine on data blocks as they are loaded. You only need to use those hooks. >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. You should only need to modify the build rules that take a .zimg file to a .zrom file. Maybe makerom can be modified to do the job. That way you can change the key without having to recompile the source. You may need to be able to read the ROM at the mapped address, not sure if this is possible on all NICs. >> 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. The motivation is weaker, you want to prevent the wrong clients from running an image, as opposed to preventing the wrong server from providing an image. That is, you indicate by keying the image to the clients whether it's legal for those clients to run it. You could simply not provide the wrong filename to the clients I suppose. I don't think it's something important to have. |
|
From: <ke...@us...> - 2003-04-26 15:20:23
|
>Problem is that SafeBoot also could make sense when etherboot is >loaded from harddisk (floppy even, in some circumstances). >I think when I'm so far, I will find a solution for that. Which is why you want a conceptual layer in between to separate out how the key is fetched, it may not be with the image, e.g. it may be in a smart card. But that can come later. |
|
From: <ebi...@ln...> - 2003-04-26 19:28:45
|
ke...@us... (Ken Yap) writes: > >Problem is that SafeBoot also could make sense when etherboot is > >loaded from harddisk (floppy even, in some circumstances). > >I think when I'm so far, I will find a solution for that. > > Which is why you want a conceptual layer in between to separate out how > the key is fetched, it may not be with the image, e.g. it may be in a > smart card. But that can come later. Though if it is a public key it is safe to store it with etherboot, which is a reasonable assertion. Eric |
|
From: Anselm M. H. <an...@ho...> - 2003-04-28 00:01:17
|
Hello Ken, Saturday, April 26, 2003, 5:20:16 PM, you wrote: > Which is why you want a conceptual layer in between to separate out how > the key is fetched, it may not be with the image, e.g. it may be in a > smart card. But that can come later. Just some status report: I added one Config option (not in CVS, local only) called SAFEBOOTMODE which currently can only be set to "1" (which means key is prepended to image). Assuming you have image.nbi and want it transferred to new "SafeBoot" format (hey, perhaps later someone implements elf block or nbi part=key support... for now, it's easier this way), go like this: If you don't have a 512bit key yet: openssl genrsa -out rsa.key 512 chmod 400 rsa.key temp1.txt Create the checksum: dd if=/dev/zero of=md5sum.bin bs=32 count=1 md5sum < image.nbi | sed s/.$// > mdsum.bin Encrypt the md5 sum with the private key: openssl rsautl -in md5sum.bin -out mdsum.sig -inkey rsa.key -sign -raw Prepend block to image: dd if=/dev/zero of=temp bs=32 count=15 cat md5sum.sig temp image.nbi > image.snbi rm temp md5sum.bin md5sum.sig MD5 digesting yet works perfect and I hope I'm more than half way through this ugly public key stuff :-) I'd like to know which RAM regions I can use safely during etherboot runs. I cannot use -DRELOCATE at the moment as this crashes my virtual machine with the lance driver, but one day it probably should work. Can I just get myself e.g. 0x30000-0x307ff for buffer purposes? Best regards, Anselm Martin Hoffmeister Stockholm Projekt Computer-Service <an...@ho...> -- Merke: Nicht das OS macht dich zu einem interessanteren Gespraechs- partner, sondern das, was du darueber weisst. Und die Toleranz macht dich dann noch zu einem liebenswerten Gespraechspartner. (Buelent Caliskan in de.org.ccc) |
|
From: <ke...@us...> - 2003-04-26 23:28:41
|
>> Which is why you want a conceptual layer in between to separate out how >> the key is fetched, it may not be with the image, e.g. it may be in a >> smart card. But that can come later. > >Though if it is a public key it is safe to store it with etherboot, >which is a reasonable assertion. Wasn't thinking that it's unsafe with Etherboot but that there may be uses where you want to separate the key and be able to give the client one of multiple identities. |
|
From: Anselm M. H. <an...@ho...> - 2003-04-26 23:46:09
|
Hello Ken & Eric,
Sunday, April 27, 2003, 1:28:36 AM, Ken wrote:
>>> Which is why you want a conceptual layer in between to separate out how
>>> the key is fetched, it may not be with the image, e.g. it may be in a
>>> smart card. But that can come later.
>>
>>Though if it is a public key it is safe to store it with etherboot,
>>which is a reasonable assertion.
> Wasn't thinking that it's unsafe with Etherboot but that there may be
> uses where you want to separate the key and be able to give the client
> one of multiple identities.
Just in case one day USB support would become real, one could
implement not only SafeBoot but even the possibilty to require an USB
flash or thumb storage to contain the key... but that's future dreams.
Hey, who knows, perhaps etherboot could gain a palladium signature for
the Microshit/OutTel/BigBlue/${BADBOY} secure booting concept :-)
Off for today, good night,
Anselm mailto:an...@ho...
|
|
From: <ke...@us...> - 2003-04-28 00:22:12
|
>I'd like to know which RAM regions I can use safely during etherboot >runs. I cannot use -DRELOCATE at the moment as this crashes my virtual >machine with the lance driver, but one day it probably should work. >Can I just get myself e.g. 0x30000-0x307ff for buffer purposes? Why not a normal BSS buffer within Etherboot itself? |
|
From: <ebi...@ln...> - 2003-04-29 02:39:54
|
ke...@us... (Ken Yap) writes: > >I'd like to know which RAM regions I can use safely during etherboot > >runs. I cannot use -DRELOCATE at the moment as this crashes my virtual > >machine with the lance driver, but one day it probably should work. > >Can I just get myself e.g. 0x30000-0x307ff for buffer purposes? > > Why not a normal BSS buffer within Etherboot itself? A major point of relocation is that etherboot occupies no memory < 1MB, as that memory is in high demand. So a normal buffer allocated like: static unsigned char buffer[1024]; should work, and because it has no initializer gcc will put it in the bss section so it won't consume memory until runtime. Keeping the memory in etherboot will mean that etherboot will verify that it is not stomped by a loaded image. Anything like a static location is up for grabs by the image that is being loaded. When you get something working I will find it interesting. This definitely calls for an extension to mkelf or similar. Eric |
|
From: Anselm M. H. <ans...@gm...> - 2003-05-01 11:36:22
|
ebi...@ln...: > When you get something working I will find it interesting. This > definitely > calls for an extension to mkelf or similar. Yesterday, I got permission by RSAEURO to use their RSA codebase to develop some verification code for etherboot (they had some restricitve permissions earlier, but now don't have problems with their code getting modified, open-sourced and everything - we only need to notice in the code and in binary etherboot distributions that make use of it). That means I will work on it as soon as I'm back to Bonn (off for the long weekend). Status: MD5 generation works like a charm. My own-coded RSA code did only hang my CPU on 90% for one hour and returned something very unsimilar to the result openssl and openpgp produced... :-( That's why I decided to ask RSAEuro, and yesterday they answered. Notice follows when code works. Greetings, Anselm -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! |
|
From: Anselm M. H. <an...@ho...> - 2003-04-26 15:14:57
|
Hello Ken, Saturday, April 26, 2003, 5:06:33 PM, you wrote: > Eric already has code in 5.1 that will call the checksum routine on data > blocks as they are loaded. You only need to use those hooks. I will have a look. >>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. > You should only need to modify the build rules that take a .zimg file to > a .zrom file. Maybe makerom can be modified to do the job. That way you > can change the key without having to recompile the source. You may need > to be able to read the ROM at the mapped address, not sure if this is > possible on all NICs. Problem is that SafeBoot also could make sense when etherboot is loaded from harddisk (floppy even, in some circumstances). I think when I'm so far, I will find a solution for that. > The motivation is weaker, you want to prevent the wrong clients from > running an image, as opposed to preventing the wrong server from > providing an image. That is, you indicate by keying the image to the > clients whether it's legal for those clients to run it. You could simply > not provide the wrong filename to the clients I suppose. I don't think > it's something important to have. OK, skipping that client key stuff for now. Best regards, Anselm mailto:an...@ho... |
|
From: <ebi...@ln...> - 2003-04-26 19:27:51
|
Anselm Martin Hoffmeister <an...@ho...> writes: > Hello Ken, > > Saturday, April 26, 2003, 5:06:33 PM, you wrote: > > > Eric already has code in 5.1 that will call the checksum routine on data > > blocks as they are loaded. You only need to use those hooks. > > I will have a look. A couple of little nits. The checksum is calculated just before the image is executed not as it downloads. The checksum is not calculated over the entire ELF image instead it is calculated over the significant parts. The ELF header The ElF program header The ELF PT_LOAD segments. The note segment (where the checksum is kept) is deliberately left out of the calculation. This should help with the signing process as well. > >>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. > > > You should only need to modify the build rules that take a .zimg file to > > a .zrom file. Maybe makerom can be modified to do the job. That way you > > can change the key without having to recompile the source. You may need > > to be able to read the ROM at the mapped address, not sure if this is > > possible on all NICs. > > Problem is that SafeBoot also could make sense when etherboot is > loaded from harddisk (floppy even, in some circumstances). > I think when I'm so far, I will find a solution for that. One question worth looking into is how is IPsec supposed to work for key distribution. > > The motivation is weaker, you want to prevent the wrong clients from > > running an image, as opposed to preventing the wrong server from > > providing an image. That is, you indicate by keying the image to the > > clients whether it's legal for those clients to run it. You could simply > > not provide the wrong filename to the clients I suppose. I don't think > > it's something important to have. > > OK, skipping that client key stuff for now. Yep one piece at a time. Eric |
