Re: [dm-crypt] cryptsetup Yubikey challenge-response support

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[JT Morée]

I have been in discussions on this list recently working toward tighter integration of LUKS with smart cards.  You can view my progress here:

https://sites.google.com/site/jtmoree/knowledge-base/cryptsetup-luks-and-smart-cards

I don't pretend to speak for the project but i have concluded
* dmcrypt would rather not implement vendor specific solutions ( I agree)
* the project has been working toward smart card features
* 2.4.0-RC0 will be a milestone in this regard

Feel free to provide feedback if I have anything incorrect on my writeup.

JT

p.s.  I think yahoo mail messes up the quotes of previous replies.  Leaving the below for context

On Wednesday, April 8, 2020, 3:09:56 AM MST, Nikolay Kichukov <hijacker@oldum.net> wrote: 

I am also interested, HMAC/SHA challenge-response for OnlyKey would be 
great addition to cryptsetup.

I do not think this should be product specific implementation, but 
general for all hardware tokens that support it: OnlyKey, Yubikey, 
Nitrokey, etc.

...

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Dan Farrell]

Thanks for the info!

Do you think there would be major push back against implementing a
generic challeng response mechanism?

The idea is to popen out to programs/scripts which then do the vendor
specific implementation, but over stdin/stdout use a common protocol.

That way cryptsetup does not need to know anything about
implementation, including whether it is vendor specific. Then it is up
to people other than cryptsetup to manage this, including adding new
scripts/programs to do this.

I'm keen to get your thoughts on this.

Thanks,

Dan Farrell

On Wed, 8 Apr 2020 at 10:19, JT Morée <moreejt@yahoo.com> wrote:
>
> I have been in discussions on this list recently working toward tighter integration of LUKS with smart cards.  You can view my progress here:
>
> https://sites.google.com/site/jtmoree/knowledge-base/cryptsetup-luks-and-smart-cards
>
> I don't pretend to speak for the project but i have concluded
> * dmcrypt would rather not implement vendor specific solutions ( I agree)
> * the project has been working toward smart card features
> * 2.4.0-RC0 will be a milestone in this regard
>
> Feel free to provide feedback if I have anything incorrect on my writeup.
>
> JT
>
> p.s.  I think yahoo mail messes up the quotes of previous replies.  Leaving the below for context
>
> On Wednesday, April 8, 2020, 3:09:56 AM MST, Nikolay Kichukov <hijacker@oldum.net> wrote:
>
> I am also interested, HMAC/SHA challenge-response for OnlyKey would be
> great addition to cryptsetup.
>
> I do not think this should be product specific implementation, but
> general for all hardware tokens that support it: OnlyKey, Yubikey,
> Nitrokey, etc.
>
> ...
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[JT Moree]

On Thu, 2020-04-09 at 20:01 -0700, Dan Farrell wrote:
> 
> The idea is to popen out to programs/scripts which then do the vendor
> specific implementation, but over stdin/stdout use a common protocol.

The next release (2.4.0) is reported to have some plugin features to
make this easier.  I don't know if there is an ETA yet but they seem to
be working toward it as a major milestone.

Arno is working on updating the docs for new features of luks2.  Ondrej
has mentioned the plugins in previous replies on this list.  Since the
plugin feature is not done yet I don't know if docs for it are even on
the radar. There was a challenge of documenting things that are not yet
stable.

JT

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Milan Broz]

On 11/04/2020 16:49, JT Moree wrote:
> On Thu, 2020-04-09 at 20:01 -0700, Dan Farrell wrote:
>>
>> The idea is to popen out to programs/scripts which then do the vendor
>> specific implementation, but over stdin/stdout use a common protocol.
> 
> The next release (2.4.0) is reported to have some plugin features to
> make this easier.  I don't know if there is an ETA yet but they seem to
> be working toward it as a major milestone.

Well, as upstream maintainer, I tried to be silent here, but...

The loadable plugins are something I tried to avoid for years,
and now we have some plan, but please - there is no ETA, there is not even
promise that it happens in 2.4 (despite we need it because of TPM2 support).

Please do not rely on it yet.
(And I warned Ondra to not tell any ETA here :-)

For this thread - there is a lot of implementations for tokens/smartcard
for LUKS. Some are abandoned, some not.

For the upstream cryptsetup, I will strictly reject all contributions that
are distro-specific or introduces direct binding to any hw libraries into
cryptsetup core (either open-source or proprietary).

I hope we can provide some way in LUKS2 how to integrate it through plugins later,
but as I said above...

For the integration, if there is a reliable code that just uses the cryptsetup
binary, it is definitely useful.

Also, see the system-homed project, there are several interesting ideas
(using hw tokens and LUKS2 metadata). 

> Arno is working on updating the docs for new features of luks2.

