Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #219418 > unrolled thread

Encrypted /boot password has to be entered twice

Back to article view | Back to linux.debian.user

Contents

  Encrypted /boot password has to be entered twice john doe <johndoe65534@mail.com> - 2020-02-25 11:40 +0100
    Re: Encrypted /boot password has to be entered twice Steve McIntyre <steve@einval.com> - 2020-02-25 18:40 +0100
      Re: Encrypted /boot password has to be entered twice Matthew Moore <a91738246@gmail.com> - 2020-02-25 20:00 +0100
        Re: Encrypted /boot password has to be entered twice john doe <johndoe65534@mail.com> - 2020-02-26 07:40 +0100
          Re: Encrypted /boot password has to be entered twice Guilhem Moulin <guilhem@debian.org> - 2020-02-26 16:10 +0100
            Re: Encrypted /boot password has to be entered twice john doe <johndoe65534@mail.com> - 2020-02-26 20:10 +0100
              Re: Encrypted /boot password has to be entered twice Guilhem Moulin <guilhem@debian.org> - 2020-02-27 01:30 +0100
                Re: Encrypted /boot password has to be entered twice john doe <johndoe65534@mail.com> - 2020-02-28 08:50 +0100

#219418 — Encrypted /boot password has to be entered twice

Hi all, when encrypting /boot on Buster after a fresh install of Debian
with encrypted lvm, I need to enter three times a passthrase (two times
foor /boot, one time foor /root)

"...

GRUB loading..
Welcome to GRUB!

Attempting to decrypt master key...
Enter passphrase for hd0,msdos1 (...):
Slot 0 opened

..

                            GNU GRUB  version 2.04-5

   The highlighted entry will be executed automatically in 0s.

...

  Booting `Debian GNU/Linux'

  Volume group "debian-bustervm-vg" not found
  Cannot process volume group debian-bustervm-vg
  Volume group "debian-bustervm-vg" not found
  Cannot process volume group debian-bustervm-vg
Please unlock disk sda5_crypt:
cryptsetup: sda5_crypt: set up successfully
/dev/mapper/debian--buster--try02vm--vg-root: clean, 38666/507904 files,
434177s
Please enter passphrase for disk QEMU_HARDDISK (boot_crypt): ***"

I don't understand why after boot is encrypted the above passthrase
prompt ask me to enter this passthrase for the second time for the boot
partition.
Why is that so and how can I avoid this extra step?

I'm testing here in a qemu VM.

I use (1) to encrypt  the boot partition.

1)  https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

--
John Doe

[toc] | [next] | [standalone]

#219429

John Doe wrote:
>Hi all, when encrypting /boot on Buster after a fresh install of Debian
>with encrypted lvm, I need to enter three times a passthrase (two times
>foor /boot, one time foor /root)
>
>"...
>
>GRUB loading..
>Welcome to GRUB!
>
>Attempting to decrypt master key...
>Enter passphrase for hd0,msdos1 (...):
>Slot 0 opened
>
>..
>
>                            GNU GRUB  version 2.04-5
>
>   The highlighted entry will be executed automatically in 0s.
>
>...
>
>  Booting `Debian GNU/Linux'
>
>  Volume group "debian-bustervm-vg" not found
>  Cannot process volume group debian-bustervm-vg
>  Volume group "debian-bustervm-vg" not found
>  Cannot process volume group debian-bustervm-vg
>Please unlock disk sda5_crypt:
>cryptsetup: sda5_crypt: set up successfully
>/dev/mapper/debian--buster--try02vm--vg-root: clean, 38666/507904 files,
>434177s
>Please enter passphrase for disk QEMU_HARDDISK (boot_crypt): ***"
>
>I don't understand why after boot is encrypted the above passthrase
>prompt ask me to enter this passthrase for the second time for the boot
>partition.
>Why is that so and how can I avoid this extra step?
>
>I'm testing here in a qemu VM.
>
>I use (1) to encrypt  the boot partition.
>
>1)  https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

