One thing that encryption in the bootstrap CAN do is prevent Trojan attacks against the kernel image. If attackers can't find out what the encryption key is they can't create a substitute Trojan kernel. It plugs a hole.
Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center Liberty Lake, Washington v: 509-343-3524 f: 509-343-3501
-----Original Message----- From: SONE Takeshi [mailto:ts1@tsn.or.jp] Sent: Wednesday, October 22, 2003 2:18 AM To: Evan Langlois Cc: linuxbios@clustermatic.org Subject: Re: AMD64: Something's missing?
On Tue, Oct 21, 2003 at 10:26:01PM +0200, Evan Langlois wrote:
EtherBoot can boot lots of things from the network or an IDE hard
disk.
FILO can boot from IDE hard disk, IDE CDROM, floppy, and maybe more?
9load
I don't know much about except that it is used to load the plan9
kernel.
I don't know much about FILO. Can anyone comment on its compatibility
with
the LILO graphical features (displaying graphical menus/splash
screens), and
is there any support available for encrypted filesystems?
FILO is not aimed at being compatible with LILO.
Assuming FILO works like LILO, and doesn't know about filesystems, I'm
assuming encryption would be difficult, and it might therefore be best
to
chain-load another boot-loader, but I'd want the encryption keys to be
in the
ROM to make it as difficult as possible to get to them.
FILO has filesystem routines borrowed from GRUB, so it works like GRUB rather than LILO.
Encryption in the BIOS itself may be a positive feature, not just for corporate users that want to protect their IP, but laptop users and
such (in
which case the key would be asked for on boot) that don't want
sensitive
information leaking out just because a laptop was stolen.
Encryption in boot process doesn't make sense to me. What you want to protect is the data in the storage, not the boot image (kernel). Encryption of the storage is OS's bussiness, and the OS will ask you the password before decrypting any data.
On Wed, Oct 22, 2003 at 08:25:28AM -0700, Alan Mimms wrote:
One thing that encryption in the bootstrap CAN do is prevent Trojan attacks against the kernel image. If attackers can't find out what the encryption key is they can't create a substitute Trojan kernel. It plugs a hole.
That is authorization rather than encryption. For this purpose, public key cryptography is used, so you don't have to have the secret key in the ROM. And the entire image is not encrypted for this purpose, because it needs lots of CPU power. Usually 128 or 160-bit hash is only encrypted.
This is much like Xbox. But who has the secret key is the system admin, not Microsoft.
IMHO the system is already broken so bad when an attacker can replace the boot image. But maybe some real use exists..