Home → Stable →

gpg-agent stops working after OSX Upgrade to Yosemite

Showing page 2 out of 2. View the first page

1. Support Staff 31 Posted by Luke Le on 17 Jan, 2015 04:23 PM

   

   Hi Samuel,

   is this the entire output you can find in your scdaemon.log file?
   I'm curious because there was much more Info in Bartoszs

   • Edit

2. 32 Posted by Stephen Oliver on 17 Jan, 2015 06:26 PM

   

   @Samuel Reed yes, my card is a Yubikey NEO

   @Luke Le GPG doesn't seem to be defaulting to the internal CCID driver in practice here. If it were, anyone with a natively supported card wouldn't even notice PCSC issues. So if it's supposed to be doing that, perhaps that is itself another bug that would resolve some of the problems people are having? I assumed that it was using PCSC by default for a reason, perhaps not.

   Anyhow, I'm happy to report that my crude hack appears to be working perfectly. 9 hours after I set it up, using the card via GPG and SSH both still work. I've never seen the system go 9 hours without needing to remove the card and kill scdamon and friends. There are some downsides (read the end), but at my company we are happy to accept them for now as we rely on OpenPGPCards for a lot of things.

   This is a bit long, so here's the short version of the hack if you know what you're doing: disable Apple's ifdhandler service with launchctl, restart scdaemon & gpg-agent. This leaves GPG no option but to use the internal driver instead of Apple's PCSC. Please test and report back, but it seems to be working great here with our Yubikey NEO's.

   My theory was that by default, GPG (or at least the GPGTools version, on this platform) is actually trying to use the card via PCSC first, and on a normal Yosemite system PCSC works well enough that GPG finds and proceeds to use it that way. And soon afterward, it stops working as everyone has now seen. The internal CCID driver seems to only be used if it can't find the card another way.

   So I figured if I can ensure that GPG can't find the card via Apple's broken PCSC, it should then try its internal CCID driver and talk to the card directly using libusb (which GPGTools includes).

   To test my theory, I first setup verbose logging in scdaemon.conf and inserted my card to see what it logs normally when PCSC is being used:

   2015-01-17 01:02:49 scdaemon[69789] listening on socket `/tmp/gpg-VCNfMw/S.scdaemon'
   2015-01-17 01:02:49 scdaemon[69789] handler for fd -1 started
   2015-01-17 01:02:50 scdaemon[69789] pcsc_control failed: invalid parameter (0x80100004)
   2015-01-17 01:02:50 scdaemon[69789] pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65538
   2015-01-17 01:02:50 scdaemon[69789] reader slot 0: not connected
   2015-01-17 01:02:50 scdaemon[69789] slot 0: ATR=3B FA 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 4E 45 4F A6
   2015-01-17 01:02:50 scdaemon[69789] AID: D2 76 00 01 24 01 02 00 00 06 02 10 30 06 00 00
   2015-01-17 01:02:50 scdaemon[69789] Historical Bytes: 00 73 00 00 80 00 00 00 00 00 00 00 00 00 00
   ...
   

   Note what it says about reader slot 0, for later. It finds the card, the ATR is correct for this Yubikey NEO model (pre-3,000,000 serial number, no PIV/U2F applets).

   Running pcsctest returns the following:

   MUSCLE PC/SC Lite Test Program
   
   Testing SCardEstablishContext    : Command successful.
   Testing SCardGetStatusChange 
   Please insert a working reader   : Command successful.
   Testing SCardListReaders         : Command successful.
   Reader 01: Yubico Yubikey NEO OTP+CCID
   Enter the reader number          : 01
   Waiting for card insertion         
                                    : Command successful.
   Testing SCardConnect             : Command successful.
   Testing SCardStatus              : Command successful.
   Current Reader Name              : Yubico Yubikey NEO OTP+CCID
   Current Reader State             : 0x54
   Current Reader Protocol          : 0x1
   Current Reader ATR Size          : 20 (0x14)
   Current Reader ATR Value         : 3B FA 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 4E 45 4F A6 
   Testing SCardDisconnect          : Command successful.
   Testing SCardReleaseContext      : Command successful.
   

   So PCSC works and anything using it can find the card that way at the moment.

   I then unplugged my card, killed scdaemon and gpg-agent, and setup my crude hack: disabling Apple's ifdhandler.

   Note: pidof comes from Homebrew, it's not a standard part of OS X

   kill -9 `pidof scdaemon` && kill -9 `pidof gpg-agent`
   sudo launchctl unload /System/Library/LaunchDaemons/com.apple.ifdreader.plist
   

   This should prevent anything from being able to find and use a card via Apple's PCSC implementation.

   Running pcsctest confirmed this.

   I then ran a GPG command to allow scdaemon and gpg-agent to start again and try to find the card, and this is what scdaemon logged (I've highlighted the important line):

   2015-01-17 01:05:36 scdaemon[70971] listening on socket `/tmp/gpg-6oenRV/S.scdaemon'
   2015-01-17 01:05:36 scdaemon[70971] handler for fd -1 started
   -------------------------------------------------------------------------------------------------
   2015-01-17 01:05:36 scdaemon[70971] reader slot 0: using ccid driver
   -------------------------------------------------------------------------------------------------
   2015-01-17 01:05:36 scdaemon[70971] slot 0: ATR=3B FA 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 4E 45 4F A6
   2015-01-17 01:05:36 scdaemon[70971] AID: D2 76 00 01 24 01 02 00 00 06 02 10 30 06 00 00
   2015-01-17 01:05:36 scdaemon[70971] Historical Bytes: 00 73 00 00 80 00 00 00 00 00 00 00 00 00 00
   2015-01-17 01:05:36 scdaemon[70971] Version-2 ......: yes
   2015-01-17 01:05:36 scdaemon[70971] Get-Challenge ..: yes (255 bytes max)
   2015-01-17 01:05:36 scdaemon[70971] Key-Import .....: yes
   2015-01-17 01:05:36 scdaemon[70971] Change-Force-PW1: yes
   2015-01-17 01:05:36 scdaemon[70971] Private-DOs ....: no
   2015-01-17 01:05:36 scdaemon[70971] Algo-Attr-Change: no
   2015-01-17 01:05:36 scdaemon[70971] SM-Support .....: yes (3DES)
   2015-01-17 01:05:36 scdaemon[70971] Max-Cert3-Len ..: 1216
   2015-01-17 01:05:36 scdaemon[70971] Max-Cmd-Data ...: 255
   2015-01-17 01:05:36 scdaemon[70971] Max-Rsp-Data ...: 255
   2015-01-17 01:05:36 scdaemon[70971] Cmd-Chaining ...: yes
   2015-01-17 01:05:36 scdaemon[70971] Ext-Lc-Le ......: no
   2015-01-17 01:05:36 scdaemon[70971] Status Indicator: 00
   2015-01-17 01:05:36 scdaemon[70971] GnuPG-No-Sync ..: no
   2015-01-17 01:05:36 scdaemon[70971] GnuPG-Def-PW2 ..: no
   2015-01-17 01:05:36 scdaemon[70971] Key-Attr-sign ..: RSA, n=2048, e=17, fmt=crt+n
   2015-01-17 01:05:36 scdaemon[70971] Key-Attr-encr ..: RSA, n=2048, e=17, fmt=crt+n
   2015-01-17 01:05:36 scdaemon[70971] Key-Attr-auth ..: RSA, n=2048, e=17, fmt=crt+n
   2015-01-17 01:05:36 scdaemon[70971] updating slot 0 status: 0x0000->0x0007 (0->1)
   2015-01-17 01:05:36 scdaemon[70971] sending signal 31 to client 70970
   2015-01-17 01:05:48 scdaemon[70971] DBG: asking for PIN '||Please enter the PIN'
   2015-01-17 01:05:52 scdaemon[70971] operation auth result: Success
   

   So despite crippling the system PCSC implementation, GPG still found the card and can use it. If I then use the disable-ccid config option in scdaemon.conf to turn off GPG's internal driver and restart the daemon, the card stops working again as expected, because it is the only thing left allowing it to work.

   There does not appear to be any obvious configuration setting provided by GPG to make sure it tries the internal CCID driver first (perhaps there's a good reason for that? are there downsides to avoiding PCSC when it is available?), but I haven't looked very hard either or tried anything else. So perhaps there is a better way than what I have done, which has real and significant downsides: PCSC no longer works at all, either with other cards or even other applets on the card GPG is using, like the PIV or U2F applets on a newer Yubikey NEO. If you only need to use natively supported GPG cards as we do, then this is a temporary solution that seems to work.

   To undo the change and put the system back to its normal configuration, just unplug your card, load ifdhandler again, and kill scdaemon & gpg-agent:

   sudo launchctl load /System/Library/LaunchDaemons/com.apple.ifdreader.plist 
   kill -9 `pidof scdaemon` && kill -9 `pidof gpg-agent`
   

   That should return things to "normal", though other services (com.apple.ctkd perhaps?) may need to be restarted afterward too.

   • Edit

3. 33 Posted by Samuel Reed on 17 Jan, 2015 06:46 PM

   

   @Luke Yes, that was the whole of the output.

   @Stephen Absolutely fantastic post! I followed your instructions and now pscstest fails as expected yet gpg --card-status is still working. Let's see how it performs long-term. Thankfully I as of yet have no need for other applets.

   • Edit

4. 34 Posted by Stephen Oliver on 17 Jan, 2015 06:56 PM

   

   That should say ifdreader up there any place it says ifdhandler, i'm so used to seeing ifdhandler at the moment my eyes skipped right over the actual name of the launchd service, sorry about that :)

   • Edit

5. Support Staff 35 Posted by Luke Le on 17 Jan, 2015 07:56 PM

   

   Hi Stephen,

   Thank you for this in depth explanation. What strikes me as odd however is the fact that GPG should not default to the ccid driver. I just checked the source and the first that is tried is always the ccid driver unless disable-ccid is given. After that I started getting curious if there might be a problem with our scdaemon, since there is one other case where ccid driver isn't the first to be checked and that is if GPG is compiled without libusb support which our version should be. So I disassembled the scdaemon binary from Beta 4 and the code which tries the ccid driver First is clearly and correctly there.

   Not sure what is going on at the moment but we'll keep looking.

   • Edit

6. 36 Posted by bartosz.malkows... on 20 Jan, 2015 06:47 AM

   

   When I unload /System/Library/LaunchDaemons/com.apple.ifdreader.plist then:
   

   $ gpg --card-status
   gpg: selecting openpgp failed: Card error
   gpg: OpenPGP card not available: Card error
   

   pcsctest result:

   MUSCLE PC/SC Lite Test Program
   
   
   
   
   Testing SCardEstablishContext    : Command successful.
   Testing SCardGetStatusChange
   

   and it hangs.

   I use Yubikey NEO 3.0.4.

   • Edit

7. 37 Posted by Stephen Oliver on 21 Jan, 2015 03:20 PM

   

   Bartosz,

   Which version of OS X and GPGTools are you using? I'm testing with OS X 10.10.1 and GPGTools nightly builds on a NEO with 3.1.2 firmware (and OpenPGPApplet 1.0.8 but that shouldn't affect anything here). GPGTools betas should be fine though.

   Which mode is the NEO in at the moment? If you haven't changed it, it shouldn't be a factor here either so don't worry about it.

   I do see gpg --card-status say card error when I first plug in the card, but the 2nd time it works and then continues to work for as long as I leave it plugged in (multiple days at this point). Everything that actually uses the card works immediately after the card is plugged in though.

   If Apple's PCSC isn't working, pcsctest should give you a result like this:

   MUSCLE PC/SC Lite Test Program
   
   Testing SCardEstablishContext    : Service not available.
   

   So something isn't quite right there.

   Take the card out for a few seconds, then make sure there aren't any com.apple.ifdreader or scdaemon processes running in Activity Monitor (kill any if you find them), then plug your card in and see if another com.apple.ifdreader process starts. If not, test gpg again and let me know what happens :)

   • Edit