Grub needs the passphrase for /boot, and then Linux needs it
separately. Unfortunately there isn't a way for Grub to pass the
passphrase to Linux so it has to ask you again. People are looking at
ways to make this work better...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

[toc] | [prev] | [next] | [standalone]

#219435

On Tue 2020-02-25 17:31, Steve McIntyre wrote:
> Grub needs the passphrase for /boot, and then Linux needs it
> separately. Unfortunately there isn't a way for Grub to pass the
> passphrase to Linux so it has to ask you again. People are looking at
> ways to make this work better...

One way to do this is to use both a passphrase and a keyfile. You use the
passphrase with grub to decrypt things, then configure the initramfs to hold the
keyfile (both located on the drive) and use it for mounting grub. The net effect
is to only have the password prompt once. Here's what to do:

* Generate the keyfile (call it /keyfile) and add it to you device.

* Add this to /etc/crypttab:

-- /etc/crypttab ---------------------------------------------------------------
root  UUID=<your uuid>  /keyfile  luks
--------------------------------------------------------------------------------

* Install cryptsetup-initramfs and add/edit this line:

-- /etc/cryptsetup-initramfs/conf-hook -----------------------------------------
KEYFILE_PATTERN=/keyfile
--------------------------------------------------------------------------------

* The keyfile should be protected and is stored, so give it a more restrictive
  umask by adding/editing the line

-- /etc/initramfs-tools/initramfs.conf -----------------------------------------
UMASK=0077
--------------------------------------------------------------------------------

* Update /etc/default/grub.

-- /etc/default/grub -----------------------------------------------------------{{{}}}
GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX="cryptdevice=/dev/<your partition>"
--------------------------------------------------------------------------------

* Rebuild the initramfs, update grub:

  $ update-initramfs -k all -u
  $ update-grub


BTW, grub's verification of the passphrase is *slow*. You can speed things up at
the cost of some security by adjusting the --iter-time parameter. I have found
that --iter-time=1000 is fast enough on newer machines.

Hope this helps,
MM

[toc] | [prev] | [next] | [standalone]

#219452

On 2/25/2020 7:48 PM, Matthew Moore wrote:
>
> On Tue 2020-02-25 17:31, Steve McIntyre wrote:
>> Grub needs the passphrase for /boot, and then Linux needs it
>> separately. Unfortunately there isn't a way for Grub to pass the
>> passphrase to Linux so it has to ask you again. People are looking at
>> ways to make this work better...
>
> One way to do this is to use both a passphrase and a keyfile. You use the
> passphrase with grub to decrypt things, then configure the initramfs to hold the
> keyfile (both located on the drive) and use it for mounting grub. The net effect
> is to only have the password prompt once. Here's what to do:
>
> * Generate the keyfile (call it /keyfile) and add it to you device.
>
> * Add this to /etc/crypttab:
>
> -- /etc/crypttab ---------------------------------------------------------------
> root  UUID=<your uuid>  /keyfile  luks
> --------------------------------------------------------------------------------
>
> * Install cryptsetup-initramfs and add/edit this line:
>
> -- /etc/cryptsetup-initramfs/conf-hook -----------------------------------------
> KEYFILE_PATTERN=/keyfile
> --------------------------------------------------------------------------------
>
> * The keyfile should be protected and is stored, so give it a more restrictive
>   umask by adding/editing the line
>
> -- /etc/initramfs-tools/initramfs.conf -----------------------------------------
> UMASK=0077
> --------------------------------------------------------------------------------
>
> * Update /etc/default/grub.
>
> -- /etc/default/grub -----------------------------------------------------------{{{}}}
> GRUB_ENABLE_CRYPTODISK=y
> GRUB_CMDLINE_LINUX="cryptdevice=/dev/<your partition>"
> --------------------------------------------------------------------------------
>
> * Rebuild the initramfs, update grub:
>
>   $ update-initramfs -k all -u
>   $ update-grub
>
>

