Page MenuHome GnuPG
Create Task
Maniphest T5702

Display prompt to user when YubiKey is waiting for touch confirmation
Closed, ResolvedPublic
Actions

Description

YubiKeys can be configured with a touch policy that requires the user to physically touch the device before it responds to a request. There is very little feedback to the user while it's waiting, other than a small and easily overlooked blinking LED on the YubiKey.

Would like to add a prompt to GPG while waiting for the YubiKey, using the existing pinentry tools, in order to make it more obvious that the user needs to take action.

A little more info/background can be found on my blog post: https://blog.unit410.com/security/2021/11/18/improving-yubikey-and-gnupg-usability.html

I've added a diff implementing this feature here: https://dev.gnupg.org/D542
(You can also find my patch on GitHub: https://github.com/joelnordell/gnupg/commit/1512c7b7fad6a9bee3ad9ca946c3b78988ceebb8)

What is the process for submitting this patch? Should I send it to the gnupg-devel@gnupg.org mailing list?

Related Objects
Search...

Event Timeline

joelnordell created this task.Nov 22 2021, 11:32 PM
• ikloecker added a subscriber: • ikloecker.EditedNov 23 2021, 8:28 AM

Just a quick comment regarding GitHub: This mirror of the gpg repo hasn't been updated since many months. Please get the sources of gpg directly from the original source: git://git.gnupg.org/gnupg.git. See https://gnupg.org/download/git.html

• ikloecker added a comment.Nov 23 2021, 4:07 PM

And you may want to read the section "Sending patches" of https://dev.gnupg.org/source/gnupg/browse/master/doc/HACKING.

joelnordell added a comment.Nov 23 2021, 4:35 PM

Thanks @ikloecker - I'll rebase to the original repo and send it to the email list.

• gniibe added a subscriber: • gniibe.Nov 29 2021, 1:50 AM

When the device-side feature was proposed, I had suggested to extend the protocol so that host side can know device side requires user interaction and prompt a user. But... the result was "it can be done with device side only".

Alas, it was not correct (for all cases). I don't know how we can move on from here.

• werner triaged this task as Low priority.Jan 18 2022, 7:18 PM
krakonos added a subscriber: krakonos.May 9 2022, 5:32 PM

Is there any progress on this issue? The code looks reasonable but does not apply on top of 2.2.35 (I didn't try master yet) and I didn't find a submission to the mailing list. I would really appreciate this patch, as it is a significant speedbump in my workflow.

• gniibe added a comment.EditedMay 19 2022, 7:45 AM

I put another change for T5099. This feature can be used for any keys, no matter if it's on Yubikey or not, no matter if token supports touch confirmation or not.

If it works for you, you can disable touch confirmation of Yubikey and use the feature (put a line "Confirm: yes" in your key under .gnupg/private-keys-v1.d) instead.

• gniibe added a parent task: T5984: gpg-agent interaction improvement (smartcard improvement #3).May 20 2022, 6:53 AM
• gniibe added a comment.May 25 2022, 4:12 AM

Besides, if lower layer solution is preferred, Yubikey can support having the special BWT value 0xff when bmCommandStatus = 2 (Time extension) is returned to host. The CCID driver recognizes this special value to prompt a user the dialog window.

• gniibe added a project: patch.May 25 2022, 4:12 AM
• gniibe added a subtask: T5099: Confirmation dialog for remote access (restricted extra socket).May 25 2022, 1:03 PM
• gniibe added a project: Restricted Project.May 25 2022, 1:11 PM

This feature is implemented in different way, by T5099.

The patch of this ticket entirely change all behavior of keys on card.

With the change by T5099, it is controlled by the Confirm field in a key, thus, a user has more fine-grained control.

So, I put 'Testing' tag in this ticket.

• gniibe closed subtask T5099: Confirmation dialog for remote access (restricted extra socket) as Resolved.Jul 12 2022, 3:30 AM
• gniibe closed this task as Resolved.Jul 12 2022, 7:10 AM
• gniibe claimed this task.
• gniibe removed a project: Restricted Project.

Please use the feature in 2.3.7 of T5099, instead.