Nitrokey / opcard-rs

OpenPGP card implementation
49 stars 1 forks source link

Default setting for "User PIN presentation only valid for one signature" (aka "forcesig" in GnuPG) #171

Open hko-s opened 1 year ago

hko-s commented 1 year ago

I'd like to propose discussing the default setting for the first byte of PW Status bytes (see https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.4.1.pdf#page=23)

I suppose there are reasonable arguments for either default value, and the OpenPGP card spec doesn't suggest a default setting. Briefly checking some of my test OpenPGP card devices shows that the default is not uniform between them: Gnuk defaults to "ask for User PIN each time", while a big proprietary vendor defaults to the other setting ("only one User PIN presentation required" - I checked devices of their two recent generations).

openpgp-rs defaults to requiring User PIN presentation for each signing operation.

My personal feeling is that PIN presentation on the host machine is a very weak mechanism, and there is very little value in requiring repeated PIN presentation (unless an external pin pad is used, which is of course not the case here). I think requiring repeated PIN presentation is mostly annoying/confusing to users, and doesn't add meaningful security benefits.

So my personal suggestion/preference would be to change the default to "One PIN presentation is sufficient for many SIG operations".

(Tagging @dvzrv because he stumbled over this on his new Nitro3 yesterday, and was first confused about what is going on, and then wondered about the space of possible configurations for PIN presentation and touch confirmation. These possibilities sadly seem to still be quite confusing to people who haven't spent quite a bit of time with OpenPGP card.)

sosthene-nitrokey commented 1 year ago

There's also the fact that the user PIN is separated between decrypt/aut (0x82) operations and the signature operation (0x81), which makes it that the PIN is required twice if you do both a decryption and a signature after, which may also be confusing I'm personally not certain I fully understand the reasoning behind this separation.

hko-s commented 1 year ago

Oh yeah, I've also been puzzled by that separation.

(I tell myself it might all make sense to me if I knew/understood the upstream ISO standards that OpenPGP card seems to borrow from. But that might just be wishful thinking :))

sosthene-nitrokey commented 1 year ago

Also to duplicate what I said in matrix here:

The choice to make "ask for User PIN each time" the default is not the result of specific deliberation or user feedback, but rather because it corresponds to the value 0 in the spec, so we're considering changing it given feedback that it is confusing.

sosthene-nitrokey commented 1 year ago

Regarding the original report @dvzrv, which software are you using to interact with the device? opgpcard I suppose?

I've always been puzzled by how frequently Gnupg prompts for some pins, especially the admin pin.

dvzrv commented 1 year ago

Regarding the original report @dvzrv, which software are you using to interact with the device? opgpcard I suppose?

I think current opgpcard does not yet allow me to toggle what gnupg refers to as "forcesig". But I have been using opgpcard to setup the touch policy and generally much prefer opgpcard over gnupg for interacting with smartcards any day of the year.

In general, I'd be happy if the card would by default behave the same way for encryption/authentication operations as for signing operations, so that password cache is used transparently across actions and touch policies can be set up right away/ more easily for the nitrokey3.

hko-s commented 1 year ago

Right, opgpcard is currently missing a subcommand to change that setting. I'll add one soon (but I'm not looking forward to coming up with a name for it :tired_face:).

dvzrv commented 1 year ago

To elaborate a bit further on my personal use-case:

I am signing a lot of files due to packaging for Arch Linux. Providing a password for each action is very cumbersome. More generically, this is also quite cumbersome when e.g. rebasing signed git commits though.