Differences
This shows you the differences between two versions of the page.
|
safebootmode [2006/06/25 06:46] stockholm created from the old wiki, partially rewritten |
safebootmode [2006/06/25 06:46] (current) stockholm created from the old wiki, partially rewritten |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ===== SafeBootMode ===== | ||
| + | ==== Trust and Security in network booting ==== | ||
| + | On regular PC systems, the aspect of which operating system is booted, where the kernel will be loaded from etc. can be controlled (more or less) reliably. For example, with a proper setup GRUB bootloader, in combination with an operating system like GNU/Linux, users will not be able to change the boot options without opening the PC case and (for example) resetting the BIOS or attach additional drivers - which is rather unlikely in most office networks, and even then, seals and lockable screws could be used. | ||
| + | In a network boot environment, things are different. Unplugging a host PC and using the network cable for e.g. a notebook, then running a DHCP server and providing tampered operating systems to one or all hosts on a network might be a serious security problem. | ||
| + | |||
| + | To overcome the necessity for Etherboot-booting hosts to "trust" the DHCP and TFTP server, the SAFEBOOTMODE feature has been implemented as //experimental// in Etherboot 5.1. | ||
| + | |||
| + | ==== SafeBootMode functional overview ==== | ||
| + | A SAFEBOOTMODE extended Etherboot ROM will behave very similar to regular Etherboot ROMS: It will issue a DHCP request, download the boot file - and then, check the cryptographical signature of this boot file. Only boot files signed by the private key matching the compiled-in public key in the ROM will be accepted, else boot will be refused. | ||
| + | |||
| + | Even stealing a ROM from a machine will not help retrieving the private key - this is a huge advantage of public-key cryptography over symmetric cryptography. | ||
| + | |||
| + | In the current state of code (which does not look like being extended, with a better, SSH based solution coming up this summer of code), only .NBI files can be used for signatures. A positive aspect is that those signed NBIs are fully compatible with Etherboot versions that are not aware of SAFEBOOTMODE - the signature is stored in an otherwise unused portion of the NBI header. | ||
| + | ==== Description from <code>etherboot-5.1/contrib/safeboot/safeboot.txt ==== | ||
| + | <file> | ||
| + | SafeBoot? is an extension to etherboot that allows the careful sysadmin | ||
| + | to verify only those OS-images are started that he originally installed. | ||
| + | This is - waiting for someone to contradict me - a method to 99,999% | ||
| + | exclude the chance that someone else manipulates IP packets on the wire | ||
| + | and so makes the client start a modified operating system. | ||
| + | Security is achieved by distributing a "public key" with the etherboot | ||
| + | software on the ROM chip, while the "private key" stays on the server - | ||
| + | or somewhere else. Any NBI image has its MD5? checksum "signed" (with | ||
| + | openssl, for those who don't trust homebrew solutions in cryptography:-) | ||
| + | and on the client side this checksum can be verified. If some anomaly | ||
| + | is detected, the client will interrupt booting and wait for some user | ||
| + | to interactively confirm that booting shall proceed. | ||
| + | For using SafeBoot?, at this moment, the public key has to be stored | ||
| + | inside the etherboot sources. So get them, change into the src/ dir | ||
| + | and create a key (which then can be reused to sign as much images as | ||
| + | you like) with "../contrib/safeboot/sign-nbi.pl gen". | ||
| + | This will result in a file ".KEY" in the current directory. Enter | ||
| + | the public key into the code with "../contrib/safeboot/sign-nbi.pl code" | ||
| + | and move the .KEY file to any location you like - even a floppy might | ||
| + | be a viable solution. Don't lose it, or you won't be able to create | ||
| + | new signed images without reburning your ROMs?! | ||
| + | Then activate -DSAFEBOOTMODE=0 in your "Config" and compile the ROM. | ||
| + | To sign any NBI (e.g. those from LTSP - which I did not test yet), | ||
| + | enter "path/to/sign-nbi.pl sign <nbi-filename>". Take care that on | ||
| + | issuing this command, ".KEY" must exist in the current working | ||
| + | directory. | ||
| + | For signature storage, a usually unused region of the NBI header | ||
| + | is filled with 64 Bytes of data (bytes 446 to 509 are over- | ||
| + | written). If you have a special NBI with lots of memory sections or | ||
| + | lot of vendor information, it could happen that it is broken by this | ||
| + | code - so better backup first. Anyhow, there could be some 12 or so | ||
| + | memory sections, and I never saw a NBI with more than 6 used. | ||
| + | The rsa.c code is copyrighted by RSAEuro? - please look into that file | ||
| + | (in the src/core/ directory) to find out more. It is used after | ||
| + | confirmation of the copyright holder that this software may be | ||
| + | distributed freely - as long as changes are reported to them and that | ||
| + | the copyright notice stays attached. Import/Export from/to US is no | ||
| + | problem anymore as the RSA algorithm has been freed somewhen in the | ||
| + | spring 2000 by its US copyright holder RSA Inc. | ||
| + | The supported file is crippled so only *decryption* of an rsa- | ||
| + | signature can be performed yet. I hope this is no hindrance anymore | ||
| + | to export to anywhere in the world. Behave. | ||
| + | Changes to rsa.c, osloader.c mainly, are | ||
| + | (C) 2003 Anselm Martin Hoffmeister, anselm AT hoffmeister-online DOT de | ||
| + | </file> | ||
| + | ==== Advantages of secure booting ==== | ||
| + | By using the SAFEBOOTMODE features you can assure that no bogus TFTP servers on the network can supply boot files that might e.g. present a login screen to capture your password. | ||
| + | |||
| + | Anyway, on a regular LTSP setup, you should then consider going for NFS encryption (not yet available) and X11 protocol encryption (neither, at the moment AFAIK). | ||
| + | ==== Future of secure booting ==== | ||
| + | There is a Google Summer of Code project dealing with secure booting matters. | ||
| + | |||
| + | It might turn out sooner or later a method of using SSL based protocols for boot file download - as such, SFTP, HTTPS and FISH come to mind. Imagine the booting machine could verify the HTTPS server certificate for validity for example.... This would of course make signing specific files unnecessary as well as open this process up for booting ELF images, which is currently not possible due to the NBI header crypto storage. | ||
