Bug#903163: Adding OpenPGP smartcard support to LUKS

[Peter Lebbing]

Hi,

On 21/11/2018 17:46, Guilhem Moulin wrote:
> Peter last poked Werner on Nov 09 but there wasn't any reply from him.
> (At least not on the gnupg-users list.)

Nope, no reply, unfortunately.

> Hmm on second thought the offer is tempting; if you're also attending
> 35c3 then shipping won't even be necessary ;-)

I have once programmed GnuK into a very cheap Maple Mini clone for
somebody. He hasn't tried to use it yet, but I don't expect any issues.
It's not a really practical form-factor for mobile use (it needs a USB
cable, it's not a "stick" form), but for development on a desktop, it
should be fine.

I'll bring one programmed with GnuK to the 35C3. I also ordered another
ten; if they come over from China in time, I'll program them as well,
give you another one and pass them around to interested people.

These are the boards:


If you want to protect them a bit, just put some shrink tube around it.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Dear Guilhem,

> >>> I'm not sure if the implementation currently found in our branch would
> >>> choke if the wrong smartcard is inserted: I wasn't able to test this
> >>> as I have only one token :-)
> > 
> > Can I fix that for you? (Serious offer; I can get this shipped to
> > you ASAP...)
> 
> Hmm on second thought the offer is tempting; if you're also attending
> 35c3 then shipping won't even be necessary ;-)

Name/link the exact device and I'll get it to you! (Alas I won't be
at 35C3...)

> There are none AFAIK, since the current shortcomings have been
> acknowledged as non-blocking.  And yes it makes sense to upload to
> unstable quickly, so we have a chance to fix possible bugs before the
> freeze.  (Wanted to close #901795 too, but it can be done in a separate
> upload.)  I'll merge and upload before the week-end :-)

Neat, looking forward to it. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

Hi,

On Wed, 21 Nov 2018 at 11:12:08 -0500, Chris Lamb  wrote:
> Guilhem Moulin wrote:
>>> GnuPG upstream was asked about a documented API to retrieve the stubs
>>> but hasn't answered yet AFAIK.
> 
> Did they get back to you yet out of interest, Guilhem?

Peter last poked Werner on Nov 09 but there wasn't any reply from him.
(At least not on the gnupg-users list.)
 
>>> I'm not sure if the implementation currently found in our branch would
>>> choke if the wrong smartcard is inserted: I wasn't able to test this
>>> as I have only one token :-)
> 
> Can I fix that for you? (Serious offer; I can get this shipped to
> you ASAP...)

Hmm on second thought the offer is tempting; if you're also attending
35c3 then shipping won't even be necessary ;-)
 
>> I have an idea on how to do this all more elegantly, but I haven't found
>> the time to work it out yet. Please don't block on this when the current
>> solution works for single reader, single smartcard cases.
> 
> Indeed, it would be great to see this land in the main Debian
> packages; what are the remaining blockers to this? :)

There are none AFAIK, since the current shortcomings have been
acknowledged as non-blocking.  And yes it makes sense to upload to
unstable quickly, so we have a chance to fix possible bugs before the
freeze.  (Wanted to close #901795 too, but it can be done in a separate
upload.)  I'll merge and upload before the week-end :-)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Hi Peter et al.,

Guilhem Moulin wrote:

> > GnuPG upstream was asked about a documented API to retrieve the stubs
> > but hasn't answered yet AFAIK.

Did they get back to you yet out of interest, Guilhem?

> > I'm not sure if the implementation currently found in our branch would
> > choke if the wrong smartcard is inserted: I wasn't able to test this
> > as I have only one token :-)

Can I fix that for you? (Serious offer; I can get this shipped to
you ASAP...)

> I have an idea on how to do this all more elegantly, but I haven't found
> the time to work it out yet. Please don't block on this when the current
> solution works for single reader, single smartcard cases.

Indeed, it would be great to see this land in the main Debian
packages; what are the remaining blockers to this? :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Peter Lebbing]

On 08/11/2018 02:07, Guilhem Moulin wrote:
> However that doesn't happen currently because I'm really worried about
> copying real private key material to the initramfs along with the stubs;
> GnuPG upstream was asked about a documented API to retrieve the stubs
> but hasn't answered yet AFAIK.  I'm not sure if the implementation
> currently found in our branch would choke if the wrong smartcard is
> inserted: I wasn't able to test this as I have only one token :-)