Arno did not add anything to FAQ in this regard for the last two+ years (the last
contribution was in 2017, I do not count last week change for "LUKS2 is not
covered" FAQ commit.
The FAQ is really obsolete now, and we have to update it or remove it
from distribution soon.
(Many people already complained through various channels.)

Anyway, please be patient. If you think there should be a strict plan,
I had several plans... and life changed everything upside-down several times
in the last year.
So you have to trust upstream maintainer for now, it will settle, eventually.

Stay tuned, and thanks for all the fish^W support :)

Milan

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Arno Wagner]

On Sat, Apr 11, 2020 at 18:09:46 CEST, Milan Broz wrote:
> On 11/04/2020 16:49, JT Moree wrote:
> > Arno is working on updating the docs for new features of luks2.
> 
> Arno did not add anything to FAQ in this regard for the last two+ years (the last
> contribution was in 2017, I do not count last week change for "LUKS2 is not
> covered" FAQ commit.
> The FAQ is really obsolete now, and we have to update it or remove it
> from distribution soon.
> (Many people already complained through various channels.)

Well, many people complained and exactly zero did any work
or offered any work. Also, zero did complain to me (except 
for the comments on the list here). These two details make 
me very unconcerned about their complaints.

This is, at the moment, the LUKS 1 FAQ (and that was really
what the commit from last week was about), and as that it does 
not need removing. It also covers quite a bit of stuff that is 
not LUKS 1 specific and some stuff that is not even LUKS specific.
So unless you are positive nobody uses LUKS 1 anymore, and the 
not LUKS 1 specific stuff is irrelevant, removing it would really 
be the wrong approach.

If you want to start a LUKS 2 FAQ, be my guest. But be aware 
that such a thing is a _lot_ of work before it is anywhere 
near completion. That you do not have complete design 
documentation for LUKS 2 (as far as I can tell) makes it 
even harder. Maybe you write that documentation and as soon
as it is complete, I will go into the FAQ and start updating.

Regards,
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] cryptsetup Yubikey challenge-response support

[JT Moree]

On Sat, 2020-04-11 at 21:56 +0200, Arno Wagner wrote:
> If you want to start a LUKS 2 FAQ, be my guest. But be aware 
> that such a thing is a _lot_ of work before it is anywhere 
> 

I am documenting for myself as I figure luks2 out and would be willing
to contribute to some end user LUKS2 docs.  I have read the spec pdf
and am still trying to understand how the less used features work
--hence my presence on this list.

It seems that quite a few people have posted this month with an
interest in working on various aspects--mostly smart card related.  If
someone has specific needs pleaase post to this list.  We will do what
we can.

I am building my own LUKS2 questions and answers and will share them as
I find answers. here are the questions I have so far--some of which we
have started addressing on this list.

Questions
=========

* it seems like the keyslot area size is not fixed in luks2 spec.  is
this correct?  what is the default size of keyslot area in the
reference implementation?  

* how can I tell if a luks container is already in use before trying to
open it? what is the best way?  alternatives?

* what is an unbound keyslot?  How can I use it?
* what is pbkdf?
* what are per keyslot parameters?
* How can I insert JSON data into the LUKS 2 header?
* How can I extract JSON data from the LUKS 2 header?
* How can I store binary data in the LUKS 2 header?
* I see the header is redundant. Is there an automatic recovery?
* How can I manually recover the luks header if the primary one is
corrupted?

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Arno Wagner]

Hi JT,

well, you can certainly send answers to me when they are 
finished and I can start building a LUKS 2 section in the 
existing FAQ based on that.

Just remember, it is an FAQ, it is not intended to replace 
the original documentation, it is intended to supplement it.
If anybody wants to write some HOWTOs outside of the FAQ,
that may also be a good idea, especially as an FAQ is not
really suitable to answer complicated question or explain
complex processes.

@everybody: What are the preferences: Separate LUKS 2 FAQ or 
section in the existing FAQ? 

@LUKS 2 team: If you want to do a LUKS 2 FAQ yourself, please 
let me know and I will stay out of it.

Regards,
Arno

