Re: Integrate cryptsetup in bootloader

[Ralf Ramsauer <ralf+dm@xxxxxxxxxxxxxxxxxxxxxx>]

For me, it works fine with:

insmod luks
insmod cryptodisk
insmod crypto

cryptomount hdX,msdosY
set root=crypto0
linux <kernel>
initrd <ramdisk>

When using cryptomount you must not use brackets between hdX,msdosY.

Regards,
  Ralf




On 11/27/2013 03:16 AM, Trinh Van Thanh wrote:

According to this guide (http://www.coreboot.org/GRUB2#LUKS_disks_openning), I try cryptomount but it seems not working. So can cryptomount works with LUKS partitions?

On Wed, Nov 20, 2013 at 10:34 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote:

Hi Ralf,

On Tue, Nov 19, 2013 at 14:38:12 CET, Ralf Ramsauer wrote:
> Hi Arno,
>
> yes, you are absolutely right. If you can't trust your bootloader or
> some verification, you can't trust the rest of the system.
> Or in other words: if you don't have a starting point to trust, rest
> cannot be trusted.

Indeed.

> But attack vectors can be mitigated and the effort which is needed to
> tamper so.'s system can be increased.
>
> And in my opinion, crypto-stuff in GRUB is very straight forward.
> It is much easier to insert some malicious code into a initrd located on
> a unencrypted boot partition than inserting malicious code into the
> bootloader with limited capabilities.

I am not sure about this. The boot-loader comes only in a small
number of versions, while the initrd and kernel are much
more diverse and more comples, e.g. if you want to patch the
binary version.

Anyways, I agree that you can make the attack more expensive. One
thing is certainly to mess with the initrd yourself, e.g. by
displaying some checksums. This way, the attacker suddenly has to
use a targetted attack instead of a generic one, that is, e.g.
only tailored to a specific kernel/onitrd of a specific distro
release. This sill not stop a competent attacker, but even if they
have to invest one day of expert time, the attack suddenly costs
something like > 300 EUR instead of being almost free.

When I say these things do not work, I do not mean they are
worthless. I just want to prevent people from thinking the
approach makes them secure.

> As it is not always possible to drag along your trusted-USB-bootstick,
> this is a (yes, more insecure but) worth considering alternative.

Hmm. You cannot drag along the USB stick, but you can drag along a
whole computer? Care to give any example for that scenario? Maybe
my imagination is just too limited...

> I'll have a closer look at Milans link, never heard about the fact that
> GRUB is already able to deal with luks partitions, but it sounds quite
> interesting.

It is not Grub2 itself, it is a plug-in. There are other interesting
ones, for example a LUA plugin that would allow you to do basically
anything, albeit slow.

Report on what you find!

Arno

> Regards,
>   Ralf
>
> On 11/19/2013 05:20 AM, Arno Wagner wrote:
> > On Tue, Nov 19, 2013 at 04:42:55 CET, Ralf Ramsauer wrote:
> >> Hi,
> >>
> >> just an idea, but shouldn't it be possible to implement encryption
> >> algorithms incl. LUKS to GRUB?
> > Possible, yes. But it does not help. Instead of attacking the
> > kernel image or the initrd, an attacker could just attack the grub
> > executable, which could then patch the kernel or the initrd.
> >
> >> /Then GRUB would be able to read the encryption kernel image and a
> >> initramfs.
> >>
> >> The initramfs itself could contain the symmetric Masterkey in order to
> >> decrypt the partition afterwards.  No further password prompts would be
> >> needed.
> >>
> >> "All" that would be needed is to teach GRUB how to deal with encrypted
> >> partitions, what generally should be possible.
> >>
> >> The one and only parts that would stay unencrypted are the MBR and
> >> GRUB's stage2 or the modules.
> >>
> >> But that leads to the question if it is really necessary to hide your
> >> kernel and initrd?
> > If it is, then you need some other encryption scheme. Software-based
> > encryption will never be able to solve this issue. You can, for example,
> > have self-encrypting storage with keypad and display direcly on it
> > in the form of a trusted (and hopefully at least somewhat
> > tamper-resistant) module.
> >
> > This is not very good either, as tamper-resistance is basically
> > a myth unless you go to large, expensive and elaborate HSMs,
> > with independent power, all kinds of sensors and that are
> > designed by highly competent paranoids.
> >
> >> Signing your kernel and/or initrd could also prove the integrity and
> >> authenticity of your system.
> > No, it cannot. At least as long as the verification mechanism
> > is also on that system.
> >
> > The bottom line ist the following: For systems like dm-crypt/LUKS,
> > no additional protection for kernel and initrd is necessary, as
> > attackers that can compromise these can compromise the any possible
> > protection mechanisms for them as well. You can make things a
> > bit more expensive for attackers by rolling your own kernel and
> > initrd.
> >
> > But if you have this type of attackers, you need to step up your
> > protection to a different level, for example by investing
> > 50k-200k EUR for a real HSM that does your disk encryption.
> >
> > Arno
> >
> >
> >
> >> Regards,
> >>   Ralf
> >> On 11/19/2013 03:52 AM, Arno Wagner wrote:
> >>> Hi,
> >>>
> >>> this topic crops up from time to time. First, doing this yourself
> >>> is hard, hard enough that if you have to ask how to do it, you
> >>> will find it severely challenging.
> >>>
> >>> That said, it has been done by several distros that can be installed
> >>> with "full root encryption". (Full disk encryption is not doable with
> >>> cryptsetup. That would need BIOS support.) Best get one of the
> >>> distros that do it. They usually just pack cryptsetup and its
> >>> libaries into the initrd and write some scripts around it.
> >>>
> >>> One example I use on a laptop is Linux Mint, which will just show
> >>> you a box to enter your encrytpion password before booting any futher.
> >>> I expect Debian and Ubuntu can do something similar.
> >>>
> >>> Best recommendation if you want to do something like this yourself
> >>> is to analyze the initrd of a distro that has it working and go from
> >>> there.
> >>>
> >>> Arno
> >>>
> >>> On Tue, Nov 19, 2013 at 03:20:43 CET, Trinh Van Thanh wrote:
> >>>> Hi all,
> >>>>
> >>>> Unencrypted boot partition is not safe for some special requirements. So I
> >>>> want to increase the secure level for full disk encryption using dm-crypt.
> >>>> Can I integrate cryptsetup in bootloader (example GRUB2) or is there any
> >>>> other solutions?
> >>>>
> >>>> Thanks in advanced,
> >>>>
> >>>> --
> >>>> ​Trinh Van Thanh​
> >>>> _______________________________________________
> >>>> dm-crypt mailing list
> >>>> dm-crypt@xxxxxxxx
> >>>> http://www.saout.de/mailman/listinfo/dm-crypt
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@xxxxxxxx
> >> http://www.saout.de/mailman/listinfo/dm-crypt
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt

--
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@xxxxxxxxxxx
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

--

Trịnh Văn Thành

Add: No.5, 64/25 Lane, Phan Dinh Giot Street, Thanh Xuan Dist, Hanoi.

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt