system drive encryption question

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

system drive encryption question

FHDATA


hello,

I am not currently using debian as linux OS but
considering it ...


If I clean install debian (latest of course) and during
the install process have  its / (system drive)
encrypted with pass-phrase ....

then later on, can I add a key, residing on
a usb flash drive,  to that encryption?

if yes, is there a step-by-step method one can follow  to do that?



thank you,
F-


Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

tomas@tuxteam.de
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 05, 2017 at 05:31:38PM -0600, FHDATA wrote:

>
>
> hello,
>
> I am not currently using debian as linux OS but
> considering it ...
>
>
> If I clean install debian (latest of course) and during
> the install process have  its / (system drive)
> encrypted with pass-phrase ....
>
> then later on, can I add a key, residing on
> a usb flash drive,  to that encryption?

I assume the encryption will be LUKS based (the default here). LUKS
supports several key slots (8 if I remember correctly), and cryptsetup's
man page mentions a luksAddKey command, so it should be possible.

I haven't tried it myself yet, though.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljl5cwACgkQBcgs9XrR2kbgHgCfXHiAR6e20YFiQVF/GEsFFGFZ
JvIAmQG0rGx5bPXpPHZNbCYLniXw5yuO
=2wzk
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

Rick Thomas-14
In reply to this post by FHDATA
On Apr 5, 2017, at 4:31 PM, FHDATA <[hidden email]> wrote:

> hello,
>
> I am not currently using debian as linux OS but
> considering it ...
>
>
> If I clean install debian (latest of course) and during
> the install process have  its / (system drive)
> encrypted with pass-phrase ....
>
> then later on, can I add a key, residing on
> a usb flash drive,  to that encryption?
>
> if yes, is there a step-by-step method one can follow  to do that?
>
>
>
> thank you,
> F-

I used to do this.  It worked very well before Jessie came along.

You need an un-encrypted /boot partition to hold the kernel and initrd, of course…

With the introduction of systemd in Jessie, the mechanism that ran a script to get a password to decrypt the root disk[1] got broken.  I don’t think there was anything about systemd in particular that made it impossible, it just wasn’t at the top of the developer’s priority list to implement that feature.

I suspect it would not be difficult to implement such a feature again under recent systemd versions, but nobody’s done it yet — at least as far as I know.

If I take a stab at implementing such a feature, would you be interested in helping?

Enjoy!
Rick

[1] In my case the script looked for a USB drive with a given label, mounted it, read the key from a file it found there, then unmounted the USB drive so it could be removed by the sysop for safe-keeping until the next reboot.
Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

Rick Thomas-14

On Apr 6, 2017, at 3:18 AM, Rick Thomas <[hidden email]> wrote:

> I suspect it would not be difficult to implement such a feature again under recent systemd versions, but nobody’s done it yet — at least as far as I know.
>
> If I take a stab at implementing such a feature, would you be interested in helping?

Helpful reading for this effort:

    http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents

Enjoy!
Rick
Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

Nathanael Schweers-2
In reply to this post by Rick Thomas-14
Rick Thomas <[hidden email]> writes:
> I used to do this.  It worked very well before Jessie came along.
>
> You need an un-encrypted /boot partition to hold the kernel and
> initrd, of course…

This is not true, although I also thought it to be the case.

Grub2 can handle LUKS, so it is possible to encrypt the whole disk.

I recently stumbled across a post where the procedure is explained using
archlinux as an example.  I’m not sure whether debian includes a version
of Grub which can also do so, but in principle an unencrypted /boot
partition is not needed.

This is the post in question:
http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/

Regards,
Nathanael Schweers
Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

Frank Weißer-4
In reply to this post by FHDATA
Hi F-,

have a look at /etc/default/cryptdisks