8. 38 Posted by bartosz.malkows... on 22 Jan, 2015 06:19 AM

   

   I use OSX 10.10.1.
   GPGTools Beta 4.

   After few plog off&in it seems to work. gpg shows card status.
   I have no idea if it is important or not, but pcsctest says Command successful. instead of Service not available..
   ps aux doesn't shows anything matching to ifd..

   • Edit

9. Support Staff 39 Posted by Steve on 26 Jan, 2015 11:00 PM

   

   Hi all,

   this issues should be fixed. Could you please download and install our latest nightly build and see if the problem persists. That page also has sig and SHA1 to verify the download.

   All the best, steve

   Disclaimer: This is a development version which has not been thoroughly tested yet - bugs or crashes are to be expected. Thanks for helping us test.

   • Edit

10. 40 Posted by Yubkikey Neo-N on 29 Jan, 2015 03:08 PM

    

    Steve,

    I can confirm this works now! Thank you so much!

    • Edit

11. 41 Posted by Stephen Oliver on 30 Jan, 2015 04:01 PM

    

    I re-enabled Apple's ifdreader, killed gpg-agent and scdaemon, and manually downloaded the newest nightly build (there's a note in the update window about the automatic update potentially failing, and it did 100% of the time).

    The newest nightly builds do allow my card to continue working 12+ hours after the GPGTools update is installed, even with scdaemon using PCSC rather than the internal CCID driver + libusb.

    gpg --card-status and ssh connections are working, and I haven't had to kill gpg-agent and friends or remove my card since the update.

    • Edit

12. Support Staff 42 Posted by Steve on 02 Feb, 2015 10:22 PM

    

    Hey Stephen and N,

    thank you both for the update. Closing, make sure to get in touch should you encounter further hickups.

    All the best,
    steve

    • Edit

13. Steve closed this discussion on 02 Feb, 2015 10:22 PM.