On Sat, Apr 11, 2020 at 23:05:36 CEST, JT Moree wrote:
> On Sat, 2020-04-11 at 21:56 +0200, Arno Wagner wrote:
> > If you want to start a LUKS 2 FAQ, be my guest. But be aware 
> > that such a thing is a _lot_ of work before it is anywhere 
> > 
> 
> I am documenting for myself as I figure luks2 out and would be willing
> to contribute to some end user LUKS2 docs.  I have read the spec pdf
> and am still trying to understand how the less used features work
> --hence my presence on this list.
> 
> It seems that quite a few people have posted this month with an
> interest in working on various aspects--mostly smart card related.  If
> someone has specific needs pleaase post to this list.  We will do what
> we can.
> 
> I am building my own LUKS2 questions and answers and will share them as
> I find answers. here are the questions I have so far--some of which we
> have started addressing on this list.
> 
> Questions
> =========
> 
> * it seems like the keyslot area size is not fixed in luks2 spec.  is
> this correct?  what is the default size of keyslot area in the
> reference implementation?  
> 
> * how can I tell if a luks container is already in use before trying to
> open it? what is the best way?  alternatives?
> 
> * what is an unbound keyslot?  How can I use it?
> * what is pbkdf?
> * what are per keyslot parameters?
> * How can I insert JSON data into the LUKS 2 header?
> * How can I extract JSON data from the LUKS 2 header?
> * How can I store binary data in the LUKS 2 header?
> * I see the header is redundant. Is there an automatic recovery?
> * How can I manually recover the luks header if the primary one is
> corrupted?
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://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] LUKS FAQ separate for LUKS1/LUKS2, or combined? Was: cryptsetup Yubikey challenge-response support

[Michael Kjörling]

On 12 Apr 2020 00:23 +0200, from arno@wagner.name (Arno Wagner):
> @everybody: What are the preferences: Separate LUKS 2 FAQ or 
> section in the existing FAQ? 

LUKS is LUKS. Most of the concepts are similar. Most of the problems
LUKS (1 and 2) solve are similar.

Yes, some _answers_ might well be different for LUKS 1 or LUKS 2. But
the _questions_ should be mostly the same, and _why_ to do one thing
or another should be similar. The only obvious exception to that which
I can think of is where something is _possible_ in LUKS 2, but simply
not possible in LUKS 1, _and_ that would be worthy of inclusion in a
FAQ in the first place.

There's already parts in the FAQ that discuss dm-crypt, RAM,
passphrases, erasing data, and so on; so there's ample precedent that
the FAQ already covers more than LUKS (1) proper.

Therefore, in the name of consistency and ease of reading, I would
suggest to keep it all in one document, _but_ clearly mark the parts
that only apply to one or the other. (This could be whole Q/A tuples,
or just a portion such as an example command line.) Also perhaps add
something near the top for how to tell based on an existing container,
ideally irrespective of how the distribution does things, whether a
LUKS container is LUKS 1 or LUKS 2.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [dm-crypt] LUKS FAQ separate for LUKS1/LUKS2, or combined? Was: cryptsetup Yubikey challenge-response support

[Milan Broz]

On 12/04/2020 15:00, Michael Kjörling wrote:
> On 12 Apr 2020 00:23 +0200, from arno@wagner.name (Arno Wagner):
>> @everybody: What are the preferences: Separate LUKS 2 FAQ or 
>> section in the existing FAQ? 
> 
> LUKS is LUKS. Most of the concepts are similar. Most of the problems
> LUKS (1 and 2) solve are similar.> 
> Yes, some _answers_ might well be different for LUKS 1 or LUKS 2. But
> the _questions_ should be mostly the same, and _why_ to do one thing
> or another should be similar. The only obvious exception to that which
> I can think of is where something is _possible_ in LUKS 2, but simply
> not possible in LUKS 1, _and_ that would be worthy of inclusion in a
> FAQ in the first place.

Yes, and in fact we designed LUKS2 to be compatible as possible
and it is described in LUKS2 doc, referenced from FAQ already).

So, there should be only one FAQ.
(And for upstream, I am not going to support any doc split in
released archive. That would be confusing to users. They should
not care about version, unless they use some new feature.)

What we need to do is to use only one FAQ copy (currently there is text
version in main repo and primary version in wiki git), the wiki version
is already in markdown format, so perhaps I can move it to the
main git repo and this allows easy contributions through merge requests.
(The same problem applies for README, it is confusing to have two versions.)

(Unfortunately Gitlab does not allow to open merge request to wiki pages,
so to be open to direct contributions, keeping it in main repo is simpler.)

> There's already parts in the FAQ that discuss dm-crypt, RAM,
> passphrases, erasing data, and so on; so there's ample precedent that
> the FAQ already covers more than LUKS (1) proper.

And some of these need update too, for example use of kernel keyring
makes all scripts that use key in mapping table obsolete.
(This is a dm-crypt feature, not LUKS2 one.)
 
> Therefore, in the name of consistency and ease of reading, I would
> suggest to keep it all in one document, _but_ clearly mark the parts
> that only apply to one or the other. (This could be whole Q/A tuples,
> or just a portion such as an example command line.) Also perhaps add
> something near the top for how to tell based on an existing container,
> ideally irrespective of how the distribution does things, whether a
> LUKS container is LUKS 1 or LUKS 2.

I do not think is so big problem.

LUKS2 format allows many optional features (authenticated encryption,
reencryption, token metadata store), but these should be in separate
chapter anyway.

The basic functionality is exactly the same as LUKS1, just it allows more
flexibility (more keyslot, other PBKDF etc).