"Booting from Hard Disk...
Attempting to decrypt master key...
Enter passphrase for hd0,msdos1 ():
Slot 0 opened"

I need to enter the password here for the first time.

"                        GNU GRUB  version 2.02+dfsg1-20

cryptsetup: sda5_crypt: set up successfully"

With key file, I don't need to enter the password for the root device.

"/dev/mapper/debian--bustervm--vg-root: recovering journal
/dev/mapper/debian--bustervm--vg-root: clean, 31578/507904 files, 287395s
Please enter passphrase for disk QEMU_HARDDISK (sda1_crypt):"

But here, I need to reenter the password for a second time.


According to "Steve McIntyre <steve@einval.com>" and I thanks him for
his answer, for the time being, the passphrase for the boot device has
to be provided twice (one for grub and one for linux).


To "Matthew Moore <a91738246@gmail.com>" and thanks for your answer:

For now, I did that per instructions at (1), As far as I understanded,
your instructions will give me the same result as what is described at (1)?

I'm just starting here, so any input is welcome.

I'm also adding the e-mail contact found at (1) and thanks "Guilhem
Moulin <guilhem@debian.org>" for his direct help.

1)
https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html#avoiding-the-extra-password-prompt

--
John Doe

[toc] | [prev] | [next] | [standalone]

#219480

[Multipart message — attachments visible in raw view] — view raw

Hi there,

On Wed, 26 Feb 2020 at 07:37:33 +0100, john doe wrote:
> But here, I need to reenter the password for a second time.
> […]
> I'm just starting here, so any input is welcome.

Let me try to rephrase what I wrote already in private.  The document
you linked to (which I wrote and which is included to src:cryptsetup)
does say that you devices holding / and /boot need to be unlocked again:

    “The device holding the kernel (and the initramfs image) is unlocked
    by GRUB, but the root device needs to be unlocked again at initramfs
    stage, regardless whether it’s the same device or not. This is
    because GRUB boots with the given vmlinuz and initramfs images, but
    there is currently no way to securely pass cryptographic material
    (or Device Mapper information) to the kernel. Hence the Device
    Mapper table is initially empty at initramfs stage; in other words,
    all devices are locked, and the root device needs to be unlocked
    again.”

So passed GRUB, all devices are locked.  The one(s) holding the root
file system, /usr (and swap if suspend-to-disk is enabled) needs to be
unlocked at initramfs stage, while other crypttab(5) entries are
processed later by the “normal” system.  This is why systemd asks you to
unlock the device holding /boot here:

> "/dev/mapper/debian--bustervm--vg-root: recovering journal
> /dev/mapper/debian--bustervm--vg-root: clean, 31578/507904 files, 287395s
> Please enter passphrase for disk QEMU_HARDDISK (sda1_crypt):"

There are 3 distinct stages:

 1. At GRUB stage, you unlock the (LUKS1) device holding the kernel (and
    the initramfs image), i.e., /boot.
 
 2. At initramfs stage, the system has access to the content initramfs
    image (which itself lives in the encrypted /boot), but the Device
    Mapper table is initially empty so device(s) holding the rootfs and
    /usr need to be unlocked and mounted before execution can be turned
    over to the “real” init(1) binary.
    One can unlock via key files to avoid the interactive passphrase
    prompt(s).  These keys files however need to be copied to the
    initramfs image as its content is the only thing available at
    initramfs stage.  (Unless you want to use an external token and/or
    activate the network stack.)

 3. At “normal” stage, the system will take care of unlocking remaining
    crypttab(5) entries, i.e., for devices that weren't required to be
    unlocked at stage #2 (for instance for devices holding /boot, /var,
    /sys, etc.).
    Again, one can unlock via key files to avoid the interactive
    passphrase prompt(s).  At that point the rootfs is mounted, so
    keyfiles can be dropped there, and don't need to be copied anywhere
    else.

