GPG Input/output error on Mac OS X

Hi,
I’m having issues using a cryptostick v2 (storage version) with gpgtools (both stable and nightly) on macosx 10.9.4.
The same stick/card/gpg-key works well under a debian system.
I’m not an advanced user on mac, so I just followed the installation instructions provided.

The reader and card are correctly seen by the mac, the stub is already into my keychain and card details well read:

[code]$ gpg2 --version
gpg (GnuPG/MacGPG2) 2.0.25
libgcrypt 1.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

$ gpg2 --card-status
Version …: 2.0
Manufacturer …: test card

Login data …: lucab
Signature PIN …: forced
Key attributes …: 4096R 4096R 4096R
Max. PIN lengths .: 0 0 0
PIN retry counter : 0 0 0
Signature counter : 0
Signature key …: 3B04xxxx …
Encryption key…: A43Cxxxx …
Authentication key: 96C7xxxx …
General key info…: pub 4096R/52078xxxx …
sec# 4096R/4F3Bxxxx …
ssb> 4096R/6BA0xxxx …
ssb> 4096R/5207xxxx …
ssb> 4096R/675Cxxxx …

$ gpg2 -K
sec# 4096R/4F3B… 2014-xx-xx
uid X X x@x.xxx
ssb> 4096R/6BA0xxxx 2014-xx-xx
ssb> 4096R/5207xxxx 2014-xx-xx
ssb> 4096R/675Cxxxx 2014-xx-xx
[/code]
However, trying to use it results in a I/O failure:

$ gpg2 -s test.txt 
gpg: signing failed: Input/output error
gpg: signing failed: Input/output error

I am asked the PIN, gpg pinentry correctly reads it and unlock the card (I’ve also tried with a bad PIN and I get proper rejection).
Signature process fails after some seconds. I see the green LED on, so the card is actually doing some computation.

Any idea? How can I debug this a bit more?

Hi! Did you install the latest firmware update? The installation details have been mailed to you on 9th July.

Yes, this is the updated firmware:

Crypto Stick Storage status

Firmware version     0.6
Unencrypted volume   READ/WRITE mode 
Encrypted volume     not active
SD change counter    2
SD erase counter     0

A couple of additional notes:

  • These are copies of existing 4096R keys, which have been imported on the card
  • The green led stays on for a couple of seconds more at the time when the I/O error happens (some timeout too short?)
  • Some other details of --card-status are wrong when read on Mac

For example, I just noticed that (Max. PIN lengths, PIN retry counter, Signature counter) are always incorrectly read to zero (proper values are read on linux).

Could you test it with 2048 bit keys, please?

Sorry for the delay. I did a bit testing with different setups and keys, and the results are as follow:

  • Generating 2048R keys fails on Mac with a I/O error
  • Trying to make a signature using 2048R keys (generated on debian) fails on Mac with an I/O error
  • Generating 1024R keys worked on Mac
  • However, using those 1024R keys on Mac still fails with an I/O error
  • All above usecases works fine on my debian laptop

Before wiping the 4096R keys, I did a quick test on another Mac and the result was the same.

It may also be unrelated, but dmesg reports the following:

As this was a bit sad, I did a couple of deeper tests and I now believe that I’m hitting some races/mis-caching on the Mac toolchain.
First of all, I had opensc installed and it was causing most of the issues: removing it, I’m now able to generate and use 1024R keys, with some degree of success also with 2048R. Moreover, I’ve also been able to properly use the original 4096R by basically killing everything related to gpg and smartcards (gpg-agent, scdaemon, etc.), running and gpg2 --card-status and right after that using the keys.

While this is far from a working setup (gpgtools integration is now completely broken), at least now I’ve seen it working and may be able to restrict the issue a bit more.