Separately encrypt dual-boot system: Windows+Arch

Kape · 2013-01-24 13:54:59

Hey guys, I want to use a dual-boot system: Windows 7 + Arch (windows being first on hdd). I would also want to encrypt them, but make it so I could access them with different passwords, like if I enter arch, i woudn't be able to see contents of windows, and vice-versa. I need arch to be on LVM, ext4 filesystem(the latter not so important, if it's trouble).

I've come accross this guide: https://aprescott.com/posts/dual-bootin … encryption which describes windows 7 encrypted with truecrypt + arch(on lvm) encrypted with dm-crypt+luks, grub legacy is put inside MBR, truecrypt bootloader resides on linux /boot, copied from MBR after truecrypt installed it there and then replaced with GRUB. With described approach there is windows boot partition and linux boot partition which remain unencrypted.

1) The question is, is it possible to do something similar but make those boot partitions encrypted too? so the only thing unencrypted would be MBR? I've read that people used Disc cryptor and with it easily encrypted windows boot partition with no trouble. What about linux boot partition? Maybe there is a way not to make separate /boot for linux, and encrypt the whole lvm partition with truecrypt(so truecrypt would install it's bootloader into MBR and i could save it and use just like in the link i gave above)?

2)Another question is for people using truecrypt for whole disk encryption. When you do full disk encryption or system encryption(for example Windows), the only thing left unencrypted is MBR? Is the boot sector of windows partition encrypted too? So in this case it maybe possible to keep MBR(at least the bootloader, without partition table) on separate media.

3)Also, in case of full disk encryption, is partition table encrypted too?

and please, I don't want questions as "Why do you need it this way?". I just want to have full disk encryption, so if the MBR is the only thing unencrypted I could keep it on separate media and boot from it(Disc Cryptor allows such feature), but I also need the system to be split into windows and linux parts, accessible by different passwords. And I dont think the idea of using truecrypt hidden partition and hidden os is good in here.

Thanks in advance.

Last edited by Kape (2013-01-24 13:58:41)

hiciu · 2013-01-24 16:01:19

/dev/sda
+--------------------------------------+
|(mbr and partition table)             |
| +----------------------------------+ |
| |(truecrypt) windows boot partition| |
| |----------------------------------| |
| |(truecrypt) windows 7             | |
| |----------------------------------| |
| |linux boot partition              | |
| |----------------------------------| |
| |(lvm on luks)                     | |
| | +------------------------------+ | |
| | |rootfs                        | | |
| | |------------------------------| | |
| | |home                          | | |
| | |------------------------------| | |
| | |swap                          | | |
| | +------------------------------+ | |
| +----------------------------------+ |
+--------------------------------------+

3)Also, in case of full disk encryption, is partition table encrypted too?

Take a look at diagram #1 :). Mbr and partition table will be not encrypted. You don't want that: there are no sensitive data in there; both windows and linux need to access partition table to know where are partitions on disk; mbr must contain some not encrypted code that will be loaded by bios, since that code can't be encrypted it can be modified (potentially in such a way to hide the modifications from the system), as long as you boot from this device there is no way around it without "secure boot" and mbr singing.