I have an idea on how to do this all more elegantly, but I haven't found
the time to work it out yet. Please don't block on this when the current
solution works for single reader, single smartcard cases. I don't know
when I'll find the time, but I'll try something out and submit it as a
patch.

I can test with multiple test readers and cards and intend to do so.

(For someone wondering: why do we need support for multiple card
readers? Consider the situation where a laptop has a built-in smartcard
reader but the user wishes to use a GnuK, which is a removable USB
device, to unlock his partition instead. This user cannot remove the
built-in smartcard reader.)

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

On Wed, 07 Nov 2018 at 13:05:17 -0800, Kyle Rankin wrote:
> I've tested these debs and can confirm everything works.

Awesome, thanks for the feedback!

> I was also able to add this support to an existing LUKS root partition
> by just using luksAddKey and making sure the crypttab was updated and
> update-initramfs was run.

Yup, that's also what I tested, and I should add to the documentation
(not specific to that keyscript) that one might want to add ‘key-slot=1’
to the crypttab(5) entry.  Indeed the first (and only) passphrase after
`luksFormat` “occupies” the 0th keyslot, and after `luksAddKey` the new
passphrase “occupies” the first keyslot available.  If one doesn't add
‘--keyslot=$INDEX’ when unlocking, then all key slots are tried one
after the other until the passphrase manages to open one; in practice
the extra KDF runs needlessly delay the boot by a few seconds.

> Note that in the case of a root partition, boot splash needs to be
> disabled so you can enter the GPG PIN.

That's because of the pinentry prompt.  Compared to askpass it also
breaks unlocking via passfifo (hence remotely via SSH, although it's not
really the use-case in this context) — which is something I should
document, but I believe it's much more important to print the number of
remaining attempts on failure, given that too many failures will freeze
the card.  (It should be feasible to retrieve the “PIN retry counter”
values from the `gpg --card-status` output and add it to the askpass
prompt, but that adds complexity and clunkiness IMHO.)

Furthermore, as Peter pointed out earlier, another advantage of using
pinentry is that if needed the user is asked to insert the smartcard
identified with its Serial Number (taken from the private key stubs).
However that doesn't happen currently because I'm really worried about
copying real private key material to the initramfs along with the stubs;
GnuPG upstream was asked about a documented API to retrieve the stubs
but hasn't answered yet AFAIK.  I'm not sure if the implementation
currently found in our branch would choke if the wrong smartcard is
inserted: I wasn't able to test this as I have only one token :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Kyle Rankin]

On Tue, Nov 06, 2018 at 10:49:36PM +0100, Guilhem Moulin wrote:
> On Tue, 06 Nov 2018 at 11:15:57 -0800, Kyle Rankin wrote:
> > On Sun, Nov 04, 2018 at 02:38:29PM +0100, Guilhem Moulin wrote:
> >> On Sun, 04 Nov 2018 at 05:35:44 -0500, Chris Lamb wrote:
> > https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
>  
>  Did you have time to look at this branch yet?  (Just rebased it on top
>  of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
> >>> 
> >>> Oh dear, I was not aware this was blocking on my end.
> >> 
> >> Oops sorry for the bad communication, should have poked you earlier
> >> in October then :-P
> >> 
> >>> Kyle, how'd you feel about checking this branch out?
> > 
> > Providing me the deb would remove any risk that any bugs I find were caused
> > by some mistake on my part in merging and building that branch, so if you
> > could provide me the deb that would be much appreciated, that way we are at
> > least a QA team of two :)
> 
> There is no merging involved as I rebased the branch on top of master :-)
> 
> But fair enough, you can use the cryptsetup packages from my private APT
> repository:
> 
> echo "deb http://guilhem.org/debian sid main" >>/etc/apt/sources.list
> apt-key add /tmp/7420DF86BCE15A458DCE997639278DA8109E6244.asc
> apt update 
> apt upgrade
> 
> The OpenPGP key used to sign the ‘Release’ file (and the source
> packages) is the one I'm using for Debian uploads; its primary key has
> the following fingerprint:
> 
> 7420 DF86 BCE1 5A45 8DCE  9976 3927 8DA8 109E 6244
> 
> Alternatively, you can manually download & install the binary packages
> from
> 
> https://guilhem.org/debian/pool/main/c/cryptsetup/
> 
> (Only ‘cryptsetup-initramfs’ and ‘cryptsetup-run’ are relevant in this
> context: the former for the initramfs boot scripts, the latter for the
> decryption script and documentation.)
> 
> Cheers,
> -- 
> Guilhem.


