Mailing List Archive

Hello,

Franklin, Jason wrote:
> I'm continuing my work on the integration of Poldi and the KDE screen
> locker.

Well, It's not clear for me what kind of scenario you expect. Could you
please elaborate?

I'm writing some of my ideas in this message.

With current implementations (Poldi, gpg-agent+scdaemon) in mind, there
are three usages of OpenPGP card in possible scenario(s).

(1) Login authentication to user by Poldi with OpenPGP card
(2) In user session, use OpenPGP card by gpg-agent+scdaemon,
for gpg and/or SSH, possibly Scute.
(3) (possible) authentication to user by Poldi for screen locker,
to unlock screen

I think that those three can work well, when/if there are three
independent OpenPGP cards for each purpose. If you share a single
OpenPGP card among three purposes, you need to write a couple of hook
scripts, I suppose.

Sharing between (1) and (2), I think that there would be no/less
problem. It depends on how you invoke gpg-agent+scdaemon. You need to
make sure that scdaemon is no longer active after logout. In a
configuration of automatic socket activation of gpg-agent by systemd,
I'm afraid scdaemon remains some seconds after logout.

Sharing between (2) and (3) is problematic. I think you need to write a
hook script for screen locker, to make sure scdaemon will be killed
before screen is locked and Poldi can invoke new scdaemon for
authentication.

I'd say, sharing a single OpenPGP card for those multiple purposes is
not that simple. It's compilicated, because for (3), Poldi runs by user
privilege and it runs by system privilege for (1).


* * *

And... I think that a typical use case of such a user authentication
with Smartcard is something like:

* A smartcard is used for login authentication
* When it is removed from card reader, either the user session
is suspended by screen locker, or the user gets log out.
* In case of suspended session, when user insert the card again,
that user will be asked PIN for the authentication using the card.
Then, user session resumes.

In this use case, there should be some program watching the card reader
to detect card removal.

To achieve this kind of Smartcard use, I think that Poldi is not good
enough, because it simply handles basic authentication by OpenPGP card.

Perhaps, it's good to investigate how other smartcards are used to
support this scenario, by other software.

I have a quick look at:

http://opensc.github.io/pam_pkcs11/doc/pam_pkcs11.html

It seems that the use case above is supported by the PAM-PKCS#11 module.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hey,

I found it odd too. I have two thoughts on that.

* The reason for using a smartcard to unlock a computer is to have a
second factor. Locking the screen but leaving the card inside the
computer is therefore like disabling the second factor. One could argue
that you shouldn't do that anyway. Unplugging the card disables the
described problem.
* On the other hand, the situation now is like disabling both factors,
so this is quite bad, especially because people tend to just forget stuff...

What I was thinking about is a function in the OpenPGP Card standard
since version 3.1. It is possible to use the VERIFY command to reset the
access status to 'not verified' (see 7.2.2 of the current standard). [1]
This may does the trick. Of course, this solution would be limited to
OpenPGP Cards only.

@Niibe Gnuk does only support OpenPGP Card 2.1 (besides ECC keys) yet,
right?

Kind regards
Alex

[1] https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.3.1.pdf

On 20.09.19 18:39, Franklin, Jason wrote:
> Greetings,
>
> I'm continuing my work on the integration of Poldi and the KDE screen
> locker.
>
> Currently, when the user locks the screen and leaves their smart card
> inserted, the smart card remains unlocked. Thus, the screen can be
> locked and the user (or someone else!) can simply press <Enter> to
> unlock the desktop.
>
> My question is simple: What component should be modified to make sure
> the smart card is locked when the screen is locked, thus requiring the
> user to enter the GPG card passphrase to unlock the card and then the
> desktop?
>
> This would make the locker behave as expected.
>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Fri, 20 Sep 2019 12:39, jason.franklin@quoininc.com said:

> My question is simple: What component should be modified to make sure
> the smart card is locked when the screen is locked, thus requiring the

What you need to do is a

gpgconf --kill scdaemon

or if you want to send the command directly you send

scd killscd

