Hello again,
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 10 2018
Mar 9 2018
Yeah, this is better, we got apdu_get_status => sw=0x0 status=7 and I can auth with this version as usual. After sleep-wake cycle it would however fail with pcsc_transmit failed: reset card (0x80100068). Logs attached.
Thanks a lot for your testing. So, apparently, the PC/SC behavior is different between GNU/Linux and Windows.
Thus, I pushed another change: rG1e27c0e04cd3: scd: More fix with PC/SC for Windows.. Please test this. (Both of previous version and this version work well on GNU/Linux for operations not including suspend/resume with Yubikey and Gnuk Token, while my Yubikey with PC/SC doesn't work well for suspend/resume.)
Mar 8 2018
Thanks, this version of scdaemon executes.
Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).
I realized that: once KDF-DO is written to smartcard/token, factory-reset command won't work because it assumes standard PIN format than hashed.
Sorry again. My script was still wrong (didn't work).
Mar 7 2018
It doesn't work because I did mistake for the salt of reset code, it should be 8-byte instead of 4-byte.
Here is a fixed version, which I tested with Gnuk 1.2.8:
Mar 6 2018
@gniibe it seems the patched scdaemon.exe is 64 bit executable and it requires libassuan6-0.dll. However I got installed 32 bit version of gpg that only has incompatible libassuan-0.dll. I scanned whole computer for the missing lib, skimmed your ftp for 64 bit binaries and looked into gpg4win installer to find it, but no luck. There is also libassuan github repo, but I would like to avoid building the dll myself; there would probably be more than one dll to build anyway.
If possible, please try with this (patched version of scdaemon):
Something like this script should be implemented by gpg frontend:
I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:
The reference is: https://stackoverflow.com/questions/11294638/how-to-use-scardgetstatuschange-correctly-on-windows-8
It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.
Mar 5 2018
@werner there had to be some mix up, as the log snippet is not mine.
This seems to be the relevant part of the log:
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed 2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip 2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d) 2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0 2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed
This would be a good solution.
This has also the advantage that we could list the possible curves and let the user select them.
So should we revert this patch and replace it by an explicit command to switch the card to ECC?
Feb 26 2018
It's in GnuPG 2.2.4, now.
It's a bug in the OpenPGP card implementation.
I put an entry in Wiki: https://wiki.gnupg.org/SmartCard#Known_Bug.28s.29_of_OpenPGPcard
Feb 13 2018
Feb 6 2018
Jan 23 2018
My apologies , after the system upgrade, multiple things around gnupg broke and I got distracted and forgot to check the fetched public key, which somehow didn't contain subkey data.
This particular issue has been resolved by updating upstream public key.
Thank you for your assistance.
Jan 22 2018
I use Debian stretch. It works for me with GnuPG 2.2.4.
The stub is created at the time when --card-edit accesses the card.
When I type RET after fetch command, it shows the key information.
Jan 12 2018
Oh dear what an evening and morning. I reversed the facts I reported. Sure 2.1 is borken - that is the whole point. ( I realized that only after install 2.2.4 and generating fresh keys). To avoid confusion I will delete my last comments.
Duplicate of T3576
@werner It's just simple; With --personal-cipher-preferences 3DES (3DES only), make a encrypted message. Then, try to decrypt the message with OpenPGPcard (version 2.1 and later).
Jan 10 2018
I find your question confusing. I'm the reporter of this bug. All the efforts and tries of gniibe and myself are documented above.
Or do you refrer to something else ?
Can you exactly explain how you tested this?
I also have the 2.1 Card which has this bug
Version ..........: 2.1
Manufacturer .....: ZeitControl
Jan 9 2018
FWIW, I ran the same test with three card versions:
I forwarded the bug report to the OpenPGP card author.
I think that 2.0 card is OK, 2.1, 2.2, and 3.3 card have this bug.
Jan 6 2018
So the assumption is it is an Error of the GnuPG card.
I tried today with an Yubikey 4 and it works. This confirms the theorie.
However - my preference is on the Smartcards. So how would we proceed now. Who can check for the error and correct it / flash a new version on a card.
I would offer to verify if it is fixed.
Jan 5 2018
Here is an extract of the log file which shows the assumed cause
OK. I managed to reproduce same behavior. I think that it is a bug of OpenPGP card implementation.
Here is the log:
In the log above, I did for RSA-2048. I also did for RSA-4096. The result was same: it was failed with 6A88
I guess that the implementation somehow confuses with the sequence of 00 02 which appears with 3DES.
Jan 4 2018
I sent the gpg: DBG: DEK frame via encrypted eMail to you. Hope this helps.
FWIW, the old format was only used up to PGP 2.3 . PGP 2.6 used the new format. This is actually more indication that the message has not been generated by an old PGP version.
Could you please give me the debug output line for DEK frame: by encrypted mail to me? So far, I can't find any likely scenario where an error occurs with smartcard. (Use of PGP2.6 is unlikely.)
Dec 31 2017
The conformance problem may (only) happen between PGP 2.6 and OpenPGPcard, because PGP 2.6 uses old format not compatible to PKCS#1, but OpenPGPcard requires PKCS#1.
Dec 30 2017
Ok - thats good news.
Thank you very much for your analysis.
Dec 29 2017
OK, I got the picture, now.
Well, my speculation of SERIALNO undefined may be wrong.
Thanks, I received the log file.
Dec 28 2017
Thank you for your efforts. Logfiles is in the mail
Thanks a lot for your testing. Here are my keys:
Dec 27 2017
All right - that was quicker.
I deinstalled pcscd (apt remove pcscd)
I changed .gnupg/scdaemon.conf as you proposed.
I tried again to decrypt the message (in the meantime I have a file) which works decrypting withoutl SmartCard when I use it on a pc with the key.
Still failed. Can I send you the Logfile encrypted ? If so - what is you eMail / key.
As said - it took me a while. Sorry for the delay.
I could dig out the Key in some archives. So I was able to test the decryption of the message on a computer without smartcard.
It worked.
Thanks a lot. I'm going to push the fix to 2.2 (and then master).
In short, it was the bug in ccid-driver of scdaemon, which was introduced last year when I enhanced it to support multiple card readers at once.
Dec 26 2017
Yes, thank you, the smartcard is being recognized now.
Thanks (again). According to the status code (bStatus), the card reader said no card is available.
Could you please remove the card and re-insert it, and do 'gpg --card-status'?
After
patch -i scdaemon-fix-for-inactive-start.diff scd/ccid-driver.c
the following log obtains.
Dec 25 2017
Thanks a lot for your testing. Please test this patch:
After installing libusb-devel, and configure and make, this is the new log.
Thanks. I think that you configured GnuPG without libusb, thus, ccid-driver is not enabled, and you don't have pcscd installed. In this situation, no way to access any smartcard reader.
Dec 24 2017
Please enable all debug information in scdaemon.conf, like:
verbose verbose debug-level guru debug-all debug-ccid-driver log-file /run/user/1000/scdaemon-verbose.log
The file scdaemon.log is short and contains only:
2017-12-24 12:32:53 scdaemon[4347] écoute sur la socket « /run/user/1000/gnupg/S.scdaemon » 2017-12-24 12:32:53 scdaemon[4347] gestionnaire pour le descripteur -1 démarré 2017-12-24 12:32:53 scdaemon[4347] pcsc_establish_context failed: no service (0x8010001d)
Thanks for your testing. please give me scdaemon.log with updated scdaemon.
Dec 23 2017
With latestes master, there still appears:
--- ~ » gpg --card-status 2 ↵ gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: selecting openpgp failed: Aucun périphérique de ce type gpg: la carte OpenPGP n'est pas disponible : Aucun périphérique de ce type
Dec 13 2017
Looking an example code of http://g10code.com/docs/openpgp-card-v21-free-source.zip (Note that this is just an example code), 6A88 can be occurred for PSO:DECIPHER when:
Dec 11 2017
Thanks a lot. Please note that there is a bit of possibility the messages which cause failure are one of attack vectors. (While most likely case is they are generated by broken implementation.)
Im mean GnuPG fails for messages from a particular sender, while it works for messages from other senders.
Do you mean, GnuPG fails for a particular message, while it works for other messages?
Or do you mean, GnuPG fails for messages from a particular sender, while it works for messages from other senders?
Dec 10 2017
The new reader arrived. Works find for every message - except obviously this one sender.
See reader https://pcsclite.alioth.debian.org/ccid/supported.html#0x04E60x5116 ti should support large APDU. Same error messages
I think we are on the wrong error track here. It is not the reader. I now tested 4.
Dec 8 2017
Thank you for your cooperation.
Dec 7 2017
I still have trouble beliving it is the reader. Since I tried now 3.
As well I have a 4096 bit key and everybody has been encrypting this with my key. Therefore it does not make sense to me.
For Gemalto USB Shell Token V2, libccid has known issue: https://ludovicrousseau.blogspot.jp/2017/03/gemalto-idbridge-k30-k50-ct30-and-zero.html
I don't know about ACR 38U.
Dec 6 2017
Here two other Reader example - same message - same problem:
Reader: Gemalto USB Shell Token V2 (00483E73) 00 00
Reader: ACS ACR 38U-CCID 00 00
For Gemalto Shell Tokens: http://support.gemalto.com/index.php?id=tokens
There are three variants. Please describe detail.
Dec 4 2017
It's in gniibe/scd-kdf-support.
I think it's good to add to GnupG 2.2 branch.
Nov 29 2017
If more fine-grained control is needed with suspend-to-ram, we need to write kernel driver for USB access.
I learned suspend-to-ram functionality. Currently, for Linux, if we have USB driver in kernel, there are methods to handle suspend-to-ram and resume events. For user space driver by libusb, there is nothing and it should all work well by reseting after resume.
Nov 22 2017
Another log is not needed, as I located the issue. If you can try building GnuPG from Git repo (it's 2.2 branch now), it helps us a lot.
Nov 21 2017
Thank you. Do you still need the log files with the settings suggested by Werner? Would I have to compile the master branch to see if it works now?
Thank you for scdamon.log. For the card reader, the interrupt transfer notifies no availability of the card before PC_to_RDR_IccPowerOn.
I fixed this issue in rG0bb7fd0cab2d: scd: Enable card removal check after select_application.. Let's see if it works well for the card reader.
Nov 20 2017
This is the actual error message from your log file:
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: idVendor: 04E6 idProduct: 5119 bcdDevice: 0525 [...] 2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: bMaxCCIDBusySlots 1 2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID submit transfer (83): 0 2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed