[Gnuk-users] Using enable-hid-card-change

Mike M mikem at linux.com
Fri Nov 10 04:24:52 UTC 2017


> > When "ScrollLock" LED is set/unset (for example, by xset command), it is
> > interpreted as a message of card removal/insertion.
> 
> When I run the following xset command, everything is unchanged. But, I wonder
> if this is because my computer views the HID device LED as "Scroll Lock":

Sorry, I got hung up on "Num Lock" from your email to the GPG mailing list.
You clearly stated in your email to me that it was "Scroll Lock". My error.

But, my problem with the card being unavailable after turning on the "Scroll
Lock" still stands.

-- 
Mike M

On Thu, Nov 09, 2017 at 05:57:12PM -0700, Mike Monsivais wrote:
> > When "ScrollLock" LED is set/unset (for example, by xset command), it is
> > interpreted as a message of card removal/insertion.
> 
> That is really neat. Thank you for the answer.
> 
> I wonder if I am missing a step, or if it *is* broken right now. I have the
> latest commit pbd58997dc98d03ec3a140894b59651903fed1798 from Wed Nov 8,
> programmed on a token, but it appears to make the token unresponsive when I
> try to invoke the feature.
> 
> After generating some keys on a fresh token, I can see things are working:
> 
> 	$ gpg --card-status
> 	
> 	Reader ...........: Free Software Initiative of Japan Gnuk
> 	(FSIJ-1.2.6-87181927) 00 00
> 	Application ID ...: D276000124010200FFFE871819270000
> 	Version ..........: 2.0
> 	Manufacturer .....: unmanaged S/N range
> 	Serial number ....: 87181927
> 	Name of cardholder: User One
> 	Language prefs ...: en
> 	Sex ..............: male
> 	URL of public key : [not set]
> 	Login data .......: mikem
> 	Signature PIN ....: forced
> 	Key attributes ...: rsa2048 rsa2048 rsa2048
> 	Max. PIN lengths .: 127 127 127
> 	PIN retry counter : 3 3 3
> 	Signature counter : 4
> 	Signature key ....: 975F C5A0 54DC 0C35 DB97  23BD 8757 DA58 C579 6BF6
> 	      created ....: 2017-11-10 00:44:13
> 	Encryption key....: D1E6 0698 18FD 3AB9 1F89  365C 358F F32D 7E67 0454
> 	      created ....: 2017-11-10 00:44:13
> 	Authentication key: 3758 8FF6 5CA2 C7B9 E0E5  CF3F 91C8 E96A 1F00 F4D9
> 	      created ....: 2017-11-10 00:44:13
> 	General key info..: pub  rsa2048/8757DA58C5796BF6 2017-11-10 User One (User
> 	One) <userone at example.com>
> 	sec>  rsa2048/8757DA58C5796BF6  created: 2017-11-10  expires: 2017-11-12
> 	                                card-no: FFFE 87181927
> 	ssb>  rsa2048/91C8E96A1F00F4D9  created: 2017-11-10  expires: 2017-11-12
> 	                                card-no: FFFE 87181927
> 	ssb>  rsa2048/358FF32D7E670454  created: 2017-11-10  expires: 2017-11-12
> 	                                card-no: FFFE 87181927
> 
> I see the Gnuk Token HID device in xinput:
> 
> 	$ xinput
> 	⎡ Virtual core pointer                          id=2    [master pointer  (3)]
> 	⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
> 	⎜   ↳ SynPS/2 Synaptics TouchPad                id=11   [slave  pointer  (2)]
> 	⎜   ↳ TPPS/2 IBM TrackPoint                     id=12   [slave  pointer  (2)]
> 	⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
> 	    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
> 	    ↳ Power Button                              id=6    [slave  keyboard (3)]
> 	    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
> 	    ↳ Sleep Button                              id=8    [slave  keyboard (3)]
> 	    ↳ Integrated Camera                         id=9    [slave  keyboard (3)]
> 	    ↳ AT Translated Set 2 keyboard              id=10   [slave  keyboard (3)]
> 	    ↳ ThinkPad Extra Buttons                    id=13   [slave  keyboard (3)]
> 	    ↳ Free Software Initiative of Japan Gnuk Token      id=14   [slave keyboard (3)]
> 
> When I run the following xset command, everything is unchanged. But, I wonder
> if this is because my computer views the HID device LED as "Scroll Lock":
> 
> 	$ xset led named "Num Lock"
> 
> Interestingly though, when I turn on the virtual LED for "Scroll Lock", the
> token LED blinks rapidly, then returns to its regular blink pattern. But, the
> token is then unresponsive:
> 
> 	$ gpg --card-status
> 	gpg: selecting openpgp failed: No such device
> 	gpg: OpenPGP card not available: No such device
> 
> Most of the time I can get the card to show up again by turning off the
> virtual HID LED, but this doesn't always work. Sometimes I have to unplug the
> device and plug it back in:
> 
> 	$ xset -led named "Scroll Lock"
> 
> What do you think? Did I miss a step?
> 
> Would it be accurate to say that you are not enthusiastic about keeping this
> feature around? If it is broken are you interested in fixing it? Would you
> rather take it out? Or, would you only keep it if someone else stepped up to
> maintain it?
> 
> 
> Thanks for response. Also, thanks for the great software that lets me have an
> open source GPG token. :)
> 
> 
> -- 
> Mike M
> 
> On Wed, Nov 08, 2017 at 09:04:58AM +0900, NIIBE Yutaka wrote:
> > Mike M <mikem at linux.com> wrote:
> > > Could someone point me to documentation, or type me up a brief example, on how
> > > to use the `--enable-hid-card-change` feature?
> > 
> > Perhaps, it is not that useful.  I don't use the feature.  Even I don't
> > know if it works now.
> > 
> > My intention was controlling the token with no additional hardware, with
> > no additional software development.  It enables to ask the token
> > "removing the (virtual) card" and "inserting the (virtual) card".  I had
> > an idea to use this feature selecting a card among multiple cards (when
> > we will implement multiple cards support), but it has not achieved.
> > 
> > With --enable-hid-card-change, Gnuk has HID interface as well as CCID
> > interface.  The HID interface works as a keypad with LED.  It works as a
> > passive device to receive LED status change.  The macro
> > HID_LED_STATUS_CARDCHANGE defines which LED-change asks card
> > removal/insertion.  Default is ScrollLock LED.
> > 
> > When "ScrollLock" LED is set/unset (for example, by xset command), it is
> > interpreted as a message of card removal/insertion.
> > -- 



More information about the gnuk-users mailing list