Sorry about the (very) late reply. To restate my goal... I'd like an encrypted system hidden in the free space of a decoy system, while being able to upgrade the decoy, and plant new decoy email/web-cache. Furthermore, the encrypted system's initial (initrd) boot is done by hand commands, so there is no /sbin/init boot script. The boot disk would look typical, or even a knoppix kernel might work. The disk key is made by encrypting an image with a decoy file (a file containing "testing"), with loop-aes.. then the image is reinitialized with a different password.. the decoy file won't exist, but that's okay, the mangled image with the "wrong" password will be the encrypted disk's key.
The point of all this is that even if these instructions are found printed on paper and stuffed in a laptop, there's no way no know for sure if it was implemented. And if the key's password is demanded, it can be given without compromising the encrypted system. I'd want this for any particular reason, I just to see if it can be done. I want to redefine "tinfoil hat". I think this would work: hda1: decoy's swap (1GB) hda2: decoy's partition (4GB) hda3: decoy's /home (2GB) First wipe the whole drive with urandom, so that the encrypted system looks like leftovers from this wipe. Install the decoy system. Then 'dd if=/dev/hda3 of=hda3.img'. Then resize hda3 to consume the rest of the drive, and reformat it. Then install the encrypted system to a loop device using the space after 2GB of hda3. This way, the decoy system can boot normally, writing to /etc/fstab and /tmp, and use swap, without possibly damaging the encrypted system. The only way to damage the encrypted system, from the decoy, is to write to /home. The decoy system would have a very typical partition layout. Decoy upgrades could be done from either system, but the /home partition would not be mountable by the encrypted system; so the encrypted system needs mount hda3.img to plant web cache, and write it with 'dd if=hda3.img of=/dev/hda3'. The write will stop at 2GB, and would leave the encrypted system untouched. I can only see one possible problem. Would hda3, mounted under the decoy system, ever report filesystem damage because the encrypted system overwrote superblock backups, or other filesystem format information? What is looked for in free space with fsck? robert On June 21, 2005 11:06 pm, Anderson Lizardo wrote: > Robert Connolly wrote: > > On June 21, 2005 10:07 am, Carlos Martin wrote: > >>mount -o loop -t ext2 $HOME/hda2-part /mnt/2 > >> > >> Just make sure you have enough size on your hard drive. > >> > >>About the dissapearing file I don't know. Maybe because the first one > >>is mounted on a loop device, but it shouldn't happen, methinks. > > > > This might work, but its not very elegant, and its slow. I'll think about > > it. > > Hi Robert, > > I had an idea that may sound strange, but it might work (and is probably > fast): > > - You first create a partition table on the device (using e.g. fdisk), > with this setup (supposing the bootable device is /dev/hda: > > /dev/hda1 (decoy system) > /dev/hda2 (actual system) > > - After that, save the HDD's 1st sector (MBR + Partition table) to a file: > > dd if=/dev/hda of=actual_mbr.bin bs=512 count=1 > > - Format /dev/hda1 and install the decoy system. Do whatever crypto > stuff you want with /dev/hda2 (e.g. mount is as crypto loop and install > the actual system there). > > - Go back again to fdisk. remove both partitions, and setup it as > /dev/hda1 were the only partition there: > > /dev/hda1 (using the entire disk) > > Note that only the partition table is modified here, the data stays intact. > > - Save this new "decoy partition table" to a file: > > dd if=/dev/hda of=decoy_mbr.bin bs=512 count=1 > > Now comes the trick: > > - Put the decoy partition table back to /dev/hda: > > dd if=decoy_mbr.bin of=/dev/hda > > - Setup the initrd to run this command before mounting the HDD: > > dd if=actual_mbr.bin of=/dev/hda > > - And, finally, setup a bootscript on the actual system to cleanup its > trace from the 1st sector: > > dd if=decoy_mbr.bin of=/dev/hda > > You can, when on the actual system, access the decoy one by just > mounting /dev/hda1. > > If I understand correctly, when not booting with the initrd, this decoy > system is made to simply ignore (even overwriting data) the crypted data > as it never existed, right? Then I suppose the above scheme will do > exacly that ;-) > > PS: I used a similar scheme to "hide" a Linux system behind a supposedly > Windows-only PC, but I used a slightly different "decoy partition table" > where I left the space used by windows as "unused space" on fdisk, so > Windows would not overwrite my stealth Linux :). It was by no means a > security measure, but just a way to hide an entire OS from unawarew > -- > Anderson Lizardo > [EMAIL PROTECTED] > http://www.linuxfromscratch.org/ > > > > > _______________________________________________________ > Yahoo! Acesso Grátis - Internet rápida e grátis. > Instale o discador agora! http://br.acesso.yahoo.com/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
