Page MenuHome GnuPG

scute w/ gpg23: Support multiple cards/tokens, major update with KEYGRIP
Open, NormalPublic

Description

Scute until version 1.7.0 only supports a single device, and the code assumes it's only one.

Now, gpg23 offers better handling of multiple devices, we can update the implementation to support multiple devices.

Event Timeline

gniibe triaged this task as Normal priority.May 24 2022, 4:36 AM
gniibe created this task.

For testing, I can use these sites for client certificate authentication:
https://stackoverflow.com/questions/38095559/https-test-server-that-checks-client-certificates

For Chromium, we can use Mozilla's modutil to enable scute:
https://linuxkamarada.com/en/2019/09/26/setting-up-smart-card-authentication-on-google-chrome-chromium/

In my case, I did:
modutil -dbdir sql:.pki/nssdb/ -add "scute" -libfile /usr/local/lib/x86_64-linux-gnu/scute.so

I realized that we need to invent a way to represent KEYGRIP (40-byte string) in the scheme of PKCS#11; PKCS#11 uses fixed-size string (space padded) for it's label (32) and serialno (16). Basically, it identifies the device by slot number.

  • gpg-agent/scdaemon identifies a key by keygrip
  • scute should maintain slot number <-> keygrip table
  • in the PKCS#11 scheme, there are:
    • label
      • 32: "scdaemon"
    • manufacturer
      • 32: use string name of manufacturer
    • serial
      • use the 16 LSB of serial number
    • model
      • "OpenPGP"
    • CKA_ID
      • keygrip of 40-byte

Newer specification is here: https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/cs01/pkcs11-base-v3.0-cs01.html

In the branch https://dev.gnupg.org/source/Scute/history/t6002/ , by the commit rS123d617ebefe: Less administration of devices by scute., things has been changed.

It's experimental, only supports OPENPGP.3 keys.

I think that PKCS#11 specification has some (irrelevant/wrong/unclear or not useful) assumptions for user<->application<->system interactions, how devices are controlled by a system and by a user.

Wise use of the specification would be that we don't try to clarify those interactions (which leads to complicate implementations), but to pick up things what we can do in meaningful and clear semantics for users.

In the branch, now, multiple devices are supported, but Scute does not watch or care about the device insertion/removal at all. This change allows gpg-agent to prompt the insertion of the device when not yet inserted. Devices are under control of scdaemon, but not under Scute. This may greatly simplify things.

This change is not perfect. It cannot support a use case where an application wants to know/detect device removal to close its session.

Other than that, it works pretty well.

I found this page:
https://firefox-source-docs.mozilla.org/security/nss/legacy/nss_tech_notes/nss_tech_note2/index.html

And I do:

NSS_DEBUG_PKCS11_MODULE=scute NSPR_LOG_MODULES=nss_mod_log:4 NSPR_LOG_FILE=/tmp/scute.log chromium

to test.

The change requires "KEYINFO --list" command. This is not available through remote access of gpg-agent (extra socket).

We could change how device keys are listed. Currently, Scute does KEYINFO --list, then asking gpgsm for each certificate.

Currently, there are two ways for Scute to get certificates;

  • By gpgsm
  • By SCD READCERT command of gpg-agent

But the latter is also restricted (not available through remote).

Kleopatra uses SCD READCERT for reading certificates from the PIV app. This is used to import the certificates stored by the PIV app. I'm not sure whether this is really needed. Maybe we could/should use "learn card" for this instead.