Should Poldi lock the smart card when the screen locks?

[Franklin, Jason]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190924/fd5038f7/attachment.sig>