I realized that it's a product of token. Then, I suggest that implementing time extension correctly, if some operation doesn't finish in BWT (block waiting time).

In general, if it requires more time, a reader can reply with time extension.

What's Trustica Cryptoucan?
In general, if it requires more time, a reader can reply with time extension.

FYI, we have "factory-reset" command in gpg --card-edit; It is not enough for a card to have admin locked state, but it requires normal user locked state, too.

I applied the following with gpg-connect-agent --hex:

I do not wonder, that you face difficulties to reproduce it. It happened only with one card from my six cards; so five cards working fine. Therefore, I thought that this particular card was may dead at arrival and I contacted the vendor. They refused to replace it with the comment, it would be a well known issue. Do you know a test where I can demonstrate that the card is dead at arrival?

It responds somehow, but the content has invalid data of (bChainParameter=0x04):

2019-07-05 09:36:41 scdaemon[71407] DBG: chan_17 -> S LOGIN-DATA aheinecke
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 9
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 21
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 40 05 00 CA 00
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0016]  6E 00 E1
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 4
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 21
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bStatus ...........: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bChainParameter ...: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 82 00 82
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 9
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 22
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 40 05 00 CA 00
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0016]  6E 00 E1
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 4
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 22
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bStatus ...........: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bChainParameter ...: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 82 00 82
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 9
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 23
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 40 05 00 CA 00
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0016]  6E 00 E1
2019-07-05 09:36:46 scdaemon[71407] DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT
2019-07-05 09:36:46 scdaemon[71407] ccid_transceive failed: (0x1000a)
2019-07-05 09:36:46 scdaemon[71407] apdu_send_simple(1) failed: card I/O error

After the cancellation, the card reader seems being screwed up:

It is canceled:

2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 19
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bStatus ...........: 64
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bError ............: 239
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: CCID command failed: PIN cancelled
2019-07-05 09:36:41 scdaemon[71407] DBG: dismiss pinpad entry prompt
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> INQUIRE DISMISSPINPADPROMPT
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 <- END
2019-07-05 09:36:41 scdaemon[71407] verify CHV2 failed: Invalid response
2019-07-05 09:36:41 scdaemon[71407] operation decipher result: Invalid response
2019-07-05 09:36:41 scdaemon[71407] app_decipher failed: Invalid response
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> ERR 100663372 Invalid response <SCD>

Please note that key generation is takes time unusually longer from a viewpoint of card reader.
It is possible for a card reader to give up the execution of key generation command as timeout.

I am trying to reproduce your problem with my 3.3 card using my TTXS card reader.

I use the internal driver.

Are you using pcscd (is that process running) or the internal driver.? Please try the latter if you are not already using it.

I pushed my change of rGc51a5685554a: scd: ccid-driver: Initial getting ATR more robustly..
With TTXS, scdaemon correctly recovers from the error.

When the computer is going to suspend, the scdaemon receives a message from USB layer as the interrupt transfer is shutting down, then scdaemon considers it's removal of device/card.
But in case of suspend (and the device does not support USB suspend), USB port is kept with the power.
So, it keeps running actually.

Here are results of my experiment with Intel NUC computer (which supports S4 (and S3)).

No. I intentionally select: Not-backporting this feature.
The feature is added for Yubikey, in the specification.
Use of the feature by Data-Object is not that so useful.

I think we should not backport this to 2.2 - okay?

Thanks a lot @gniibe for this change.
I do understand and share your concerns, nevertheless are there, in my opinion valid reasons to be able to have a backup or duplicate, especially on the same or similar media type.
Consider for example giving multiple devices a chance of common interaction, using the keys for backup encryption etc. - I think there are several possible use-cases which can benefit from this.

I see the regression of gpgconf. I wonder if it's better to fix gpgconf side, too.

I see a regression with your fix. This option is even controllable with gpgconf at the basic level. It would be better to make it a dummy option.

I meant, 'card-timeout' was not intended for controlling caching PIN on card. It was for "DISCONNECT" command support.
I'm going to remove questionable documentation.
Closing.

While it's not recommended, current master has a support of sharing same raw key materials. I think that it now works (I don't try, though).
Closing.

Simply sending "KILLSCD" is implemented.

In master, I pushed a change, closing.

For future, it would make sense applying your patch, but I wonder if it works on macOS.
Let me check.