I've tested these debs and can confirm everything works. I was also able to
add this support to an existing LUKS root partition by just using
luksAddKey and making sure the crypttab was updated and update-initramfs
was run. Note that in the case of a root partition, boot splash needs to be
disabled so you can enter the GPG PIN.

-Kyle


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Dear Guilhem,

> But fair enough, you can use the cryptsetup packages from my private APT
> repository:
> 
> echo "deb http://guilhem.org/debian sid main" >>/etc/apt/sources.list
> apt-key add /tmp/7420DF86BCE15A458DCE997639278DA8109E6244.asc
> apt update 
> apt upgrade

Neat, thanks for providing this. I'll assume Kyle is happy to go
ahead and use these. :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

On Tue, 06 Nov 2018 at 11:15:57 -0800, Kyle Rankin wrote:
> On Sun, Nov 04, 2018 at 02:38:29PM +0100, Guilhem Moulin wrote:
>> On Sun, 04 Nov 2018 at 05:35:44 -0500, Chris Lamb wrote:
> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
 
 Did you have time to look at this branch yet?  (Just rebased it on top
 of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
>>> 
>>> Oh dear, I was not aware this was blocking on my end.
>> 
>> Oops sorry for the bad communication, should have poked you earlier
>> in October then :-P
>> 
>>> Kyle, how'd you feel about checking this branch out?
> 
> Providing me the deb would remove any risk that any bugs I find were caused
> by some mistake on my part in merging and building that branch, so if you
> could provide me the deb that would be much appreciated, that way we are at
> least a QA team of two :)

There is no merging involved as I rebased the branch on top of master :-)

But fair enough, you can use the cryptsetup packages from my private APT
repository:

echo "deb http://guilhem.org/debian sid main" >>/etc/apt/sources.list
apt-key add /tmp/7420DF86BCE15A458DCE997639278DA8109E6244.asc
apt update 
apt upgrade

The OpenPGP key used to sign the ‘Release’ file (and the source
packages) is the one I'm using for Debian uploads; its primary key has
the following fingerprint:

7420 DF86 BCE1 5A45 8DCE  9976 3927 8DA8 109E 6244

Alternatively, you can manually download & install the binary packages
from

https://guilhem.org/debian/pool/main/c/cryptsetup/

(Only ‘cryptsetup-initramfs’ and ‘cryptsetup-run’ are relevant in this
context: the former for the initramfs boot scripts, the latter for the
decryption script and documentation.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Kyle Rankin]

On Sun, Nov 04, 2018 at 02:38:29PM +0100, Guilhem Moulin wrote:
> On Sun, 04 Nov 2018 at 05:35:44 -0500, Chris Lamb wrote:
> >>> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
> >> 
> >> Did you have time to look at this branch yet?  (Just rebased it on top
> >> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
> > 
> > Oh dear, I was not aware this was blocking on my end.
> 
> Oops sorry for the bad communication, should have poked you earlier
> in October then :-P
> 
> > Kyle, how'd you feel about checking this branch out?

Providing me the deb would remove any risk that any bugs I find were caused
by some mistake on my part in merging and building that branch, so if you
could provide me the deb that would be much appreciated, that way we are at
least a QA team of two :)

-Kyle

> 
> Let me know if you don't want to build the package yourself, I can
> provide the .deb instead :-)  Alternatively, you could manually copy the
> relevant files:
> 
> install -oroot -groot -m0755 -t /lib/cryptsetup/scripts   
>   ./debian/scripts/decrypt_gnupg-sc
> install -oroot -groot -m0644 -t /usr/share/doc/cryptsetup-run 
>   ./debian/README.gnupg-sc
> install -oroot -groot -m0755 -t /usr/share/initramfs-tools/hooks  
>   ./debian/initramfs/hooks/cryptgnupg-sc
> install -oroot -groot -m0755 -t 
> /usr/share/initramfs-tools/scripts/local-bottom 
> ./debian/initramfs/scripts/local-bottom/cryptgnupg-sc
> 
> -- 
> Guilhem.




signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

On Sun, 04 Nov 2018 at 05:35:44 -0500, Chris Lamb wrote:
>>> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
>> 
>> Did you have time to look at this branch yet?  (Just rebased it on top
>> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
> 
> Oh dear, I was not aware this was blocking on my end.

Oops sorry for the bad communication, should have poked you earlier
in October then :-P

> Kyle, how'd you feel about checking this branch out?

Let me know if you don't want to build the package yourself, I can
provide the .deb instead :-)  Alternatively, you could manually copy the
relevant files:

install -oroot -groot -m0755 -t /lib/cryptsetup/scripts 
./debian/scripts/decrypt_gnupg-sc
install -oroot -groot -m0644 -t /usr/share/doc/cryptsetup-run   
./debian/README.gnupg-sc
install -oroot -groot -m0755 -t /usr/share/initramfs-tools/hooks
./debian/initramfs/hooks/cryptgnupg-sc
install -oroot -groot -m0755 -t 
/usr/share/initramfs-tools/scripts/local-bottom 
./debian/initramfs/scripts/local-bottom/cryptgnupg-sc

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Dear Guilhem,

> > https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
> 
> Did you have time to look at this branch yet?  (Just rebased it on top
> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)

Oh dear, I was not aware this was blocking on my end. Kyle, how'd
you feel about checking this branch out?


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

Hi Chris,

On Sun, 23 Sep 2018 at 06:10:52 +0200, Guilhem Moulin wrote:
> Fortunately I did have some quiet evenings last week, and finally
> pushed a new branch derived from Peter and Erik's work:
> 
> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard

Did you have time to look at this branch yet?  (Just rebased it on top
of ‘debian/2%2.0.5-1’ and applied a couple of changes.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

Hi,

On Mon, 06 Aug 2018 at 13:09:13 +0200, Jonas Meurer wrote:
> Am 23.07.2018 um 14:42 schrieb Chris Lamb:
> Still, if we would split the gnupg smartcard keyscript into an own
> binary package, we would have to do the same for decrypt_gnupg,
> decrypt_opensc and decrypt_ssl. Which would mean four new binary
> packages.

More, if were to further split the initramfs integration.  For instance
in the case of OpenPGP smartcards, pinentry-gtk (the default pinentry
flavor) will suffice for the normal system, but pinentry-curses |
pinentry-tty is required for unlocking to work at early boot stage.

Tight dependencies are great, but is it really worth it for a package
with just a dozen of lines of shell code and 10× as much meta-data?

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

On Sat, 22 Sep 2018 at 09:04:49 +0100, Chris Lamb wrote:
>> Sorry, I've been rather short on time lately; will try to take another
>> stab at this the week after next.
> 
> No worries at all; how you getting on?

Thanks for the poke :-)  Fortunately I did have some quiet evenings last
week, and finally pushed a new branch derived from Peter and Erik's work:

https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard

Works with my GNUK token, both at initramfs stage and in the main
system.  The main difference is that only the pubring is copied to the
initramfs, not the whole GnuPG homedir.  See Messages #65 and #120 for
the rationale, and ‘debian/README.gnupg-sc’ for the HOWTO.

cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

Hi Chris,

On Fri, 14 Sep 2018 at 11:46:26 +0100, Chris Lamb wrote:
>> Sorry, I've been rather short on time lately; will try to take another
>> stab at this the week after next.
> 
> Sure thing. Do let me know whether it would help if you had specific
> hardware or things like that; I can get them sent out you. (Even if it
> would duplicate what you would already have.)

Thanks for the offer!  I don't think I *need* extra hardware, though: I
still have the GNUK token Niibe-san generously gave me some years ago,
and QEMU's USB device pass-through works like a charm :-)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#888916: Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Hey Guilhem,

> Sorry, I've been rather short on time lately; will try to take another
> stab at this the week after next.

No worries at all; how you getting on?


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#888916: Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Hey Guilhem,

> Sorry, I've been rather short on time lately; will try to take another
> stab at this the week after next.

Sure thing. Do let me know whether it would help if you had specific
hardware or things like that; I can get them sent out you. (Even if it
would duplicate what you would already have.)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#888916: Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

Hi Chris,

On Sat, 01 Sep 2018 at 11:50:47 +0100, Chris Lamb wrote:
>>> So, whilst I will be at DebCamp too (yay) I unfortunately won't have
>>> any hardware to test with and for various reasons I should keep
>>> commitments low at this point.
>> 
>> Sure thing!  I was planning to do some triaging anyway :-)  (#888916 has
>> been open for a while already and it's unfortunate that we didn't find
>> time to provide any follow-up yet.)
> 
> Just wondering what the current status of this was? We (with Purism hat
> on...) would love to get something we could start testing on, even if
> it were on a branch etc. etc.

Sorry, I've been rather short on time lately; will try to take another
stab at this the week after next.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#888916: Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Dear Guilhem et al.,