Also, if you anyone think there missing anything in LUKS2 doc, please
be exact and report it.
GRUB2 just implemented LUKS2 support using that doc, so I think
it works as implementation doc.
(And the cryptography is exactly the same as in LUKS1, except Argon2 PBKDF.)

Milan

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Milan Broz]

On 11/04/2020 21:56, Arno Wagner wrote:
> On Sat, Apr 11, 2020 at 18:09:46 CEST, Milan Broz wrote:
>> On 11/04/2020 16:49, JT Moree wrote:
>>> Arno is working on updating the docs for new features of luks2.
>>
>> Arno did not add anything to FAQ in this regard for the last two+ years (the last
>> contribution was in 2017, I do not count last week change for "LUKS2 is not
>> covered" FAQ commit.
>> The FAQ is really obsolete now, and we have to update it or remove it
>> from distribution soon.
>> (Many people already complained through various channels.)
> 
> Well, many people complained and exactly zero did any work
> or offered any work. Also, zero did complain to me (except 
> for the comments on the list here). These two details make 
> me very unconcerned about their complaints.

Arno, please do not take this as a personal thing.

There are several issues in tracker about FAQ, some distributions
already have quite nice own LUKS2 doc (Arch Linux for example).
So we should update it, even it is incomplete, it is better
than to not touch it at all.

Also, external contributors should have easy way hot to update
FAQ (see my other reply about wiki; merge request are not problematic).

> This is, at the moment, the LUKS 1 FAQ (and that was really
> what the commit from last week was about), and as that it does 
> not need removing. It also covers quite a bit of stuff that is 
> not LUKS 1 specific and some stuff that is not even LUKS specific.
> So unless you are positive nobody uses LUKS 1 anymore, and the 
> not LUKS 1 specific stuff is irrelevant, removing it would really 
> be the wrong approach.

Yes, LUKS1 is there and will be there.

But what I really tried from the beginning - a normal user
should not care about version.

(For example that keyslot checker use API, so it should work
with LUKS2 etc. Just the offsets of keyslot will not be fixed.)

And it works this way, people complained mainly about memory 
requirements for Argon KDF (and that is a feature, not a bug :-)

> If you want to start a LUKS 2 FAQ, be my guest. But be aware 
> that such a thing is a _lot_ of work before it is anywhere 
> near completion. That you do not have complete design 
> documentation for LUKS 2 (as far as I can tell) makes it 
> even harder. Maybe you write that documentation and as soon
> as it is complete, I will go into the FAQ and start updating.

One LUKS FAQ is enough for anyone :)

What is missing in LUKS2 doc that you need for this work to start?
It is metadata on-disk format, nothing more.

And for the FAQ complexity - I am FAQ co-author since
the cryptsetup 1.0.7 (2009) release so I know how longterm work it is.
That's why it a little bit irritates me that we did not updated
it yet (I just fixed obsolete links there).

Milan

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Dan Farrell]

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

Hi Milan,

I can code ugly just watch!

On Sat, 11 Apr 2020 at 09:12, Milan Broz <gmazyland@gmail.com> wrote:
> For the upstream cryptsetup, I will strictly reject all contributions that
> are distro-specific or introduces direct binding to any hw libraries into
> cryptsetup core (either open-source or proprietary).

Please take a look at the attached, feel to poke fun at it, it is
terrible for all of the reasons.

But, if something that did what is achieved in this patch was done
properly, would it be even possible to get it merged?

Hopefully the attachment comes through...

Regards,

Dan Farrell