I believe windows boot partition and windows partition can be encrypted with truecrypt (you need to check that, I don't know truecrypt). There still will be some minimal not encrypted bootloader in order to ask you for for key / passphrase, so it is not 100% secure (someone could replace it; search for "evil maid" attack by Joanna Rutkowska).

Linux bootloader (I forgot about it on diagram) and linux boot partition can't be encrypted (again, unless you do: truecrypt -> grub2 / syslinux -> linux, and there still will be not encrypted minimal bootloader).

You see, the problem is always the same: you can't boot from encrypted device. You need something that will decrypt it first.

I just want to have full disk encryption, so if the MBR is the only thing unencrypted I could keep it on separate media and boot from it(Disc Cryptor allows such feature), but I also need the system to be split into windows and linux parts, accessible by different passwords.

In order to secure boot partitions / bootloaders one could separate encryption and bootloaders, keep data on encrypted disk and keep bootloaders code at secure location (i.e. on pen drive attached to key chain). Take a look at diagram #2:

/dev/sda                                   /dev/usb-stick
+--------------------------------------+   +--------------------------+
|(mbr and partitions table)            |   |(mbr and partitions table)|
| +----------------------------------+ |   | +----------------------+ |
| |other data / partitions           | |   | |linux boot partition  | |
| +----------------------------------+ |   | | +------------------+ | |
| |(lvm on luks)                     | |   | | |grub / syslinux   | | |
| | +------------------------------+ | |   | | |kernel            | | |
| | |rootfs                        | | |   | | |initramfs         | | |
| | |------------------------------| | |   | | +------------------+ | |
| | |home                          | | |   | +----------------------+ |
| | |------------------------------| | |   +--------------------------+
| | |swap                          | | |
| | +------------------------------+ | |
| +----------------------------------+ |
+--------------------------------------+

In this setup you boot your system from usb stick. Bios will load and execute mbr and bootloader from usb stick (and you know its good since you have it physically secured), it should decrypt luks and boot system. You still can run windows with truecrypt using /dev/sda as boot device. I know I didn't exactly answered your questions.

Last edited by hiciu (2013-01-24 16:02:51)

Kape · 2013-01-25 00:46:04

hiciu wrote:

/dev/sda
+--------------------------------------+
|(mbr and partition table)             |
| +----------------------------------+ |
| |(truecrypt) windows boot partition| |
| |----------------------------------| |
| |(truecrypt) windows 7             | |
| |----------------------------------| |
| |linux boot partition              | |
| |----------------------------------| |
| |(lvm on luks)                     | |
| | +------------------------------+ | |
| | |rootfs                        | | |
| | |------------------------------| | |
| | |home                          | | |
| | |------------------------------| | |
| | |swap                          | | |
| | +------------------------------+ | |
| +----------------------------------+ |
+--------------------------------------+
3)Also, in case of full disk encryption, is partition table encrypted too?
Take a look at diagram #1 . Mbr and partition table will be not encrypted. You don't want that: there are no sensitive data in there; both windows and linux need to access partition table to know where are partitions on disk; mbr must contain some not encrypted code that will be loaded by bios, since that code can't be encrypted it can be modified (potentially in such a way to hide the modifications from the system), as long as you boot from this device there is no way around it without "secure boot" and mbr singing.
I believe windows boot partition and windows partition can be encrypted with truecrypt (you need to check that, I don't know truecrypt). There still will be some minimal not encrypted bootloader in order to ask you for for key / passphrase, so it is not 100% secure (someone could replace it; search for "evil maid" attack by Joanna Rutkowska).
Linux bootloader (I forgot about it on diagram) and linux boot partition can't be encrypted (again, unless you do: truecrypt -> grub2 / syslinux -> linux, and there still will be not encrypted minimal bootloader).
You see, the problem is always the same: you can't boot from encrypted device. You need something that will decrypt it first.
I just want to have full disk encryption, so if the MBR is the only thing unencrypted I could keep it on separate media and boot from it(Disc Cryptor allows such feature), but I also need the system to be split into windows and linux parts, accessible by different passwords.
In order to secure boot partitions / bootloaders one could separate encryption and bootloaders, keep data on encrypted disk and keep bootloaders code at secure location (i.e. on pen drive attached to key chain). Take a look at diagram #2:
/dev/sda                                   /dev/usb-stick
+--------------------------------------+   +--------------------------+
|(mbr and partitions table)            |   |(mbr and partitions table)|
| +----------------------------------+ |   | +----------------------+ |
| |other data / partitions           | |   | |linux boot partition  | |
| +----------------------------------+ |   | | +------------------+ | |
| |(lvm on luks)                     | |   | | |grub / syslinux   | | |
| | +------------------------------+ | |   | | |kernel            | | |
| | |rootfs                        | | |   | | |initramfs         | | |
| | |------------------------------| | |   | | +------------------+ | |
| | |home                          | | |   | +----------------------+ |
| | |------------------------------| | |   +--------------------------+
| | |swap                          | | |
| | +------------------------------+ | |
| +----------------------------------+ |
+--------------------------------------+
In this setup you boot your system from usb stick. Bios will load and execute mbr and bootloader from usb stick (and you know its good since you have it physically secured), it should decrypt luks and boot system. You still can run windows with truecrypt using /dev/sda as boot device. I know I didn't exactly answered your questions.

1)so this way i can leave mbr(including partition table) empty on hdd, while having them on usb stick? good. I can put copy of mbr with truecrypt loader on that usb stick too along with /boot partition just like in the link i gave above? So there would be NOTHING left unencrypted on my hdd? i like it.

2)My main goal is that hdd would look like blank if someone would want to check its contents. I've heard using Luks leaves some traces in the volume header?(it's not possible to use truecrypt for full linux system encryption too, right?)

3)How do i properly put /boot on usb stick? Also will there be any troubles updating arch with /boot being on separate media?