> > So, whilst I will be at DebCamp too (yay) I unfortunately won't have
> > any hardware to test with and for various reasons I should keep
> > commitments low at this point.
> 
> Sure thing!  I was planning to do some triaging anyway :-)  (#888916 has
> been open for a while already and it's unfortunate that we didn't find
> time to provide any follow-up yet.)

Just wondering what the current status of this was? We (with Purism hat
on...) would love to get something we could start testing on, even if
it were on a branch etc. etc.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Jonas Meurer]

Hi Chris,

Am 23.07.2018 um 14:42 schrieb Chris Lamb:
>> I don't think that adding a new binary package for OpenPGP smartcard
>> support is a good idea and would oppose to it
> 
> Might smartcard support require some smartcard-specific packaged
> dependencies that would 
> be solved somewhat elegantly by having a separate binary package?

Might be. Currently we suggest such extra dependencies for keyscripts.

Still, if we would split the gnupg smartcard keyscript into an own
binary package, we would have to do the same for decrypt_gnupg,
decrypt_opensc and decrypt_ssl. Which would mean four new binary packages.

> (Just to clarify, do you mean a new binary package as part of
> src:cryptsetup or a new binary package as part of some other
> hypothetical source package?)

Nope, just a new binary package as part of src:cryptsetup.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Hi Jonas et al.,

> I don't think that adding a new binary package for OpenPGP smartcard
> support is a good idea and would oppose to it

Might smartcard support require some smartcard-specific packaged
dependencies that would 
be solved somewhat elegantly by having a separate binary package?

(Just to clarify, do you mean a new binary package as part of
src:cryptsetup or a new binary package as part of some other
hypothetical source package?)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Jonas Meurer]

Hi Guilhem and Chris,

greetings from Portugal to Taiwan :)

Am 16.07.2018 um 19:28 schrieb Guilhem Moulin:
> I'm in favor of adding OpenPGP smartcard support to src:cryptsetup, but
> not more that one set of hook & boot scripts.

Ack.

> Since there is already #888916 open requesting merging of some initramfs
> scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
> polite of us cryptsetup package maintainers to review Rian's code as
> well before including anything.

Ack.

> I'm not sure it's worth shipping another “Architecture: all” binary
> package to src:cryptsetup, though (as opposed to including the keyscript
> to cryptsetup-run and the initramfs bits to cryptsetup-initramfs, like
> we're doing for decrypt_gnupg, decrypt_keyctl, decrypt_opensc, etc.).
> Sure, splitting cryptsetup-run and cryptsetup-initramfs further means we
> can assign more fine-grained dependencies, but in the end it'll just be
> a tiny shell script in each package, so is it worth the effort?  Also
> `update-initramfs -u` will complain if the required binaries (pcsd, gpg,
> etc.) cannot be copied; and the user has to install these to be able to
> set up the mapping in the first place.
> 
> (If we add another “Architecture: all” binary package we should also
> split cryptsetup-run and cryptsetup-initramfs for the sake of
> consistency.  Not sure it's worth the effort, but now-ish would be a
> good time to do this since we've already split cryptsetup-initramfs
> away.  I personally don't have strong feelings either way; CC'ing Jonas
> who might have a different opinion.)

I don't think that adding a new binary package for OpenPGP smartcard
support is a good idea and would oppose to it. If we followed that logic
(e.g. in order to allow more fine-grained dependencies), we'd have to
split other keyscripts into own binary packages as well. Also, given the
limited scope of keyscripts these days[1], I don't think that's worth
the effort and to much overhead.

Cheers,
 jonas

[1] The systemd cryptsetup helper implementation doesn't support
keyscripts and upstream refuses to implement support for it. So
we're left with keyscripts support in the initramfs and the SysVinit
init scripts.




signature.asc
Description: OpenPGP digital signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

On Mon, 16 Jul 2018 at 18:39:59 +0100, Chris Lamb wrote:
> So, whilst I will be at DebCamp too (yay) I unfortunately won't have
> any hardware to test with and for various reasons I should keep
> commitments low at this point.

Sure thing!  I was planning to do some triaging anyway :-)  (#888916 has
been open for a while already and it's unfortunate that we didn't find
time to provide any follow-up yet.)

> (Can we get something into shape on a branch for Kyle to test, or are
> the bug references you cite above enough?)

AFAIK we don't have anything to show other than the two bugs and the
link to the respective repositories, but hopefully we'll have something
after DebCamp.  I'll poke you once this is the case! :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Dear Guilhem,

> > My gut tells me we should incoropate OpenPGP support directly into
> 
> I assume you mean OpenPGP *smartcard* here

Yes, mea culpa; wasn't paying attention! :)