When having a backup media, I'd recommend completely different one (for example, on paper using paperkey to be stored in a locker in basement), which requires different method for recovering. Brains may be easily confused when same private key material exists in multiple similar devices.

Thanks for this @gniibe. I have long been frustrated by trying to save the correct "stubs" to have my keyring point at two different smartcards. It was common and even advocated in my former community to place one's master key on a separate smartcard (certify capability), with a different one designated for daily usage.

Thanks Gniibe San for explanation.

@blades: This feature will be available in GnuPG 2.3, which is planed to be released this year.
For Debian, Buster will come with GnuPG 2.2.12. After release of GnuPG 2.3, backport might be available (like GnuPG 2.2.x is available as backport for Stretch).

Helo and forgive me for the ignorance, Iam a new.
I subscribed to this topic because I need a fix like that, I have 2 yubikeys with same subkeys...
Now how is possible to install from master; It's about a debian based distro. Also, when this will be pushed for updates via apt-get;
Thank you.

We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.

I did lot of tests in the last weeks while working on gpg-card.

Good that it works again for you.

I don't anymore think that it makes sense to fix it. Further there is no cache for PINs; that is entirely up to the card.

This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...

Thanks so much your helps.
With new version 3.1.6, I can generate key on Kleopatra tool and use key stored in smartcard.

There was indeed a problem. With a test card I could reproduce the issue and fix it.

Thanks for fixing that.

That's my badness. In wait_child_thread, assuan_release may cause thread context switch to agent_reset_scd which accesses scd_local_list; This access should be serialized.
And... in start_scd, calling unlock_scd should be after unlocking start_scd_lock.

Does not happen in 2.2. Additional requirement to test this bug in master: Another connection to the scdaemon must be open. For example running scute or, easier, call "gpg --card-edit" and keep it open.

Gnuk implements the feature, and newer GnuPG shows a dialog to request pushing the ack button.

Interaction will be something like this:

Priority is high, because Gnuk Token requires this feature for testing its implementation.

Thank you for the clarification. For now, I'll modify our implementation to use shorter length representation and close this bug as Invalid.
However, I'm still not convinced that using hard-coded arguments is the right way to handle requests. I'll do some more testing and if I discover a legitimate use-case that requires long APDUs, I'll reopen the issue.

Thanks for the information.

In our implementation, DO 0x6E contains:

I don't understand the reason why 0x6E (Application Related Data) can be so long. What OpenPGP card implementation do you have?

Here is a sequence of operations/commands that permits to setup or update KDF-DO and align PIN codes accordingly:

Now there it gets complicated. According to the card software author in 3.3 and even 2.2 there is a fix. BUT there was a small amount of cards already created in 3.3 without the fix. Nobody ever told my how to diferentiate them.
There is no Version 3.3.1 you can by - it is only 3.3. So you can buy one and hope you have a good one.
At least this is my understanding.

Does v3.3.1 fix this? (The release notes for it seem to imply that's not the case.)

@nitroalex Perhaps, creating new ticker is better for this topic.
In the current OpenPGP card specification, there is no way for an application (except having a list of card implementation information) to know wich algo and which curve is supported or not.
So, what an application does is try and error.
I don't like this situation, but I don't know how we can modify the specification.

Well, I surely would agree (and this is only a proposal anyway), but my point here is, that OpenPGP Card does not support Curve 25519, so that one *have to* choose between those other two. Considering me a tinfoil hat person, I would rather not choose NIST, as many others wouldn't too.

Neither Brainpool nor NIST curves make any sense unless there is an organizational policy requirement. Thus the --expert requirement is the Right Thing (tm).

works just fine, thx!

For the situation where PINs are not factory setting, given the specification, I don't know how to achieve "to align all PWs and the KDF-DO with correct values"; It might depend on card's implementation.

You are right about the fact that multiple steps could result in unusable cards in case of power down before all commands have been issued. Nevertheless, in practice, these commands would involve very few treatments on the token (i.e. no cryptographic operation or heavy data transfer) and it should really not take long to complete the three steps (admin PIN update, user PIN update, KDF-DO update).

Workaround is implemented in 2.2.6.

Fixed in 2.2.6.

My interpretation of the specification is different.
By requiring the condition of setting KDF-DO (it is only valid to setup KDF-DO when PINs are factory setting), Gnuk works well with current "kdf-setup".
If the procedure of setting KDF-DO includes multiple steps with KDF-DO update and PIN update, there is a risk of power down which results unusable card.