[-- Attachment #2: 0001-utils_password-add-external-password-helper.patch --]
[-- Type: text/x-patch, Size: 4660 bytes --]

From d02cac64caae1b1bd5e7b0d4e8841d525a0dda61 Mon Sep 17 00:00:00 2001
From: djfarrell <djfarrell@gmail.com>
Date: Tue, 14 Apr 2020 23:29:11 -0700
Subject: [PATCH] utils_password: add external password helper

This change is hacky and horrible, used only for science of the
bad kind.

Adds method for gathering password from external helper program.

Tested with basic helper.

Signed-off-by: djfarrell <djfarrell@gmail.com>
---
 src/cryptsetup.c     |  1 +
 src/cryptsetup.h     |  1 +
 src/utils_password.c | 59 ++++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/src/cryptsetup.c b/src/cryptsetup.c
index 6a0d8ef9..3a78864d 100644
--- a/src/cryptsetup.c
+++ b/src/cryptsetup.c
@@ -3448,6 +3448,7 @@ int main(int argc, const char **argv)
 		{ "veracrypt-query-pim", '\0', POPT_ARG_NONE, &opt_veracrypt_query_pim, 0, N_("Query Personal Iteration Multiplier for VeraCrypt compatible device"), NULL },
 		{ "type",               'M', POPT_ARG_STRING, &opt_type,                0, N_("Type of device metadata: luks, luks1, luks2, plain, loopaes, tcrypt, bitlk"), NULL },
 		{ "force-password",    '\0', POPT_ARG_NONE, &opt_force_password,        0, N_("Disable password quality check (if enabled)"), NULL },
+		{ "password-helper",   '\0', POPT_ARG_STRING, &opt_password_helper,     0, N_("Launch passowrd helper to get password"), NULL },
 		{ "perf-same_cpu_crypt",'\0', POPT_ARG_NONE, &opt_perf_same_cpu_crypt,  0, N_("Use dm-crypt same_cpu_crypt performance compatibility option"), NULL },
 		{ "perf-submit_from_crypt_cpus",'\0', POPT_ARG_NONE, &opt_perf_submit_from_crypt_cpus,0,N_("Use dm-crypt submit_from_crypt_cpus performance compatibility option"), NULL },
 		{ "deferred",          '\0', POPT_ARG_NONE, &opt_deferred_remove,       0, N_("Device removal is deferred until the last user closes it"), NULL },
diff --git a/src/cryptsetup.h b/src/cryptsetup.h
index 1afcf433..e799855f 100644
--- a/src/cryptsetup.h
+++ b/src/cryptsetup.h
@@ -62,6 +62,7 @@ extern int opt_verbose;
 extern int opt_batch_mode;
 extern int opt_force_password;
 extern int opt_progress_frequency;
+extern char *opt_password_helper;
 
 /* Common tools */
 void clogger(struct crypt_device *cd, int level, const char *file, int line,
diff --git a/src/utils_password.c b/src/utils_password.c
index 55c1343f..fbbf9563 100644
--- a/src/utils_password.c
+++ b/src/utils_password.c
@@ -23,6 +23,7 @@
 #include <termios.h>
 
 int opt_force_password = 0;
+char *opt_password_helper = NULL;
 
 #if defined ENABLE_PWQUALITY
 #include <pwquality.h>
@@ -102,6 +103,7 @@ static int untimed_read(int fd, char *pass, size_t maxlen)
 	i = read(fd, pass, maxlen);
 	if (i > 0) {
 		pass[i-1] = '\0';
+		printf("%s\n", pass);
 		i = 0;
 	} else if (i == 0) { /* EOF */
 		*pass = 0;
@@ -127,6 +129,53 @@ static int timed_read(int fd, char *pass, size_t maxlen, long timeout)
 	return failed;
 }
 
+static int timed_read_with_helper(int fd, char *pass, size_t maxlen, long timeout)
+{
+	struct timeval t, *pt;
+	fd_set fds = {}; /* Just to avoid scan-build false report for FD_SET */
+	int failed = -1;
+	FILE *phelper = popen(opt_password_helper, "r");
+	int phelper_fd = -1;
+	int maxfd = fd;
+	int nfds = 0;
+
+	FD_ZERO(&fds);
+	FD_SET(fd, &fds);
+
+	if (timeout > 0) {
+		t.tv_sec = timeout;
+		t.tv_usec = 0;
+		pt = &t;
+	} else {
+		pt = NULL;
+	}
+
+	if (phelper) {
+		printf("have phelper\n");
+		phelper_fd = fileno(phelper);
+		if (phelper_fd > maxfd)
+			maxfd = phelper_fd;
+		FD_SET(phelper_fd, &fds);
+	}
+
+
+	nfds = select(maxfd+1, &fds, NULL, NULL, pt);
+	if (nfds == 2 || FD_ISSET(fd, &fds))
+		failed = untimed_read(fd, pass, maxlen);
+	else if (nfds == 1)
+		failed = untimed_read(phelper_fd, pass, maxlen);
+
+	if (phelper)
+		pclose(phelper);
+
+	return failed;
+}
+
+static int untimed_read_with_helper(int fd, char *pass, size_t maxlen)
+{
+	return timed_read_with_helper(fd, pass, maxlen, -1);
+}
+
 static int interactive_pass(const char *prompt, char *pass, size_t maxlen,
 		long timeout)
 {
@@ -156,9 +205,15 @@ static int interactive_pass(const char *prompt, char *pass, size_t maxlen,
 
 	tcsetattr(infd, TCSAFLUSH, &tmp);
 	if (timeout)
-		failed = timed_read(infd, pass, maxlen, timeout);
+		if (!opt_password_helper)
+			failed = timed_read(infd, pass, maxlen, timeout);
+		else
+			failed = timed_read_with_helper(infd, pass, maxlen, timeout);
 	else
-		failed = untimed_read(infd, pass, maxlen);
+		if (!opt_password_helper)
+			failed = untimed_read(infd, pass, maxlen);
+		else
+			failed = untimed_read_with_helper(infd, pass, maxlen);
 	tcsetattr(infd, TCSAFLUSH, &orig);
 
 out_err:
-- 
2.25.2

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Dan Farrell]

Oh god it contains the printing out the password for testng...

On Tue, 14 Apr 2020 at 23:37, Dan Farrell <djfarrell@gmail.com> wrote:
>
> Hi Milan,
>
> I can code ugly just watch!
>
> On Sat, 11 Apr 2020 at 09:12, Milan Broz <gmazyland@gmail.com> wrote:
> > For the upstream cryptsetup, I will strictly reject all contributions that
> > are distro-specific or introduces direct binding to any hw libraries into
> > cryptsetup core (either open-source or proprietary).
>
> Please take a look at the attached, feel to poke fun at it, it is
> terrible for all of the reasons.
>
> But, if something that did what is achieved in this patch was done
> properly, would it be even possible to get it merged?
>
> Hopefully the attachment comes through...
>
> Regards,
>
> Dan Farrell

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Dan Farrell]

And the popen mode should be "rw"...

Anyway, I think the idea is clear.

On Tue, 14 Apr 2020 at 23:48, Dan Farrell <djfarrell@gmail.com> wrote:
>
> Oh god it contains the printing out the password for testng...
>
> On Tue, 14 Apr 2020 at 23:37, Dan Farrell <djfarrell@gmail.com> wrote:
> >
> > Hi Milan,
> >
> > I can code ugly just watch!
> >
> > On Sat, 11 Apr 2020 at 09:12, Milan Broz <gmazyland@gmail.com> wrote:
> > > For the upstream cryptsetup, I will strictly reject all contributions that
> > > are distro-specific or introduces direct binding to any hw libraries into
> > > cryptsetup core (either open-source or proprietary).
> >
> > Please take a look at the attached, feel to poke fun at it, it is
> > terrible for all of the reasons.
> >
> > But, if something that did what is achieved in this patch was done
> > properly, would it be even possible to get it merged?
> >
> > Hopefully the attachment comes through...
> >
> > Regards,
> >
> > Dan Farrell

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Milan Broz]

On 15/04/2020 08:37, Dan Farrell wrote:
> 
> Please take a look at the attached, feel to poke fun at it, it is
> terrible for all of the reasons.
> 
> But, if something that did what is achieved in this patch was done
> properly, would it be even possible to get it merged?

Hi,

Why do you need this? Cryptsetup easily allows to pipe passphrase:

/path/some_helper | cryptsetup open ....

(some tricks are needed to process binary input, but it is possible,
see man page or ask here).

For LUKS2, you can also define keyring token, store passphrase in keyring
under defined name and then cryptsetup automagically use it in open command.

(Even systemd-ask-password scripts can be used to automate it, but
I understand there is a group of people that is quite reserved to this,
me included. For reference see clevis/tang project, but please do not
ask me about it in detail :-)

Milan

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Arno Wagner]