> # Mountpoints to mount, before cryptsetup is invoked at initscripts. Takes
> # mountpoins which are configured in /etc/fstab as arguments. Separate
> # mountpoints by space.
> # This is useful for keyfiles on removable media. Default is unset.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I just tried it on a Fujitsu Lifebook E781, but i have LVM running and
get missing volume (containing the mountpath) :-(

No time for further testing now, so...
gould luck and kind regards

readU
Frank

FHDATA:

>
>
> hello,
>
> I am not currently using debian as linux OS but
> considering it ...
>
>
> If I clean install debian (latest of course) and during
> the install process have  its / (system drive)
> encrypted with pass-phrase ....
>
> then later on, can I add a key, residing on
> a usb flash drive,  to that encryption?
>
> if yes, is there a step-by-step method one can follow  to do that?
>
>
>
> thank you,
> F-
>
>

Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

Pascal Hambourg-2
In reply to this post by Nathanael Schweers-2
Le 06/04/2017 à 13:10, Nathanael Schweers a écrit :
> Rick Thomas <[hidden email]> writes:
>>
>> You need an un-encrypted /boot partition to hold the kernel and
>> initrd, of course…
>
> This is not true, although I also thought it to be the case.
>
> Grub2 can handle LUKS, so it is possible to encrypt the whole disk.

Actually not the whole disk (except if you are going to install GRUB's
boot/core images on another device, but the full /boot, including
/boot/grub, can be encrypted.

However my opinion is that encrypting /boot provides little benefit in
general. Here is why.

Encryption provides two main benefits : confidentiality and
tamper-proof. There is nothing confidential in /boot, but if
tamper-proof matters to you then all the boot components, including
GRUB's boot/core images, which cannot be encrypted, must be tamper-proof
too. This can be achieved by installing them on a write-only device, or
on a removable device used only for booting, or using some "trusted
computing" framework (UEFI secure boot, TPM module...).

> I recently stumbled across a post where the procedure is explained using
> archlinux as an example.  I’m not sure whether debian includes a version
> of Grub which can also do so, but in principle an unencrypted /boot
> partition is not needed.

The version of GRUB included in Jessie at least can handle an encrypted
/boot. However the Debian installer does not handle this case correctly.
You must add the following line in /etc/default/grub in order for
grub-install to install the core image with crypto modules and for
update-grub to generate a proper grub.cfg :

GRUB_ENABLE_CRYPTODISK=y

(not =1 or =true as seen on some documentation)

The procedure in the post you point to is flawed in Debian Jessie : if
you run update-grub or grub-mkconfig before adding the line in
/etc/default/grub, it won't add the required "cryptomount" commands to
open encrypted devices. Actually it is grub-mkconfig which is broken :
if the line is present, it adds an cryptomount command in every menu
entry, even when not needed (and generates boot-time errors). If the
line is missing, it adds insmod commands to load crypto modules when
needed but not the cryptomount commands.

Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

Nathanael Schweers-2
Pascal Hambourg <[hidden email]> writes:

> The version of GRUB included in Jessie at least can handle an encrypted
> /boot. However the Debian installer does not handle this case correctly.
> You must add the following line in /etc/default/grub in order for
> grub-install to install the core image with crypto modules and for
> update-grub to generate a proper grub.cfg :
>
> GRUB_ENABLE_CRYPTODISK=y
>
> (not =1 or =true as seen on some documentation)
>
> The procedure in the post you point to is flawed in Debian Jessie : if
> you run update-grub or grub-mkconfig before adding the line in
> /etc/default/grub, it won't add the required "cryptomount" commands to
> open encrypted devices. Actually it is grub-mkconfig which is broken :
> if the line is present, it adds an cryptomount command in every menu
> entry, even when not needed (and generates boot-time errors). If the
> line is missing, it adds insmod commands to load crypto modules when
> needed but not the cryptomount commands.

I never said that it works on debian.  I just wanted to point out that
it is not strictly necessary to have an unencrypted /boot partition.
Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

Pascal Hambourg-2
Le 10/04/2017 à 10:26, Nathanael Schweers a écrit :
> Pascal Hambourg <[hidden email]> writes:
>>
>> The procedure in the post you point to is flawed in Debian Jessie (...)
>
> I never said that it works on debian.

Don't misunderstand me : the procedure works with a minor adjustment, so
your information was valuable.

> I just wanted to point out that
> it is not strictly necessary to have an unencrypted /boot partition.

And I just wanted to point out that in most cases it is not very useful
to have an encrypted /boot.

Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

Jonathan Dowland
In reply to this post by Rick Thomas-14
On Thu, Apr 06, 2017 at 03:18:10AM -0700, Rick Thomas wrote:
> With the introduction of systemd in Jessie, the mechanism that ran a script
> to get a password to decrypt the root disk[1] got broken.  I don’t think
> there was anything about systemd in particular that made it impossible, it
> just wasn’t at the top of the developer’s priority list to implement that
> feature.

It works fine for me, now, with jessie and systemd. I use it to be able to
supply a decryption key via SSH when my headless NAS system reboots.

        https://jmtd.net/hardware/phobos/#index6h3
 

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: system drive encryption question

FHDATA
In reply to this post by FHDATA
On Wed, 5 Apr 2017, FHDATA wrote:

>
>
> hello,
>
> I am not currently using debian as linux OS but
> considering it ...
>
>
> If I clean install debian (latest of course) and during
> the install process have  its / (system drive)
> encrypted with pass-phrase ....
>
> then later on, can I add a key, residing on
> a usb flash drive,  to that encryption?
>
> if yes, is there a step-by-step method one can follow  to do that?
>
>
>
> thank you,
> F-
>
>
>


i apologize for not sending a timely response back;
just being busy;

thanks to all who provided feedback from
which  i learned:



   1. possibility of using a 3rd party 2fa solution (e.g. yubico)
      [relaying on internet during boot may be undesirable...]


   2. in LUKS  one of the other remaining 7  slots can be utilize for path
to encryption key ...


   3. system boot process looks for & mounts a external
usb device and use the key on it .....


   4. utilizing Password Agents ,Plymouth, (of systemd) to
prompt user for 'some passphrase for ---- '


   5. /etc/default/cryptdisks {seems to be a debian/ubuntu centric
thing, which is fine...}




#2 seems unlikely but i will investigate further.

combination of #3 + #4  looks promising ...

#5 seems to be tailored solution for this sort of things ...
but needs testing...


i like to keep things simple:
no /boot encryption, no LVM , RAID ,etc


someday every linux distro during the
install process will ask the user for
the 2nd auth factor residing on an external device.

till then i will do more reading & testing ...


F-