> Since there is already #888916 open requesting merging of some initramfs
> scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
> polite of us cryptsetup package maintainers to review Rian's code as
> well before including anything.

Of course and I totally agree with this and your following paragraphs.

So, whilst I will be at DebCamp too (yay) I unfortunately won't have
any hardware to test with and for various reasons I should keep
commitments low at this point.

(Can we get something into shape on a branch for Kyle to test, or are
the bug references you cite above enough?)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

Hi Chris,

On Mon, 16 Jul 2018 at 10:15:47 +0100, Chris Lamb wrote:
>> Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the
>> hook is copying private key material to the initramfs, but […]
> 
> My gut tells me we should incoropate OpenPGP support directly into

I assume you mean OpenPGP *smartcard* here: symmetric OpenPGP encryption
is supported 2:1.0.3-3 released 12 years ago (and that's the hook and
boot scripts which Peter then Erik forked) :-)

> Does that work for you in principle Guilhem? I'm assuming we can
> "just" merge in the aforementioned package (!) and fix up some of the
> issues, including the umask one you already outlined.
> 
> What would be the next steps here? :)

I'm in favor of adding OpenPGP smartcard support to src:cryptsetup, but
not more that one set of hook & boot scripts.

Since there is already #888916 open requesting merging of some initramfs
scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
polite of us cryptsetup package maintainers to review Rian's code as
well before including anything.

We've been quite busy lately with the massive refactoring and the couple
of regressions that followed, but I hope to take a closer look at both
proposals during DebCamp next week.  Naturally, help is welcome :-)

I'm not sure it's worth shipping another “Architecture: all” binary
package to src:cryptsetup, though (as opposed to including the keyscript
to cryptsetup-run and the initramfs bits to cryptsetup-initramfs, like
we're doing for decrypt_gnupg, decrypt_keyctl, decrypt_opensc, etc.).
Sure, splitting cryptsetup-run and cryptsetup-initramfs further means we
can assign more fine-grained dependencies, but in the end it'll just be
a tiny shell script in each package, so is it worth the effort?  Also
`update-initramfs -u` will complain if the required binaries (pcsd, gpg,
etc.) cannot be copied; and the user has to install these to be able to
set up the mapping in the first place.

(If we add another “Architecture: all” binary package we should also
split cryptsetup-run and cryptsetup-initramfs for the sake of
consistency.  Not sure it's worth the effort, but now-ish would be a
good time to do this since we've already split cryptsetup-initramfs
away.  I personally don't have strong feelings either way; CC'ing Jonas
who might have a different opinion.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Dear Guilhem,

> Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the
> hook is copying private key material to the initramfs, but […]

My gut tells me we should incoropate OpenPGP support directly into
Debian's src:cryptsetup simply based on ensuring its on-going
maintainability, etc. Especially important given that, for example,
an API change or other breakage might result in an unbootable system.

Does that work for you in principle Guilhem? I'm assuming we can
"just" merge in the aforementioned package (!) and fix up some of the
issues, including the umask one you already outlined.

What would be the next steps here? :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

On Mon, 09 Jul 2018 at 10:14:50 -0700, Kyle Rankin wrote:
> Given it is just a shell script, I would vote for incorporating OpenPGP
> smartcard support directly into cryptsetup-initramfs so it's available for
> users who want encrypted storage without having to know about a standalone
> package.

With my cryptsetup maintainer hat on, I don't mind either way.  In any
case we shouldn't ship multiple hooks providing essentially the same
functionalities (#888916, #903163).  I have a Gnuk Token so I should be
able to test and maintain this :-)

In general, rather than using our internal interface, authors of third
party hooks should either 1/ ask us to document and publish the bits
they need, or 2/ convince us to incorporate their hook & script into
cryptsetup-initramfs, effectively making us maintainers.

Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the
hook is copying private key material to the initramfs, but /initrd.img
is just a cpio archive which is created with mode 0644 minus umask… so
without additional protection in place [0] (which the README doesn't
mention) any local user can read the (hopefully symmetrically encrypted)
private key material!  It's not clear to me why they need the private
key files, but at the very least a loud warning should be shown if the
umask is too permissive.

-- 
Guilhem.

[0] For instance setting UMASK=0077 in /etc/initramfs-tools/initramfs.conf.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Kyle Rankin]

Given it is just a shell script, I would vote for incorporating OpenPGP
smartcard support directly into cryptsetup-initramfs so it's available for
users who want encrypted storage without having to know about a standalone
package.
 
-Kyle