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.

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.

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

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

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.