thanks!

hiciu · 2013-01-25 01:42:31

Kape wrote:

hiciu wrote:
In this setup you boot your system from usb stick. Bios will load and execute mbr and bootloader from usb stick (and you know its good since you have it physically secured), it should decrypt luks and boot system. You still can run windows with truecrypt using /dev/sda as boot device. I know I didn't exactly answered your questions.
1)so this way i can leave mbr(including partition table) empty on hdd, while having them on usb stick? good.

No. You can only be sure that no code from mbr will be executed when system is booted. I think mbr can be empty, but partition table *must be on the disk and it can't be encrypted* (again, you probably dont want to encrypt it. It only says where are partitions on disk).

Of course you could, from initrd hook do something like:

cat mbr partition-table > /dev/sda; partprobe /dev/sda; cat empty-mbr empty-partition-table > /dev/sda;

And keep mbr, partition-table and other files in initrd, but its hack and it will not work with windows.

Kape wrote:

I can put copy of mbr with truecrypt loader on that usb stick too along with /boot partition just like in the link i gave above?

I don't know if you can do this with truecrypt. I have similar setup (luks only) on my pc. Looks like it should be possible.

Kape wrote:

So there would be NOTHING left unencrypted on my hdd? i like it.

If you remove windows from this equation you can use /dev/sda as luks device (and have lvm on top of that). Otherwise, windows need partition table.

Kape wrote:

2)My main goal is that hdd would look like blank if someone would want to check its contents. I've heard using Luks leaves some traces in the volume header?(it's not possible to use truecrypt for full linux system encryption too, right?)

You can think of luks like a frontend to dm-crypt. In luks header there are things like cipher, key size, encryption key encrypted with PBKDF2 that dm-crypt needs to know before it can decrypt device. My luks header looks like that:

$ sudo head -c 100 /dev/sda | xxd
0000000: 4c55 4b53 babe 0001 6165 7300 0000 0000  LUKS....aes.....
0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 7874 732d 706c 6169  ........xts-plai
0000030: 6e00 0000 0000 0000 0000 0000 0000 0000  n...............
0000040: 0000 0000 0000 0000 7368 6131 0000 0000  ........sha1....
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000                                ....

As you can see, it does not look like blank at all :). Of course you can use dm-crypt without luks; see http://code.google.com/p/cryptsetup/wik … s#2._Setup under '2.2 What is the difference between "plain" and LUKS format?', but even then disk will look like it have garbage data, it will not be blank.

Kape wrote:

3)How do i properly put /boot on usb stick? Also will there be any troubles updating arch with /boot being on separate media?

I did that during installation; usb stick was visible as /dev/sdb so I made partition on it, made it bootable, mounted it in /mnt/boot and installed there grub. Just like on any other partition. There was a catch here, but I can not remember what it was.

When updating arch you will need to have usb stick mounted in /boot in case if there is kernel upgrade. Normally mine usb stick is needed only to boot linux, I can remove it after grub screen. If you forget to mount it you will need to manually boot and fix things (it's easy after several times).

PaulBx1 · 2013-01-25 04:09:30

Normally the contents of /boot should be no more interesting to snoops than the MBR. In most cases all you want is to make sure it is not sneakily corrupted with some malware. I have been satisfied with an unencrypted /boot since I added chkboot to ensure it was not being messed with. See this item:

https://wiki.archlinux.org/index.php/Dm … _partition

Last edited by PaulBx1 (2013-01-25 04:17:02)

hiciu · 2013-01-25 13:56:13

PaulBx1 wrote:

Normally the contents of /boot should be no more interesting to snoops than the MBR. In most cases all you want is to make sure it is not sneakily corrupted with some malware. I have been satisfied with an unencrypted /boot since I added chkboot to ensure it was not being messed with.

I may be a little paranoid, but you are leaving the most important piece of code unencrypted, on disk and you are checking if it was modified only after you executed it. If someone can access your /boot partition it can also modify kernel in such way that accessing raw block device (or only filesystem layer) will return unmodified results. Even if you detect that your /boot partition has been modified you already gave your password to the attacker. With unencrypted /boot (and one-time access to your pc) I can clone all your encrypted partitions and I can modify initrd in such way, that it will remember your password, connect to the network and send it via email (all without leaving initrd).

But, as I said, I may be a little paranoid :).

Strike0 · 2013-01-25 18:29:47

hiciu wrote:

Even if you detect that your /boot partition has been modified you already gave your password to the attacker. With unencrypted /boot (and one-time access to your pc) I can clone all your encrypted partitions and I can modify initrd in such way, that it will remember your password, connect to the network and send it via email (all without leaving initrd).

Yes, but
(a) You can name the chkboot differently and choose where to store the logs of it - so that it cannot be guessed by the attacker.
(b) The discovery of a manipulation happens at start up and there is no need to have an automatic network connection before the script checks authenticity of /boot --> if you adhere to that, the email stays in ram or on the compromised PC at least.
(c) The script also checks mbr/inodes, leaving few space to manipulate the initrd and "restore" it after password discovery.

However,
(d) If you have to worry (/be paranoid) about your data this far, you better go the USB-boot way you described or wait for a secureboot-PC.

By the way: with which tool did you do those ascii-drive mapping charts? They look neat.

hiciu · 2013-01-25 18:33:26

Strike0 wrote:

By the way: with which tool did you do those ascii-drive mapping charts? They look neat.

http://www.asciiflow.com/

Strike0 · 2013-01-25 19:34:11

hiciu wrote:

http://www.asciiflow.com/

Cheers.

PaulBx1 · 2013-01-25 20:06:59

I admit a USB boot sounds more fool-proof and secure than chkboot. I may have to look into that myself...

<later>

Now that I think of it, chkboot seems a good idea in any case. With a separate boot USB flash drive it can still check /boot and the MBR. This would help take care of any possibility you got separated from your flash drive (taking a shower? :-) ) and had it messed with. Not 100% perfect, for reasons already mentioned, but another pretty good stumbling block for the snoops.

Last edited by PaulBx1 (2013-01-25 20:15:51)

PaulBx1 · 2013-01-25 20:29:19

If you remove windows from this equation you can use /dev/sda as luks device (and have lvm on top of that). Otherwise, windows need partition table.

To boot Windows:
1) Boot linux (it's fast with systemd, or might not even need to go past initrd?)
2) Copy saved partition table to sda
3) Reboot into Windows
4) When done, reboot into linux
5) Copy garbage into sda partition table
6) Shut down

Of course that makes Windows inconvenient to use, but we already knew that. :-)

You might have a special linux kernel line in grub whose only purpose is to automatically (as much as possible) do these steps.

Last edited by PaulBx1 (2013-01-25 20:33:50)

Kape · 2013-01-31 21:02:01

So I've tested truecrypt and Disk cryptor, neither of them do encrypt partition table(I used whole disk encryption for truecrypt). Disk cryptor also doesn't have the option for full disk encryption, but it's easily achieved by encryption every partition separately(including Windows 7 Boot). And Disk Cryptor is damn very convenient to use, bootloader has many option to configure, but I don't know if it's as reliable in protection as Truecrypt(but I also know nothing about truecrypt real protection reliability). But it's not supported in linux.
What do you guys think, will it run under WINE, so I could access encrypted windows partitions from linux?

How come partition table encryption is stated in arch linux wiki? Mistake or I just didn't find the right option? https://wiki.archlinux.org/index.php/Di … plications

I guess dm-crypt doesn't allow encrypting partition table too? Anybody who knows that? Maybe guys who stated it in wiki?

Last edited by Kape (2013-01-31 21:03:51)

Arch Linux

#1 2013-01-24 13:54:59

Separately encrypt dual-boot system: Windows+Arch

#2 2013-01-24 16:01:19

Re: Separately encrypt dual-boot system: Windows+Arch

#3 2013-01-25 00:46:04

Re: Separately encrypt dual-boot system: Windows+Arch

#4 2013-01-25 01:42:31

Re: Separately encrypt dual-boot system: Windows+Arch

#5 2013-01-25 04:09:30

Re: Separately encrypt dual-boot system: Windows+Arch

#6 2013-01-25 13:56:13

Re: Separately encrypt dual-boot system: Windows+Arch

#7 2013-01-25 18:29:47

Re: Separately encrypt dual-boot system: Windows+Arch

#8 2013-01-25 18:33:26

Re: Separately encrypt dual-boot system: Windows+Arch

#9 2013-01-25 19:34:11

Re: Separately encrypt dual-boot system: Windows+Arch

#10 2013-01-25 20:06:59

Re: Separately encrypt dual-boot system: Windows+Arch

#11 2013-01-25 20:29:19

Re: Separately encrypt dual-boot system: Windows+Arch

#12 2013-01-31 21:02:01

Re: Separately encrypt dual-boot system: Windows+Arch

Board footer