On Tue, Apr 14, 2020 at 13:35:21 CEST, Milan Broz wrote:
> On 11/04/2020 21:56, Arno Wagner wrote:
> > On Sat, Apr 11, 2020 at 18:09:46 CEST, Milan Broz wrote:
> >> On 11/04/2020 16:49, JT Moree wrote:
> >>> Arno is working on updating the docs for new features of luks2.
> >>
> >> Arno did not add anything to FAQ in this regard for the last two+ years (the last
> >> contribution was in 2017, I do not count last week change for "LUKS2 is not
> >> covered" FAQ commit.
> >> The FAQ is really obsolete now, and we have to update it or remove it
> >> from distribution soon.
> >> (Many people already complained through various channels.)
> > 
> > Well, many people complained and exactly zero did any work
> > or offered any work. Also, zero did complain to me (except 
> > for the comments on the list here). These two details make 
> > me very unconcerned about their complaints.
> 
> Arno, please do not take this as a personal thing.

Ok, I will not.

> There are several issues in tracker about FAQ, some distributions
> already have quite nice own LUKS2 doc (Arch Linux for example).
> So we should update it, even it is incomplete, it is better
> than to not touch it at all.

Arch has it? Good. I will look at it as soon as I find time.
I am currently more busy than usual due to some things 
happening at my emplpoyer. The Arch doc would at least be an 
item for the references.
 
> Also, external contributors should have easy way hot to update
> FAQ (see my other reply about wiki; merge request are not problematic).

Ok.

> > This is, at the moment, the LUKS 1 FAQ (and that was really
> > what the commit from last week was about), and as that it does 
> > not need removing. It also covers quite a bit of stuff that is 
> > not LUKS 1 specific and some stuff that is not even LUKS specific.
> > So unless you are positive nobody uses LUKS 1 anymore, and the 
> > not LUKS 1 specific stuff is irrelevant, removing it would really 
> > be the wrong approach.
> 
> Yes, LUKS1 is there and will be there.
> 
> But what I really tried from the beginning - a normal user
> should not care about version.

Well, the FAQ goes deep into details in some places and then
you need to know. For somebody just doing the standard 
scenario and not having any specific issues, I agree, the 
version should not matter.

> (For example that keyslot checker use API, so it should work
> with LUKS2 etc. Just the offsets of keyslot will not be fixed.)
> 
> And it works this way, people complained mainly about memory 
> requirements for Argon KDF (and that is a feature, not a bug :-)

I see an FAQ item upcomming on that ;-)

