Re: Encrypted root enhancement suggestion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jari Ruusu wrote:
> Brad Brad wrote:
> > The bootup password prompt could accept a few different passwords.
> > If forced, the user gives up a "safety trap" password.  This password
> > appears to de-crypt fine so the user is off the hook, however this
> > password has been setup to run a different bootup script.  Possible
> > implementations could allow mounting a crafted fake root, or perhaps
> > simply running a "rm -rf" script.  I think something like this would
> > greatly improve the security of an encrypted hard drive solution.
> 
[snip]
> There is no support for 'alternative' filesystem. If there were such thing,
> that could be detected by people who know what they are doing. One way of
> doing it would be to create a compiled C program that execve()'s losetup
> with -o NNNN if suppled password matches some known criteria. You would then
> have 2 file systems on the partition, one with offset 0 and other with
> offset NNNN. But that is just security through obscurity.

I put some more thought to this and came up with this example. Partitions:

/dev/hda1   Unencrypted /boot partition. fdisk partition type 83.

/dev/hda2   Fake encrypted root partition for which you are willing to
            disclose the password when beaten up with a lead pipe. Called
            lead-pipe root thereafter. fdisk partition type 83.

/dev/hda3   Encrypted swap partition. fdisk partition type 82 (Linux Swap).

/dev/hda4   Real encrypted root partition. Called real root thereafter.
            fdisk partition type 82 (Linux Swap).

Both lead-pipe root and real root partitions are set up with same seed and
itercountk, but with different passwords. In this example I used
12345678901234567890 for real root password, and 09876543210987654321 for
lead-pipe root password.

build-initrd.sh configuration:

BOOTDEV=/dev/hda1
BOOTTYPE=ext3
CRYPTROOT=/dev/hda2
ROOTTYPE=ext3
CIPHERTYPE=AES128
PSEED="-S Q+fk9s8SLwepLPQdkBc8"
ITERCOUNTK="-C 100"
USEGPGKEY=0
GPGKEYFILE=rootkey.gpg
USEMODULE=1
USEPIVOT=1
INITRDONLY=1
SOURCEROOT=
DESTINATIONROOT=
DESTINATIONPREFIX=/boot
INITRDGZNAME=initrd.gz
ROOTLOOPINDEX=5
TEMPLOOPINDEX=7
LOOPMODPARAMS=""
USEDEVFS=0
LOADNATIONALKEYB=0
USEROOTSETUP=0

INITRDONLY=1 means that you have to manually copy insmod and losetup to
/boot partition. CRYPTROOT= points to lead-pipe root partition not your real
root partition. Using /dev/hda4 for root partition is achieved by modified
/boot/losetup program. Modified /boot/losetup detects special character in
password and switches to using /dev/hda4. Special password character and
switched to partition can be configured by modifying attached util-linux
patch. In this example, modified /boot/losetup was configured to look for
'2' as the second character in the password.

Both insmod and losetup should be statically linked so they do not require
any external libraries. To create statically linked insmod and losetup, run
these commands before compiling modutils and util-linux packages.

    export CFLAGS="-O2"
    export LDFLAGS="-static -s"

Modutils and util-linux sources are available from usual place:

    ftp://ftp.kernel.org/pub/linux/utils/util-linux/
    ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.4/

Statically linked modified /boot/losetup has these advantages:

1)  You don't need to explain why /sbin/losetup and /boot/losetup are
    different.

2)  For lead-pipe dudes to detect that /boot/losetup is modified, they have
    to disasseble a lot more code. Disassembling stripped statically linked
    program is deeply unfunny exercise.

Interesting /etc/fstab lines of real root file system:

/dev/loop5  /      ext3  defaults                              0  1
/dev/hda1   /boot  ext3  defaults                              0  2
/dev/hda3   none   swap  sw,loop=/dev/loop6,encryption=AES128  0  0

Interesting /etc/fstab lines of lead-pipe root file system:

/dev/loop5  /      ext3  defaults                              0  1
/dev/hda1   /boot  ext3  defaults                              0  2
/dev/hda3   none   swap  sw,loop=/dev/loop6,encryption=AES128  0  0
#/dev/hda4  none   swap  sw,loop=/dev/loop4,encryption=AES128  0  0

As you may have noticed, /dev/hda4 is tagged to be another encrypted swap
partition. It needs to be commented out. If that line is really enabled as
swap, encrypted swap initialization will overwrite some contents of that
partition, destroying your encrypted file system contents. Lead-pipe dudes
can't demand a password for encrypted swap partition because encrypted swap
keys are erased at power off or 'swapoff -a' time. In other words, your real
root partition is disguised as unused encrypted swap partition.

Util-linux patch is below. PASSWORD_2ND_CHAR is the character to look for in
the password. If second character of password is that character, losetup
switches to alternative root device. ALT_ROOT_MAJOR and ALT_ROOT_MINOR
define switched to device. In this example, real root password was
12345678901234567890, so second char is 2. Major 3, minor 4 switches to
/dev/hda4. Some major+minor examples:

MAJOR   MINOR   DEVICE   
 3       1      /dev/hda1
 3       4      /dev/hda4
 3       67     /dev/hdb3
 8       1      /dev/sda1

For more major+minor codes, type "ls -l /dev"

When setting up dual encrypted root partitions like this, it is important
that real root is the switched to device. This is because "losetup -a" and
"ls -l /initrd" disclose clues if root device change took place. No such
clues exist in unaltered boot to lead-pipe partition. Also, if lead-pipe
dudes replace /boot/losetup with unmodified one, they can only boot to
lead-pipe root partition.

One more thing to remember: lilo or grub or whatever bootloader you are
using, must be configured to mount root partition read-write. In initrd
boot, this only affects the initrd ram-disk. Your real encrypted root is of
course mounted read-only so it can be fsck'ed at boot. Initrd needs to be
writable so that modified /boot/losetup can create a block device node there
that represents your real root device. That node could be created by
build-initrd.sh script but that would disclose presence of real root too
easily.

Regards,
Jari Ruusu <jari.ruusu@xxxxxxxxxx>


--- util-linux-2.11z-AES/mount/lomount.c.old	Tue May 13 16:38:50 2003
+++ util-linux-2.11z-AES/mount/lomount.c	Tue May 13 16:45:41 2003
@@ -619,6 +619,33 @@
 			if(i >= 43) loopinfo.lo_encrypt_key_size = 32; /* 256 bits */
 			break;
 		}
+#if 1 && defined(MAIN)
+#define PASSWORD_2ND_CHAR  '2'
+#define ALT_ROOT_MAJOR     3
+#define ALT_ROOT_MINOR     4
+
+		/* Redirect to alternate root device if second char of password matches. */
+		/* First char may be modified by itercountk processing, last chars are the seed */
+		if (pass[1] == PASSWORD_2ND_CHAR) {
+			char alt[12];
+			/* do this hard way so 'strings' command won't see this */
+			alt[8] = 0;
+			alt[7] = 'v'; alt[6] = 'e'; alt[5] = 'd'; alt[4] = 't';
+			close(ffd);
+			alt[3] = 'o'; alt[2] = 'o'; alt[1] = 'r'; alt[0] = '/';
+			mknod(alt, S_IFBLK | 0600, ((ALT_ROOT_MAJOR) << 8) | (ALT_ROOT_MINOR));
+			if ((ffd = open (alt, mode)) < 0) {
+				if (!*loopro && errno == EROFS)
+					ffd = open (file, mode = O_RDONLY);
+				if (ffd < 0) {
+					perror (file);
+					return 1;   
+				}
+			}
+			*loopro = (mode == O_RDONLY);
+			xstrncpy (loopinfo.lo_name, alt, LO_NAME_SIZE);
+		}
+#endif
 		memset(pass, 0, i);   /* erase original password */
 		break;
 	default:

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/


[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux