[dm-crypt] Integrate cryptsetup in bootloader

Ralf Ramsauer ralf+dm at ramses-pyramidenbau.de
Wed Nov 27 14:45:08 CET 2013


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 at wagner.name
> <mailto: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 <mailto:dm-crypt at saout.de>
>     > >>>> http://www.saout.de/mailman/listinfo/dm-crypt
>     > >> _______________________________________________
>     > >> dm-crypt mailing list
>     > >> dm-crypt at saout.de <mailto:dm-crypt at saout.de>
>     > >> http://www.saout.de/mailman/listinfo/dm-crypt
>     >
>     > _______________________________________________
>     > dm-crypt mailing list
>     > dm-crypt at saout.de <mailto: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 <mailto: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 <mailto:dm-crypt at saout.de>
>     http://www.saout.de/mailman/listinfo/dm-crypt
>
>
>
>
> -- 
> *Tri.nh Va(n Thành*
>
> Add: No.5, 64/25 Lane, Phan Dinh Giot Street, Thanh Xuan Dist, Hanoi.
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20131127/b07a7d2b/attachment.html>


More information about the dm-crypt mailing list