> > If you want to start a LUKS 2 FAQ, be my guest. But be aware 
> > that such a thing is a _lot_ of work before it is anywhere 
> > near completion. That you do not have complete design 
> > documentation for LUKS 2 (as far as I can tell) makes it 
> > even harder. Maybe you write that documentation and as soon
> > as it is complete, I will go into the FAQ and start updating.
> 
> One LUKS FAQ is enough for anyone :)

Ok, I think that is settled then.

> What is missing in LUKS2 doc that you need for this work to start?
> It is metadata on-disk format, nothing more.

Ok, then I will start with that. 

It is an FAQ fter all, so it is request driven. Anything missing, 
people using it should complain about. Is the issue-tracker still 
the best source to find all requets and complaints? If not, can 
you update it with the issue people have run into with the 
current FAQ in a way to I can find them?
 
> And for the FAQ complexity - I am FAQ co-author since
> the cryptsetup 1.0.7 (2009) release so I know how longterm work it is.
> That's why it a little bit irritates me that we did not updated
> it yet (I just fixed obsolete links there).

One reason is perhaps that most things with LUKS2 did not involve 
me. Being an external contributor has the advantace of a separate 
perspective, but also the disadvantage that I am distant from 
what is going on and ofthen late to find out. That is fine,
after all, we can talk things over and I know now that some
work is needed.

Regards,
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] LUKS FAQ separate for LUKS1/LUKS2, or combined? Was: cryptsetup Yubikey challenge-response support

[Arno Wagner]

On Tue, Apr 14, 2020 at 12:56:26 CEST, Milan Broz wrote:
> On 12/04/2020 15:00, Michael Kjörling wrote:
> > On 12 Apr 2020 00:23 +0200, from arno@wagner.name (Arno Wagner):
> >> @everybody: What are the preferences: Separate LUKS 2 FAQ or 
> >> section in the existing FAQ? 
> > 
> > LUKS is LUKS. Most of the concepts are similar. Most of the problems
> > LUKS (1 and 2) solve are similar.> 
> > Yes, some _answers_ might well be different for LUKS 1 or LUKS 2. But
> > the _questions_ should be mostly the same, and _why_ to do one thing
> > or another should be similar. The only obvious exception to that which
> > I can think of is where something is _possible_ in LUKS 2, but simply
> > not possible in LUKS 1, _and_ that would be worthy of inclusion in a
> > FAQ in the first place.
> 
> Yes, and in fact we designed LUKS2 to be compatible as possible
> and it is described in LUKS2 doc, referenced from FAQ already).
> 
> So, there should be only one FAQ.
> (And for upstream, I am not going to support any doc split in
> released archive. That would be confusing to users. They should
> not care about version, unless they use some new feature.)

Ok, I think that is settled then: Current FAQ will be updated
in order to have one place of reference and to not have 
redundancies (where possible).
 
> What we need to do is to use only one FAQ copy (currently there is text
> version in main repo and primary version in wiki git), the wiki version
> is already in markdown format, so perhaps I can move it to the
> main git repo and this allows easy contributions through merge requests.
> (The same problem applies for README, it is confusing to have two versions.)

Since I have always only maintained the Wiki version (I still have the
Wiki->txt Python script somewhere, I think) that is entirely fine by me.

> (Unfortunately Gitlab does not allow to open merge request to wiki pages,
> so to be open to direct contributions, keeping it in main repo is simpler.)

Just let me know what you decide. Since it looks like I will be doing 
some editing, it would be nice if I could still edit it directly
though. Of course I do not need (or want) access to anything else.
 
> > There's already parts in the FAQ that discuss dm-crypt, RAM,
> > passphrases, erasing data, and so on; so there's ample precedent that
> > the FAQ already covers more than LUKS (1) proper.
> 
> And some of these need update too, for example use of kernel keyring
> makes all scripts that use key in mapping table obsolete.
> (This is a dm-crypt feature, not LUKS2 one.)

Ok. Here I would need to know what heppens if the kernel is old 
and does not have the keyring feature. Or is the keyring feature 
assured on all currently maintained kernels? First document I found 
on it on a brief search is from 2006, so that may be the case.

Since this seems to be originally for eCryptFS (which I do not use),
I have ignored this feature so far. Is
https://www.kernel.org/doc/Documentation/security/keys-ecryptfs.txt
the autorative reference? Or am I confusing something here?

