[dm-crypt] Integrate cryptsetup in bootloader

[dm-crypt] Integrate cryptsetup in bootloader

[Trinh Van Thanh]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

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​

[-- Attachment #2: Type: text/html, Size: 921 bytes --]

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Arno Wagner]

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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Tue, 2013-11-19 at 09:20 +0700, Trinh Van Thanh wrote:
> 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?

Integrating it in the bootloader doesn't really help you since then the
bootloader is the weak point.

In the end you'll always need an unencrypted kernel/initrd/bootloader...
so what one can do is booting from a USB stick,.. which you have always
with you... and then have a fully encrypted root-fs.


Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5165 bytes --]

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Ralf Ramsauer]

Hi,

just an idea, but shouldn't it be possible to implement encryption
algorithms incl. LUKS to GRUB?
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?
Signing your kernel and/or initrd could also prove the integrity and
authenticity of your system.

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@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Arno Wagner]

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@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Milan Broz]

On 11/19/2013 03:20 AM, 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?

FYI GRUB2 has some LUKS support already integrated, you can try it...
It is reimplementation, just some code was copied from cryptsetup.
See e.g. Gentoo wiki
http://wiki.gentoo.org/wiki/GRUB2#Booting_from_LUKS_Physical_Volume

But I think not many people using it, initramfs with boot partition
is most common.

Milan

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Ralf Ramsauer]

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.

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.

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

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.

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@saout.de
>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Sven Eschenberg]

Aside from the fact that grub2 does actually support loading the kernel
from an encrypted disk, you could still sign your grub executeable for
secure boot.

Then again, can we really trust SecureBoot and the UEFI firmware not being
tampered with - that will most probably be the major question on modern
systems.

Regards

-Sven


On Tue, November 19, 2013 05:20, 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.
>
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Ralf Ramsauer]

On 11/20/2013 12:28 AM, Sven Eschenberg wrote:
> Aside from the fact that grub2 does actually support loading the kernel
> from an encrypted disk, you could still sign your grub executeable for
> secure boot.
And who will verify authenticity?
And where do you want to store the public key for verification?
>
> Then again, can we really trust SecureBoot and the UEFI firmware not being
> tampered with - that will most probably be the major question on modern
> systems.
Absolutely. But nevertheless, you always will have to trust a certain
part of your system.

Regards,
  Ralf
>
> Regards
>
> -Sven
>
>
> On Tue, November 19, 2013 05:20, 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.
>>
>> --
>> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Sven Eschenberg]

What autheticity? grub's?

The key will be stored by the firmware the same way the keys delivered
with it are stored, most probably. That's why I said, you'd have to trust
the firmware and that it can not easily be tampered with.

I wanted to point out, that an attack on the bootloader itself is not
really the problem here, as you can sign it and use secure boot.

But in turn we'd have to trust secure boot and the security of the
firmware in general.

It is probably way easier though to manipulate the bootloader executeable,
as Arno pointed out, than using a JTAGGer and modify the firmware.

Regards

-Sven


On Wed, November 20, 2013 01:28, Ralf Ramsauer wrote:
> On 11/20/2013 12:28 AM, Sven Eschenberg wrote:
>> Aside from the fact that grub2 does actually support loading the kernel
>> from an encrypted disk, you could still sign your grub executeable for
>> secure boot.
> And who will verify authenticity?
> And where do you want to store the public key for verification?
>>
>> Then again, can we really trust SecureBoot and the UEFI firmware not
>> being
>> tampered with - that will most probably be the major question on modern
>> systems.
> Absolutely. But nevertheless, you always will have to trust a certain
> part of your system.
>
> Regards,
>   Ralf
>>
>> Regards
>>
>> -Sven
>>
>>
>> On Tue, November 19, 2013 05:20, 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.
>>>
>>> --
>>> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
>>> arno@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@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Alex Elsayed]

Christoph Anton Mitterer wrote:

> On Tue, 2013-11-19 at 09:20 +0700, Trinh Van Thanh wrote:
>> 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?
> 
> Integrating it in the bootloader doesn't really help you since then the
> bootloader is the weak point.
> 
> In the end you'll always need an unencrypted kernel/initrd/bootloader...
> so what one can do is booting from a USB stick,.. which you have always
> with you... and then have a fully encrypted root-fs.

