I pushed the change to master.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 28 2020
Feb 17 2020
Fixed in master.
Feb 12 2020
Jan 31 2020
Jan 30 2020
Jan 28 2020
I would prefer to have a procedure that do not reset PINs to their default values, but as long as all PINs are set to known and valid values when KDF is setup it will not make the token unusable after that, so it seems reasonable to me.
Or, #5 would be:
Jan 27 2020
@Amaud, I read your code in Python. IIUC, it asks users PW1, Reset Code, and PW3 to setup, just before registering KDF DO (as you describe in https://dev.gnupg.org/T3891#114950).
Jan 24 2020
Thanks for concrete cases. Sorry, not responding earlier. It was an experimental feature, firstly only available in Gnuk Token.
Jan 23 2020
I implemented the script described previsouly (https://dev.gnupg.org/T3891#114950) in the smartpgp-cli utility provided in the SmartPGP repository (see commit https://github.com/ANSSI-FR/SmartPGP/commit/4be0fa442b43c2bafd5f0171417ff68fd88cbe2d).
Jan 22 2020
Some users of ours wanted to use KDF with their OpenPGP smart cards. Could you tell when solution to this issue could be expected?
Additionally, is there any workaround for the current state? Perhaps based on T3823, or on derived [1]? To which values the PINs had to be set?
Jan 16 2020
There is no use cases for $SIGNKEYID.
$ENCRKEYID use case have been removed.
Jan 13 2020
Caching of the OpenPGP PIN while switching to and from PIV does now work in master
$AUTHKEYID use cases have been removed.
Jan 6 2020
Dec 23 2019
Dec 19 2019
Considering the concrete use case(s), it is more rational to support listing by capability.
Dec 18 2019
Nov 26 2019
This is actually unused code and it will never be called with ERR == 0. Will fix it in master anway.
[ Please do not post each compiler warning as a single report. That is just just too much overhead and we do see such messages ourselves if you would provide a bit more information. ]
Nov 18 2019
This will be in 2.2.18, closing.
Oct 29 2019
Sorry, it was simply my confusion (between GEMPC_PINPAD and GEMPC_EZIO).
Fixed now.
Oct 28 2019
Please test. When I can confirm that it is stable, I'll backport it to 2.2.
Oct 15 2019
@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC
@pow, thanks for a reference. But problem here is that there are multiple products with same name.
Oct 9 2019
Sep 25 2019
For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.
For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.
It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.
It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.
Aug 23 2019
Aug 22 2019
Note that rGd3f5d8544fdb needs to be backported to 2.2 but we will wait until we have better tested it.
Aug 21 2019
Aug 7 2019
Aug 6 2019
Jul 27 2019
The card was replaced by the vendor. It seems to be a problem with the specific card. All other cards so far worked well. The issue can be closed.
Jul 25 2019
I see your point (I am also the one who implements reader/token). That's reasonable argument.
Jul 22 2019
Thanks for clarification.
However, CCID_CMD_TIMEOUT should be then based on BWT value reported by the card/reader, as bulk_in() function will still timeout if BWT is longer than 5 seconds.
Thanks for pointing me in the right direction. I was confused by the hard-coded timeout value and got it all wrong.
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.
Jul 20 2019
I applied the following with gpg-connect-agent --hex:
Jul 19 2019
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.
Jul 18 2019
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.
Jul 9 2019
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)).
Jul 8 2019
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.
Jul 5 2019
I think we should not backport this to 2.2 - okay?
Jun 10 2019
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.
Jun 4 2019
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.
May 23 2019
Simply sending "KILLSCD" is implemented.
May 21 2019
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.
May 20 2019
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.
May 17 2019
@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).
May 16 2019
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.
Apr 9 2019
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.
Apr 8 2019
Apr 5 2019
I did lot of tests in the last weeks while working on gpg-card.
Mar 28 2019
Good that it works again for you.