Only device(s) unlocked at stage #1 need to comply with GRUB's
limitations: LUKS1 only (although there is an upstream patch for LUKS2
now), limited RAM, limited cipher selection, etc.  On the other hand
device(s) unlocked at stage #2 and #3 are processed by libcryptsetup, so
one can use any feature available there, including LUKS2 on-disk format,
use of kernel keyring tokens, authenticated encryption, etc.  If you use
LUKS2 and offload the volume to the kernel keyring though, please bear
in mind that key files lying on disk are readable by userspace, so the
threat model changes slightly.

In practice, if you go for key files, the following crypttab(5) snippet
should work with your setup, assuming /dev/sda1 is a LUKS1 device
holding /boot and /dev/sda2 is a LUKS1/LUKS2 device holding / (possibly
with a Logical Volume in between).

    sda1_crypt /dev/sda1 /etc/keys/boot.key luks,key-slot=1
    sda2_crypt /dev/sda2 /etc/keys/root.key luks

(See the note about key slots in the document you linked.)  And for
/etc/cryptsetup-initramfs/conf-hook:

    KEYFILE_PATTERN="/etc/keys/root.key"

So 1. at GRUB stage you unlock /dev/sda1 interactively; 2. at initramfs
stage /dev/sda2 is unlocked non-interactively using the key file copied
to the initramfs image from /etc/keys/root.key; 3. later systemd unlocks
/dev/sda1 non-interactively using the key file /etc/keys/boot.key.

I'll see if I can clarify the document.

Hope this helps,
cheers
-- 
Guilhem.

PS. Not subscribed to debian-user

[toc] | [prev] | [next] | [standalone]

#219491

On 2/26/2020 3:54 PM, Guilhem Moulin wrote:
> Hi there,
>
> On Wed, 26 Feb 2020 at 07:37:33 +0100, john doe wrote:
>> But here, I need to reenter the password for a second time.
>> […]
>> I'm just starting here, so any input is welcome.
>
> Let me try to rephrase what I wrote already in private.  The document
> you linked to (which I wrote and which is included to src:cryptsetup)
> does say that you devices holding / and /boot need to be unlocked again:
>
>     “The device holding the kernel (and the initramfs image) is unlocked
>     by GRUB, but the root device needs to be unlocked again at initramfs
>     stage, regardless whether it’s the same device or not. This is
>     because GRUB boots with the given vmlinuz and initramfs images, but
>     there is currently no way to securely pass cryptographic material
>     (or Device Mapper information) to the kernel. Hence the Device
>     Mapper table is initially empty at initramfs stage; in other words,
>     all devices are locked, and the root device needs to be unlocked
>     again.”
>
> So passed GRUB, all devices are locked.  The one(s) holding the root
> file system, /usr (and swap if suspend-to-disk is enabled) needs to be
> unlocked at initramfs stage, while other crypttab(5) entries are
> processed later by the “normal” system.  This is why systemd asks you to
> unlock the device holding /boot here:
>
>> "/dev/mapper/debian--bustervm--vg-root: recovering journal
>> /dev/mapper/debian--bustervm--vg-root: clean, 31578/507904 files, 287395s
>> Please enter passphrase for disk QEMU_HARDDISK (sda1_crypt):"
>
> There are 3 distinct stages:
>
>  1. At GRUB stage, you unlock the (LUKS1) device holding the kernel (and
>     the initramfs image), i.e., /boot.
>
>  2. At initramfs stage, the system has access to the content initramfs
>     image (which itself lives in the encrypted /boot), but the Device
>     Mapper table is initially empty so device(s) holding the rootfs and
>     /usr need to be unlocked and mounted before execution can be turned
>     over to the “real” init(1) binary.
>     One can unlock via key files to avoid the interactive passphrase
>     prompt(s).  These keys files however need to be copied to the
>     initramfs image as its content is the only thing available at
>     initramfs stage.  (Unless you want to use an external token and/or
>     activate the network stack.)
>
>  3. At “normal” stage, the system will take care of unlocking remaining
>     crypttab(5) entries, i.e., for devices that weren't required to be
>     unlocked at stage #2 (for instance for devices holding /boot, /var,
>     /sys, etc.).
>     Again, one can unlock via key files to avoid the interactive
>     passphrase prompt(s).  At that point the rootfs is mounted, so
>     keyfiles can be dropped there, and don't need to be copied anywhere
>     else.
>
> Only device(s) unlocked at stage #1 need to comply with GRUB's
> limitations: LUKS1 only (although there is an upstream patch for LUKS2
> now), limited RAM, limited cipher selection, etc.  On the other hand
> device(s) unlocked at stage #2 and #3 are processed by libcryptsetup, so
> one can use any feature available there, including LUKS2 on-disk format,
> use of kernel keyring tokens, authenticated encryption, etc.  If you use
> LUKS2 and offload the volume to the kernel keyring though, please bear
> in mind that key files lying on disk are readable by userspace, so the
> threat model changes slightly.
>
> In practice, if you go for key files, the following crypttab(5) snippet
> should work with your setup, assuming /dev/sda1 is a LUKS1 device
> holding /boot and /dev/sda2 is a LUKS1/LUKS2 device holding / (possibly
> with a Logical Volume in between).
>
>     sda1_crypt /dev/sda1 /etc/keys/boot.key luks,key-slot=1
>     sda2_crypt /dev/sda2 /etc/keys/root.key luks
>
> (See the note about key slots in the document you linked.)  And for
> /etc/cryptsetup-initramfs/conf-hook:
>
>     KEYFILE_PATTERN="/etc/keys/root.key"
>
> So 1. at GRUB stage you unlock /dev/sda1 interactively; 2. at initramfs
> stage /dev/sda2 is unlocked non-interactively using the key file copied
> to the initramfs image from /etc/keys/root.key; 3. later systemd unlocks
> /dev/sda1 non-interactively using the key file /etc/keys/boot.key.
>
> I'll see if I can clarify the document.
>
> Hope this helps,

