On Sun, 9 Feb 2003, Jim Choate wrote: > On Sun, 9 Feb 2003, Sunder wrote: > > > No shit Sherlock, that's the whole point! > > Actually it's not, the point is to stop the attacker in their tracks.
Sigh, I don't know why I'm bothering to write anything your clueless way... he we go. We're guaranteed you'll miss every point here, but what the fuck - I'm feeling masochistic today and so I'll visit Choate'. Yes, that is the meta-goal here. Encrypting a disk prevents the attacker from just stealing the disk and using another OS to access the data. You still need to solve the issue of the OS itself accessing the data. But you want to encrypt things such as the swap, temp files, etc because they can leak data and possibly your key. Other vectors of attack come into play after the OS has booted fully and include such things as vulnerabilities in the OS itself, applications, software key grabbers, etc. We won't address those here. > > The OS doesn't boot until you type in your passphrase, plug in your USB fob, > > etc. and allow it to read the key. Like, Duh! You know, you really ought to > > stop smoking crack. > > Spin doctor bullshit, you're not addressing the issue which is the > mounting of an encrypted partition -before- the OS loads (eg lilo, which > by the way doesn't really 'mount' a partition, encrypted or otherwise - > it just follows a vector to a boot image that gets dumped into ram and > the cpu gets a vector to execute it - one would hope it was the -intended- > OS or fs de-encryption algorithm). What does that do? Nothing (unless > you're the attacker). A Spin Doc is a marketting guy who puts a spin on a story, I'm unsure what you mean here. Perhaps Ad Homeneim would be better suited - save that there is a long history between you and reality. :) LILO lives in either the MBR or the 1st sector of the Linux boot partition. (The same applies to GRUB and other boot loaders for other OS's) All it needs to do is load the kernel plus the initrd image (ram disk containing kernel modules for various drivers such as the disk.) At this point you can do one of several things: You can compile in a small blowfish/SHA implementation into LILO and have LILO ask you for your passphrase if you want the kernel to live in the encrypted disk. In this case you'll need some mechanism to pass the key to the kernel so when it kicks in the encrypted disk driver, it'll be able to mount /, etc. Otherwise /boot can be naked so long as you diff it against a CD or another known pristine source. Any changes there and you've got a dead canary. :) If /boot is naked, and that's fine too so long as you take care when your system mysteriously reboots. At this point, the kernel boots up, the initrd image is available to it so it can load its modules, one of which can be the encrypting block driver can load. When it does, it can ask for the passphrase for each volume to mount when mount is called, etc. You may have some fun with having to tell the kernel what device / lives on, and so long as the encrypted block device driver is used, it'll mount it from there. Same with swap and other partitions. If you wanna do a USB fob or other device, you'll need to have the driver for that fob (and anything else it'll need) loaded before the encrypting block driver, and of course the underlying IDE/SCSI drivers need to be loaded in the kernel before it too. > There are two and only two general applications for such an approach. A > standard workstation which isn't used unless there is a warm body handy. > The other being a server which one doesn't want to -reboot- without human > intervention. Both imply that the physical site is -secure-, that is the > weakness to all the current software solutions along this line. No shit, if you're hackable at the physical layer, all bets are already off - you can consider yourself owned - it's just a matter of time. And physical restraints do nothing other than delay an attacker. If you're hackable - say in a way that will give your attacker remote root access, it's actually worse than the attacker having physical access because your OS is running, it's encrypted partitions are accessible and mounted - and if your attacker can install a kernel module, you're douily fucked as you won't be able to detect their presence. For physical access, the best you can do is attempt to detect the event, send out warnings, and log the event, wipe RAM and halt the machine; then it doesn't matter, the attacker has nothing more than a pile of hardware with some random numbers on its spindles. Useless without the key worth whatever ebay will pay for it. This is why a keyboard is not a good way to enter a passphrase - it can be removed from the PC and modified, or taken apart without disconnecting it and a capture device added - just turn it upside down, unscrew, solder, screw and done. The best you can do with a workstation is to have it on all the time and have something watching it for reboots, outages, etc. If it's always on and watched, you can at least limit the attacker to remote root style attacks, which if you've hardened your machine well are also limited (provided you have users that chose security over dancing gophers.) ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :NSA got $20Bil/year |Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ <--*-->:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. [EMAIL PROTECTED] http://www.sunder.net ------------
