Hey, I've been reading through the TCPA documents and thinking a bit about changes that might give higher assurance to an ordinary PC, or at least a PC with only minor changes. Specifically, one of the things I've always been mulling over is a secure boot sequence. Basically, like the TCPA, I want a sequence where each stage decrypts and validates the next one so that a user doesn't have to worry about modifications to the bootup state. Basically, I've been thinking about rewriting the BIOS (perhaps with large portions in FORTH a la openfirmware*) such that instead of prompting the user for a password which is compared to a stored copy (that can be erased by removing the battery), it instead prompts the user for a passphrase that is used to decrypt and authenticate the MBR (boot block) and possibly the first-stage boot loader. The boot loader in turn decrypts and authenticates the kernel and any associated crud it needs (perhaps supporting the multiboot spec), and the kernel and crud are smart enough to decrypt and authenticate the root partition, and away we go. [*] http://www.openfirmware.org/ Similarly, I wouldn't mind seeing a PCI card or something that is designed for securely storing crypto keys (from DMA among other things) and performing crypto operations. These parts of the TCPA are okay. I don't see the need to curtain memory, as I'm comfortable with the "ring 0 can do anything" property. Additionally, it would be nice to have a "trusted path" to the OS, whereby a certain key sequence triggers a direct input path to a program, or the user is assured of what program he/she is talking to. http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/trusted-path.h... Is it possible to implement most block ciphers in FPGAs? It'd be nice to have a bus-mastering crypto co-processor device to do, say, disk encryption without requiring CPU help, but I want to be able to update it to new algorithms as new attacks against the cipher appear. I use some disk encryption stuff on a dual processor machine and it's still slow. The load climbs to 10 or 12 all too easily, then stuff becomes unresponsive (perhaps because swap is one of the things I'm encrypting). -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
On Thu, 2005-12-01 at 02:08 -0600, Travis H. wrote:
I use some disk encryption stuff on a dual processor machine and it's still slow. The load climbs to 10 or 12 all too easily, then stuff becomes unresponsive (perhaps because swap is one of the things I'm encrypting).
What processors, specifically? (If you expect a dual Pentium 100 system
to work miracles, that's your problem.)
What operating system? I'm pretty sure OpenBSD encrypts swap out of the
box, and it is SMP capable. Chances are if you're getting double-digit
load just from normal use due to swap encryption, you either don't have
anywhere near enough RAM, don't have enough CPU, or the code you're
running is inefficient.
--
Shawn K. Quinn
On Thu, 1 Dec 2005, Travis H. wrote:
Is it possible to implement most block ciphers in FPGAs? It'd be nice to have a bus-mastering crypto co-processor device to do, say, disk encryption without requiring CPU help, but I want to be able to update it to new algorithms as new attacks against the cipher appear. I use some disk encryption stuff on a dual processor machine and it's still slow. The load climbs to 10 or 12 all too easily, then stuff becomes unresponsive (perhaps because swap is one of the things I'm encrypting).
Have you tried the swap-encryption option in OpenBSD? According to
http://www.openbsd.org/papers/swapencrypt.ps
the performance is pretty good.
ciao,
--
-- Jonathan Thornburg
participants (3)
-
Jonathan Thornburg -
Shawn K. Quinn -
Travis H.