It does clearly helps!

$ systemctl status systemd-cryptsetup@sda1_crypt | cut -d " " -f 5-
systemd-cryptsetup[352]: Failed to activate with key file
'/etc/keys/boot.key': No such file or directory


I don't understand why I get this error, the file is there and generated
as suggested  for 'root.key'.


Any thoughts?

I realy appriciate you walking me through this process.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#219511

[Multipart message — attachments visible in raw view] — view raw

On Wed, 26 Feb 2020 at 19:59:33 +0100, john doe wrote:
> I don't understand why I get this error, the file is there

Did you triple-check that? :-)  `sudo cryptdisks_start sda1_crypt` will
do the checking logic for you, but you can also run the cryptsetup(8)
binary manually:

    $ sudo cryptsetup luksOpen --key-file /etc/keys/boot.key --key-slot 1 \
        --test-passphrase --verbose /dev/sda1 sda1_crypt

If it that doesn't work, then no wonder systemd-cryptsetup@sda1_crypt
fails :-)  Is the key file really used on key slot #1?  (If you're
unsure, just remove ‘--key-slot 1’ from the above command, it'll tell
you the index of the right keyslot, assuming it can open with that key
file.)

Otherwise, do you perhaps have /etc in a separate partition which is not
mounted yet by the time systems tries to unlock the device?  That said
systemd should be clever enough to setup the correct .mount dependencies
on that unit.

-- 
Guilhem.

PS. Not subscribed to debian-user

[toc] | [prev] | [next] | [standalone]

#219600

