[dm-crypt] Using a removable-device-recorded passphrase to decrypt a system

[dm-crypt] Using a removable-device-recorded passphrase to decrypt a system

[Arbiel (gmx)]

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

Hi

I decided to use a 512-byte randomly generated passphrase to crypt my
system partition. I recorded this passphrase on a removable device (USB
key) and correctly wrote the crypttab and fstab files and updated my
initrd.img for all this to work.

I am anxious now to replicate my passphrase on additionnal USB keys, in
case my primary USB key get lost or damaged.

For some reasons, I cannot name all partitions where my passphrase will
be recorded with a unique label.

I tried to write several lines in the crypttab file for defining as many
passphrase locations as necessary such as
root UUID=uuid /dev/disk/by-label/USBkey1/passphrase:x
luks,keyscript=/lib/cryptsetup/scripts/passdev
root UUID=uuid /dev/disk/by-label/USBkey2/passphrase:x
luks,keyscript=/lib/cryptsetup/scripts/passdev
and so on, but this does not work.

I thank in advance anybody who can advise me on how to solve this issue.

Arbiel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [dm-crypt] Using a removable-device-recorded passphrase to decrypt a system

[Arno Wagner]

Hi Arbiel,

I think you have some misunderstanding here: crypttab does 
not work for encrypted system, as it is on that encrypted system 
itself (catch-22). 

In order to have an encrypted system partition, you need some 
mechanism in the initrd to read your passphrase. What form that 
mechanism takes depends on the distribution you are using.

My advice is to not encrypt the system partition itself, just
all user and data partitions. An "evil Maid" attacker can get
into your boot process anyways. Disk encryption really only 
protects against encrypted devices being stolen while not 
mapped (machine is off, e.g.).

Gr"usse,
Arno




On Thu, Jun 25, 2015 at 16:57:33 CEST, Arbiel (gmx) wrote:
> Hi
> 
> I decided to use a 512-byte randomly generated passphrase to crypt my
> system partition. I recorded this passphrase on a removable device (USB
> key) and correctly wrote the crypttab and fstab files and updated my
> initrd.img for all this to work.
> 
> I am anxious now to replicate my passphrase on additionnal USB keys, in
> case my primary USB key get lost or damaged.
> 
> For some reasons, I cannot name all partitions where my passphrase will
> be recorded with a unique label.
> 
> I tried to write several lines in the crypttab file for defining as many
> passphrase locations as necessary such as
> root UUID=uuid /dev/disk/by-label/USBkey1/passphrase:x
> luks,keyscript=/lib/cryptsetup/scripts/passdev
> root UUID=uuid /dev/disk/by-label/USBkey2/passphrase:x
> luks,keyscript=/lib/cryptsetup/scripts/passdev
> and so on, but this does not work.
> 
> I thank in advance anybody who can advise me on how to solve this issue.
> 
> Arbiel
> 



> _______________________________________________
> 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
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Using a removable-device-recorded passphrase to decrypt a system

[Heinz Diehl]

On 26.06.2015, Arno Wagner wrote: 

> My advice is to not encrypt the system partition itself, just
> all user and data partitions.

I wonder if the passphrase could leak to the unencrypted system partition in such
a scenario. E.g. memory contents dumped to disk while crashing or
similar. In fact, I don't know what is possible or not, I'm just
curious..

Re: [dm-crypt] Using a removable-device-recorded passphrase to decrypt a system

[Arno Wagner]

Hi Heinz,

I doubt it. It is a valid question, bit also one any halfway
competent implementor of crypto on Linux has to ask themselves.

Without verifying what is actually done (Milan is the expert for 
that), I assume:

- Passphrases get stored only in locked memory and that does
  not get swapped. (Root permissions are needed anyways for
  setting up any mapping. E.g. GnuPG has a harder job here
  as it does not necessarily run as root. AFAIK it uses a
  suid second stage exactly for the purpose of having locked
  memory.)
- Passphrases are wiped from memory as soon as possible.
- I have no idea whether locked memory can end up in a 
  core-dump, but usually these are disabled anyways.
- In-kernel keys are protected against leaking to disk.

The thing is, system encryption is not easy to do and conceptually
does not help a lot. If it was necessary to prevent having
passphrases/keys to disk, that would be a major security flaw
in the handling of said passphrases/keys and it would affect 
other things as well, like GnuPG, OpenSSL, etc. and so I hope
somebody would have complained by now if that was a real issue.

Gr"usse,
Arno


On Fri, Jun 26, 2015 at 14:59:18 CEST, Heinz Diehl wrote:
> On 26.06.2015, Arno Wagner wrote: 
> 
> > My advice is to not encrypt the system partition itself, just
> > all user and data partitions.
> 
> I wonder if the passphrase could leak to the unencrypted system partition in such
> a scenario. E.g. memory contents dumped to disk while crashing or
> similar. In fact, I don't know what is possible or not, I'm just
> curious..
> 
> 
> _______________________________________________
> 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
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Using a removable-device-recorded passphrase to decrypt a system

[Sven Eschenberg]

On Fri, June 26, 2015 15:19, Arno Wagner wrote:
> Hi Heinz,
>
> I doubt it. It is a valid question, bit also one any halfway
> competent implementor of crypto on Linux has to ask themselves.
>
> Without verifying what is actually done (Milan is the expert for
> that), I assume:
>
> - Passphrases get stored only in locked memory and that does
>   not get swapped. (Root permissions are needed anyways for
>   setting up any mapping. E.g. GnuPG has a harder job here
>   as it does not necessarily run as root. AFAIK it uses a
>   suid second stage exactly for the purpose of having locked
>   memory.)

cryptsetup indeed mlocks() the whole process' memory as soon as possible
including all future pages. That should even include all pages from all
forked proceses IIRC.

> - Passphrases are wiped from memory as soon as possible.
> - I have no idea whether locked memory can end up in a
>   core-dump, but usually these are disabled anyways.

There certainly is a debug option to get coredumps including locked pages,
I presume.

> - In-kernel keys are protected against leaking to disk.

Again, I presume, since I did not check the kernel's source, that the
relevant kernel pages are marked as unswappable. I guess when you dump the
kernel for debugging you'll get the locked pages aswell - Doesn't make to
much sense if all locked pages are missing from the dump.

>
> The thing is, system encryption is not easy to do and conceptually
> does not help a lot. If it was necessary to prevent having
> passphrases/keys to disk, that would be a major security flaw
> in the handling of said passphrases/keys and it would affect
> other things as well, like GnuPG, OpenSSL, etc. and so I hope
> somebody would have complained by now if that was a real issue.

It is quite difficult to i.e. encrypt /etc (which might include
passphrases for services or something) by it's own, so doing a system
encryption is quite tempting. Otherwhise you'll have to relocate specific
files from /etc to other places and maintain a pile of config changes,
which can be quite an effort aswell.

>
> Gr"usse,
> Arno
>
>

Regards

-Sven

> On Fri, Jun 26, 2015 at 14:59:18 CEST, Heinz Diehl wrote:
>> On 26.06.2015, Arno Wagner wrote:
>>
>> > My advice is to not encrypt the system partition itself, just
>> > all user and data partitions.
>>
>> I wonder if the passphrase could leak to the unencrypted system
>> partition in such
>> a scenario. E.g. memory contents dumped to disk while crashing or
>> similar. In fact, I don't know what is possible or not, I'm just
>> curious..
>>
>>
>> _______________________________________________
>> 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
> ----
> A good decision is based on knowledge and not on numbers. -- Plato
>
> If it's in the news, don't worry about it.  The very definition of
> "news" is "something that hardly ever happens." -- Bruce Schneier
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Using a removable-device-recorded passphrase to decrypt a system

[Arno Wagner]

On Fri, Jun 26, 2015 at 15:53:01 CEST, Sven Eschenberg wrote:
> On Fri, June 26, 2015 15:19, Arno Wagner wrote:
[...]
> > - I have no idea whether locked memory can end up in a
> >   core-dump, but usually these are disabled anyways.
> 
> There certainly is a debug option to get coredumps including locked pages,
> I presume.

I would expect so as well. But debugging is not a concern IMO,
unless it is too easy to leace on accidentally.

> > - In-kernel keys are protected against leaking to disk.
> 
> Again, I presume, since I did not check the kernel's source, that the
> relevant kernel pages are marked as unswappable. I guess when you dump the
> kernel for debugging you'll get the locked pages aswell - Doesn't make to
> much sense if all locked pages are missing from the dump.
> 
> >
> > The thing is, system encryption is not easy to do and conceptually
> > does not help a lot. If it was necessary to prevent having
> > passphrases/keys to disk, that would be a major security flaw
> > in the handling of said passphrases/keys and it would affect
> > other things as well, like GnuPG, OpenSSL, etc. and so I hope
> > somebody would have complained by now if that was a real issue.
> 
> It is quite difficult to i.e. encrypt /etc (which might include
> passphrases for services or something) by it's own, so doing a system
> encryption is quite tempting. Otherwhise you'll have to relocate specific
> files from /etc to other places and maintain a pile of config changes,
> which can be quite an effort aswell.

Well, yes. It is a trade-off that depends on the specific situation 
and distribution. Personally, I avoid putting credentials into /etc,
but I do have some in my home, mostly ssh-keys allowing passwordless
logins.

I do realize this will not always be possible.

Gr"usse,
Arno
-- 
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
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Using a removable-device-recorded passphrase to decrypt a system

[Sven Eschenberg]

Hi Arno,

On Fri, June 26, 2015 14:30, Arno Wagner wrote:
> Hi Arbiel,
>
> I think you have some misunderstanding here: crypttab does
> not work for encrypted system, as it is on that encrypted system
> itself (catch-22).

Conceptually yes, well, kinda. Usually crypttab ends up in the initram/rd
and should be available during early boot

>
> In order to have an encrypted system partition, you need some
> mechanism in the initrd to read your passphrase. What form that
> mechanism takes depends on the distribution you are using.

Exactly, so it all is distribution specific. If the distribution builds
initram/rd with cryptsetup+tab and has all the necesary meat around the
bones crypttab is the right place. But the info the OP is looking for will
be coming with his distribution and is only loosely related to cryptsetup
itself.

>
> My advice is to not encrypt the system partition itself, just
> all user and data partitions. An "evil Maid" attacker can get
> into your boot process anyways. Disk encryption really only
> protects against encrypted devices being stolen while not
> mapped (machine is off, e.g.).

A good advice, esp. for less experienced users. Even when the distribution
makes it a piece of cake to set up, once it fails, it bakfires hard on
inexperienced users.

>
> Gr"usse,
> Arno
>
>
Regards

-Sven

>
>
> On Thu, Jun 25, 2015 at 16:57:33 CEST, Arbiel (gmx) wrote:
>> Hi
>>
>> I decided to use a 512-byte randomly generated passphrase to crypt my
>> system partition. I recorded this passphrase on a removable device (USB
>> key) and correctly wrote the crypttab and fstab files and updated my
>> initrd.img for all this to work.
>>
>> I am anxious now to replicate my passphrase on additionnal USB keys, in
>> case my primary USB key get lost or damaged.
>>
>> For some reasons, I cannot name all partitions where my passphrase will
>> be recorded with a unique label.
>>
>> I tried to write several lines in the crypttab file for defining as many
>> passphrase locations as necessary such as
>> root UUID=uuid /dev/disk/by-label/USBkey1/passphrase:x
>> luks,keyscript=/lib/cryptsetup/scripts/passdev
>> root UUID=uuid /dev/disk/by-label/USBkey2/passphrase:x
>> luks,keyscript=/lib/cryptsetup/scripts/passdev
>> and so on, but this does not work.
>>
>> I thank in advance anybody who can advise me on how to solve this issue.
>>
>> Arbiel
>>
>
>
>
>> _______________________________________________
>> 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
> ----
> A good decision is based on knowledge and not on numbers. -- Plato
>
> If it's in the news, don't worry about it.  The very definition of
> "news" is "something that hardly ever happens." -- Bruce Schneier
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>