Using a removable-device-recorded passphrase to decrypt a system
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
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
Quoted 32 lines · Arbiel (gmx)
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Quoted 2 lines · Arno Wagner
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..
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
Quoted 15 lines · Heinz Diehl
Quoted 2 lines · Arno Wagner
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Quoted 8 lines · 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:
Quoted 6 lines
- 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.
Quoted 3 lines
- 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.
Quoted 1 line
- 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.
Quoted 7 lines
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.
Quoted 5 lines
Gr"usse,
Arno
Regards
-Sven
Quoted 32 lines · Heinz Diehl
Quoted 12 lines · Arno Wagner
Quoted 3 lines
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..Quoted 4 lines
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected]
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. -- PlatoIf 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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Hi Arno,
Quoted 5 lines · 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).
Conceptually yes, well, kinda. Usually crypttab ends up in the initram/rd and should be available during early boot
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
Gr"usse,
Arno
Regards
-Sven
Quoted 51 lines · Arbiel (gmx)
Quoted 28 lines
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
Quoted 4 lines
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected]
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. -- PlatoIf 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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 1 line · Sven Eschenberg
On Fri, June 26, 2015 15:19, Arno Wagner wrote:
[...]
Quoted 5 lines
Quoted 2 lines
- 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.
Quoted 15 lines
Quoted 1 line
- 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.
Quoted 7 lines
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.
Quoted 5 lines
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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