On 2/27/2020 1:25 AM, Guilhem Moulin wrote:
> On Wed, 26 Feb 2020 at 19:59:33 +0100, john doe wrote:
>> I don't understand why I get this error, the file is there
>
> Did you triple-check that? :-)  `sudo cryptdisks_start sda1_crypt` will
> do the checking logic for you, but you can also run the cryptsetup(8)
> binary manually:
>
>     $ sudo cryptsetup luksOpen --key-file /etc/keys/boot.key --key-slot 1 \
>         --test-passphrase --verbose /dev/sda1 sda1_crypt
>

The keyfile was present but not "added".

> If it that doesn't work, then no wonder systemd-cryptsetup@sda1_crypt
> fails :-)  Is the key file really used on key slot #1?  (If you're
> unsure, just remove ‘--key-slot 1’ from the above command, it'll tell
> you the index of the right keyslot, assuming it can open with that key
> file.)
>
> Otherwise, do you perhaps have /etc in a separate partition which is not
> mounted yet by the time systems tries to unlock the device?  That said
> systemd should be clever enough to setup the correct .mount dependencies
> on that unit.
>

I'm pasting here the commands that got me going to only enter the boot
passphrase once, that is, you only get prompted one time for a password:


Debian Buster was installed with encrypted LVM in one partition.


Commands to encrypt the boot partition:

mount -oremount,ro /boot || exit $?
install -m0600 /dev/null /tmp/boot.tar || exit $?
tar -C /boot --acls --xattrs --one-file-system -cf /tmp/boot.tar . ||
exit $?
umount /boot || exit $?
dd if=/dev/urandom of=/dev/sda1 bs=1M status=none
cryptsetup luksFormat --type luks1 /dev/sda1 || exit $?
uuid="$(blkid -o value -s UUID /dev/sda1)" || exit $?
echo "sda1_crypt UUID=$uuid none luks" | tee -a /etc/crypttab || exit $?
cryptdisks_start sda1_crypt || exit $?
uuid=$(awk '/UUID/ && /\/boot/{print substr($1,6)}' /etc/fstab) || exit $?
mkfs.ext2 -m0 -U $uuid /dev/mapper/sda1_crypt || exit $?
mount -v /boot || exit $?
tar -C /boot --acls --xattrs -xf /tmp/boot.tar || exit $?
echo "GRUB_ENABLE_CRYPTODISK=y" >>/etc/default/grub || exit $?
update-grub || exit $?
grub-install /dev/sda || exit $?


Commands to use a keyfile for the root partition:

mkdir -m 0700 /etc/keys || exit $?
( umask 0077 && dd if=/dev/urandom bs=1 count=64 of=/etc/keys/root.key
conv=excl,fsync ) || exit $?
cryptsetup luksAddKey /dev/sda5 /etc/keys/root.key || exit $?
sed -i '/sda5_crypt/s/none/\/etc\/keys\/root.key/' /etc/crypttab || exit $?
chmod 0644 /etc/crypttab || exit $?
echo "KEYFILE_PATTERN=\"/etc/keys/root.key\""
>>/etc/cryptsetup-initramfs/conf-hook || exit $?
echo UMASK=0077 >>/etc/initramfs-tools/initramfs.conf || exit $?
update-initramfs -u || exit $?


Commands to use a keyfile for the boot partition:

( umask 0077 && dd if=/dev/urandom bs=1 count=64 of=/etc/keys/boot.key
conv=excl,fsync ) || exit $?
cryptsetup luksAddKey /dev/sda1 /etc/keys/boot.key --key-slot=1 || exit $?
sed -i
'/sda1_crypt/s/none/\/etc\/keys\/boot.key/;/sda1_crypt/s/luks/key-slot=1/'
/etc/crypttab || exit $?
chmod 0644 /etc/crypttab || exit $?


The above commands are taken from a script, '|| exit $?' will abort on
any commands failure, that might not be what you want if the commands
are entered manually.


The commands are taken from (1).

A big thank you to 'Guilhem Moulin <guilhem@debian.org>' for his help
and to the others who has contributed in this thread.


This e-mail is folded by my mailer.


1)  https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

--
John Doe

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web