to the gpg-agent. This way the scdaemon is terminated and the card
powered down. The next time a card is requested the gpg-agent will
restart scdameon and in turn it will ask for the PIN.

It would be nicer if we could have scdaemon running as a system
daemon but that is not easy to implement because we need take card of
users who have permissions to use the card reader but are not allowed to
start or re-configure a system daemon. However, we assume that a
smartcard is used only on single-user-at-a-time box and thus a system
daemon does not give a real advantage.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On 9/24/19 3:21 AM, Alexander Paetzelt | Nitrokey via Gnupg-devel wrote:
> Hey,
>
> I found it odd too. I have two thoughts on that.
>
> * The reason for using a smartcard to unlock a computer is to have a
> second factor. Locking the screen but leaving the card inside the
> computer is therefore like disabling the second factor. One could argue
> that you shouldn't do that anyway. Unplugging the card disables the
> described problem.

Negligent users do this kind of thing all the time.

I would argue that it is common enough that safeguards should be in
place to minimize the likelihood of system compromise when it inevitably
happens.

The current behavior is that putting the machine in a locked state
(locking the screen) only requires one factor to unlock the machine (the
card). This is not two-factor authentication, at least in the case of
the screen locker.

> * On the other hand, the situation now is like disabling both factors,
> so this is quite bad, especially because people tend to just forget stuff...

Precisely my point!

I am currently working with colleagues to provision Debian machines with
2FA using the GPG smart card.

It has become pretty obvious that most of the less technical users of
this configuration will habitually forget to remove their smart cards
when locking the screen.

> What I was thinking about is a function in the OpenPGP Card standard
> since version 3.1. It is possible to use the VERIFY command to reset the
> access status to 'not verified' (see 7.2.2 of the current standard). [1]
> This may does the trick. Of course, this solution would be limited to
> OpenPGP Cards only.

This sounds like a great idea. I would love to explore this further.

I am very curious to see what Niibe thinks about this.

--
Jason Franklin

On 24.09.19 17:23, Franklin, Jason wrote:
>
>> What I was thinking about is a function in the OpenPGP Card standard
>> since version 3.1. It is possible to use the VERIFY command to reset the
>> access status to 'not verified' (see 7.2.2 of the current standard). [1]
>> This may does the trick. Of course, this solution would be limited to
>> OpenPGP Cards only.
>
> This sounds like a great idea. I would love to explore this further.
>
> I am very curious to see what Niibe thinks about this.
>
>

My message was a bit misleading, I am afraid. I mixed up some things in
my head...

The proposed "maybe-solution" would only work with newer cards following
the OpenPGP Card standard (v3.1). I am not sure if you would like to use
this for a general purpose screen locker. Thus, I guess the solution
that Werner proposed is much better (killing scdaemon when locking the
screen), especially because I think it is working for all cards that
make use of poldi. So this would be a more general approach. Did you
already think about that solution?

Kind regards
Alex

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 9/25/19 8:13 AM, Alexander Paetzelt | Nitrokey via Gnupg-devel wrote:
> My message was a bit misleading, I am afraid. I mixed up some things in
> my head...
>
> The proposed "maybe-solution" would only work with newer cards following
> the OpenPGP Card standard (v3.1). I am not sure if you would like to use
> this for a general purpose screen locker. Thus, I guess the solution
> that Werner proposed is much better (killing scdaemon when locking the
> screen), especially because I think it is working for all cards that
> make use of poldi. So this would be a more general approach. Did you
> already think about that solution?

That is currently the method my colleague uses to solve the problem. I
had hoped that a more general solution could be deployed that would work
across desktop environments.

Perhaps this is not feasible.

--
Jason Franklin

On Wed, 25 Sep 2019 09:56, jason.franklin@quoininc.com said:

> That is currently the method my colleague uses to solve the problem. I
> had hoped that a more general solution could be deployed that would work
> across desktop environments.

The proposed method works on all envirinments, including Windows. What
did I miss?

What we could implement in addition is an option to reset the card after
some time of inactivity.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.