Integrating with the bootloader isn't a _solution_, but it is a 
_mitigation_.

If you're using GRUB2 in a traditional (non-EFI) boot configuration, you can 
get away with leaving VERY little space for an attacker to work in. In 
particular, the space before the protective MBR (which is filled by grub's 
core, and not especially useful to tamper with) and the BIOS Boot Partition 
it uses to store the more full image (EF02 in gdisk).

By creating a truly minimal grub image (cryptdisk, your boot filesystem 
driver, the linux loader, maybe a couple other things) in which every part 
is necessary to the boot process, and placing the BBP at the end of the 
disk, you can force the partition to be the exact minimal size that will 
hold that data by resizing the LUKS partition.

That way, tampering in a manner that WON'T cause the boot process to fail 
entirely becomes exceedingly difficult, and something with sufficient 
complexity to patch the kernel becomes prohibitive.

I used to use GRUB2's cryptdisk support for a while, and while it was tetchy 
to work with it does function - if one is familiar with GRUB2's scripting 
syntax, coreboot's (very) brief overview is sufficient:

http://www.coreboot.org/GRUB2#LUKS_disks_openning

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Alex Elsayed]

Whoops - forgot to make clear that this assumes GPT partitioning despite 
using a traditional boot process, and that the only two partitions are the 
LUKS partition and the BIOS Backup Partition. That's essentially what my 
setup was when I used GRUB2's encryption support, although I didn't take the 
minimization steps described.

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Alex Elsayed]

Sven Eschenberg wrote:

> What autheticity? grub's?
> 
> The key will be stored by the firmware the same way the keys delivered
> with it are stored, most probably. That's why I said, you'd have to trust
> the firmware and that it can not easily be tampered with.
> 
> I wanted to point out, that an attack on the bootloader itself is not
> really the problem here, as you can sign it and use secure boot.
> 
> But in turn we'd have to trust secure boot and the security of the
> firmware in general.
> 
> It is probably way easier though to manipulate the bootloader executeable,
> as Arno pointed out, than using a JTAGGer and modify the firmware.

Well, there are two concerns there, and the difficulty of using a JTAG 
debugger only addresses one.

The other issue is that while GRUB2 is open-source and can be inspected for 
backdoors, the same is not generally true of firmware.

Trinh, if you have the resources you may want to look into Coreboot with a 
signed (and verification-capable) U-Boot payload. That's what ChromeOS is 
using (although their U-Boot verification differs from and predates what 
went upstream), and provides a similar trust chain to Secure Boot using 
open-source components. That will restrict what hardware you can use, but if 
your use-case requires that kind of security it may be worth considering.

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Arno Wagner]

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@saout.de
> >>>> http://www.saout.de/mailman/listinfo/dm-crypt
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Trinh Van Thanh]

[-- Attachment #1: Type: text/plain, Size: 8017 bytes --]

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@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@saout.de
> > >>>> http://www.saout.de/mailman/listinfo/dm-crypt
> > >> _______________________________________________
> > >> dm-crypt mailing list
> > >> dm-crypt@saout.de
> > >> http://www.saout.de/mailman/listinfo/dm-crypt
> >
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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@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.

[-- Attachment #2: Type: text/html, Size: 10765 bytes --]

Re: [dm-crypt] Integrate cryptsetup in bootloader

[Ralf Ramsauer]

[-- Attachment #1: Type: text/plain, Size: 9510 bytes --]

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@wagner.name
> <mailto:arno@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@saout.de <mailto:dm-crypt@saout.de>
>     > >>>> http://www.saout.de/mailman/listinfo/dm-crypt
>     > >> _______________________________________________
>     > >> dm-crypt mailing list
>     > >> dm-crypt@saout.de <mailto:dm-crypt@saout.de>
>     > >> http://www.saout.de/mailman/listinfo/dm-crypt
>     >
>     > _______________________________________________
>     > dm-crypt mailing list
>     > dm-crypt@saout.de <mailto:dm-crypt@saout.de>
>     > http://www.saout.de/mailman/listinfo/dm-crypt
>
>     --
>     Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
>     arno@wagner.name <mailto:arno@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@saout.de <mailto:dm-crypt@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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


[-- Attachment #2: Type: text/html, Size: 16517 bytes --]