> > Therefore, in the name of consistency and ease of reading, I would
> > suggest to keep it all in one document, _but_ clearly mark the parts
> > that only apply to one or the other. (This could be whole Q/A tuples,
> > or just a portion such as an example command line.) Also perhaps add
> > something near the top for how to tell based on an existing container,
> > ideally irrespective of how the distribution does things, whether a
> > LUKS container is LUKS 1 or LUKS 2.
> 
> I do not think is so big problem.
> 
> LUKS2 format allows many optional features (authenticated encryption,
> reencryption, token metadata store), but these should be in separate
> chapter anyway.

I agree. "Section XYZ: Additional features available with LUKS2".

> The basic functionality is exactly the same as LUKS1, just it allows more
> flexibility (more keyslot, other PBKDF etc).
> 
> Also, if you anyone think there missing anything in LUKS2 doc, please
> be exact and report it.

Yes, please do. And on things added to the FAQ, please report errors.

> GRUB2 just implemented LUKS2 support using that doc, so I think
> it works as implementation doc.
> (And the cryptography is exactly the same as in LUKS1, except Argon2 PBKDF.)

Ah, good to know. That was one of the things unclear to me.
Another item for the LUKS2 section.

Ok, I think I can invest a few hours this or next weekend to 
start on the structure additions to the FAQ and put in some 
initial items and do some reviewe. 
The whole process will take a while though.

Regards,
Arno

 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://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] cryptsetup Yubikey challenge-response support

[Dan Farrell]

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

Hi,

The reason I want this is be have the option of entering a password
manually, or have it automatically provided by a program at the same time.

So the idea is, for example, I turn on my laptop and either type the
password, or insert a security token. The password helper program would
interact with the token, and provide a password from it.

Does that make sense? I realise it is a bit silly, but relying on systemd
to provide a password seems suboptimal. It's just an easy way of getting
vendor specific USB support without he libs in cryptsetup itself.

But for sure I won't take any offence if it's a no go, I can do it for my
own systems easily enough.

Cheers,

Dan Farrell

On Wed, 15 Apr 2020, 12:38 Milan Broz, <gmazyland@gmail.com> wrote:

> On 15/04/2020 08:37, Dan Farrell wrote:
> >
> > Please take a look at the attached, feel to poke fun at it, it is
> > terrible for all of the reasons.
> >
> > But, if something that did what is achieved in this patch was done
> > properly, would it be even possible to get it merged?
>
> Hi,
>
> Why do you need this? Cryptsetup easily allows to pipe passphrase:
>
> /path/some_helper | cryptsetup open ....
>
> (some tricks are needed to process binary input, but it is possible,
> see man page or ask here).
>
> For LUKS2, you can also define keyring token, store passphrase in keyring
> under defined name and then cryptsetup automagically use it in open
> command.
>
> (Even systemd-ask-password scripts can be used to automate it, but
> I understand there is a group of people that is quite reserved to this,
> me included. For reference see clevis/tang project, but please do not
> ask me about it in detail :-)
>
> Milan
>

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

Re: [dm-crypt] cryptsetup Yubikey challenge-response support

[Milan Broz]

On 16/04/2020 04:03, Dan Farrell wrote:
> The reason I want this is be have the option of entering a password manually, or have it automatically provided by a program at the same time.
> 
> So the idea is, for example, I turn on my laptop and either type the password, or insert a security token. The password helper program would interact with the token, and provide a password from it.
> 
> Does that make sense? I realise it is a bit silly, but relying on systemd to provide a password seems suboptimal. It's just an easy way of getting vendor specific USB support without he libs in cryptsetup itself.

Well, that's exactly what we tried to solve with "tokens" struct in LUKS2 metadata.
(Token says "how the unlocking passphrase could be retrieved".)

If there is a token defined, cryptsetup tries to use it, if not, it fallbacks to password query.
(Currently only internal keyring token is implemented. IOW it tries to check keyring,
if it is not there, it fallbacks to password query.)

Later we allow dynamic token handling. (You can do it today if you compile own application,
libcryptsetup API allows it, but not commandline cryptsetup.)

This way the policy (and keyslot priorities) is stored in LUKS2 metadata.

For LUKS1, you can easily script this outside of cryptetup (check if token is available,
then pipe output otherwise call cryptsetup without piping input). Or see below.

> But for sure I won't take any offence if it's a no go, I can do it for my own systems easily enough.

TBH I think you are implementing something that can be done with named pipes already
(you can use named pipe for --key-file).

Try:

# mkfifo pipe
# cryptsetup open <device> <name> --key-file pipe &

And now just write to the pipe what you want (either manually ot through token):
# echo -n <passphrase> >pipe

(Note it processes EOL as part of the keyfile, so you need to avoid it.)

Milan