[dm-crypt] Integrate cryptsetup in bootloader

Trinh Van Thanh eyestormit at gmail.com
Wed Nov 27 03:16:20 CET 2013


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 at wagner.name> 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 at saout.de
> > >>>> http://www.saout.de/mailman/listinfo/dm-crypt
> > >> _______________________________________________
> > >> dm-crypt mailing list
> > >> dm-crypt at saout.de
> > >> http://www.saout.de/mailman/listinfo/dm-crypt
> >
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt at saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
> 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 at saout.de
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20131127/4c41d4de/attachment-0001.html>


More information about the dm-crypt mailing list