Current master breaks key access on the token via reader #109
Comments
|
Does that object have |
|
Certainly not. It's a public key (on a properly initialized token): And private keys: And using pkcs11-tool: Funny thing - the above works when the token is connected directly (not via reader)... I'm trying to determine whether this is a The problem seems to have something to do with the presence of multiple readers... |
|
The excerpts look OK to me. The device must be a Yubico device that does not handle VERIFY with Lc=0, The rest of the debug log may show something. |
|
Hm, can you show output of |
Correct. But I've been having the same problem with CAC (that handles VERIFY quite well). Not to mention that VERIFY doesn't seem to belong with the public key access/retrieval (and no, I'm not mad to ever provision the card in such a way that a public key gets CKA_PRIVATE set). Providing the entire log of the original event (excerpt from the log is in the original posting):
This is the setup when everything works (Gemalto reader is disconnected): Plugging in Gemalto reader did not change the above output - still the same. Putting Yubikey NEO on that reader did not change the above output either. Keychain Access (on Mac OS X) is able to lock and unlock the Yubikey token when it's on Gemalto reader - but does not show any certificates on it (which is does fine when the Yubikey is inserted directly into a USB port). CAC inserted into a different reader (SCM Microsystems Inc. SCR 3310, with Gemalto reader still plugged in) does show its certificates in the Keychain Access, and requests for certificates or private key operations work. CAC inserted into Gemalto reader also worked fine (certificates shown, keys accessible). The failure appears to be with the NFC part of the Gemalto reader... (??? it used to work fine ???) Here's the complete log of the above test: Update
I don't know... Reason I suspect it wouldn't is because I see the LEDs blinking when the request goes to the token, so the system appears to know what device to ask for the certs/pubkeys... How would I do that (a) with OpenSC command line tools, and (b) with pkcs11 URI that I feed to OpenSSL and libp11? I'd love to try it. |
|
Just specify more details — e.g. I asked about that because I was wondering it was a problem in the code which iterates over all the tokens, and searches in the one(s) which match the search criteria. And if your URI matches more than one token then it won't log in. |
Update You can see that it did not get the serial number, for example. |
|
in opensc-20160927-broken.txt line 1018-1020 an attempt to read the remaining 0xFC bytes of the second certificate It would appear it is caused by some other process, PCSC, the USB or causing some issue maybe power with the reader and PCSC has lost the lock on the card. Things fall apart quickly here. Could be hardware or power issues or It could have also been caused by some memory overwrite. Don't know what else to say. |
|
Your original command line included That is the PKCS#11 URI. If you actually have two tokens in the system which each have an object with But it doesn't look like that's the case now? |
Ah, so I just add "serial=xxxxx;" to that pkcs11 URI. Understood, thank you very much! @dwmw2 in my setup there (almost) always is only one token actually inserted and in use. So, I could understand a confusion between the readers - but only one of them would actually have a working card. From that I conclude that specifying token serial number isn't likely to help, correct? @dengert I hear you (Dr. Google says "an attempt was made to end a non-existing transaction"). Would you recommend anything to remedy or diagnose further? |
|
No ideas. Its Tokend on MacOS with Apple's pcsc and using that dual reader. |
Actually, it is not - the same situation happens after I kill tokend, thus ensuring that nothing interferes with the command line operations (I do the same when I need to access OpenPGP applet). Regarding the dual reader - yes, but I've no idea what to make of it. The contact part seems to be working with CAC. The contactless used to work fine with NEO, a couple of weeks ago it stopped working for no obvious reasons. I've been tracking OpenSC updates to the master, but even trying to install OpenSC.pkg built around end of July (which I know worked OK) did not help. And the problem is manifested by the very basic OpenSC tools (this is with tokend killed): But trying (thanks, @dwmw2) p11-tool, I'm getting: |
|
Did one of the commits break the functionality that previously worked? Which commit? |
|
It appears so, but I've been unable to pinpoint it. I went back to a commit made in August (and I remember than it worked then), but couldn't get it to work any more. :-( |
@mtrojnar two facts to support your point: OpenSC command line tool also fails to access public keys (libp11 not involved there), and there was an OS update between when things worked and when they stopped working. :-( Question: does GnuTLS and p11tool use libp11, or OpenSC only/directly? |
|
GnuTLS and p11tool will use OpenSC via p11-kit. Definitely not via libp11 (which is only for OpenSSL). |
|
@mouse07410 You said "OpenSC command line tool also fails to access public keys" Do you mean pkcs15-tool? Or do you mean pkcs11-tool? Some change in OpenSC might have changes this. OR it could be the "SCardTransmit/Control failed: 0x80100016" Do you have more then one reader? That could pin down a hardware problem. Do you have or can get a Linux system to try your reader and cards to see if you can reproduce the problems? |
Actually I meant both. Regarding the logs: noted. Complete log:
Yes. And only one type of the reader appeared to misbehave. Also, it seemed to misbehave only with command line tools (OpenSSL + libp11, and OpenSC). Unlocking the screen using OpenSC.tokend succeeded several times. Also: I don't understand. When the token is inserted in a USB port - all the certificates and keys are perfectly accessible. When it is accessed via NFC through Gemalto reader - sometimes all the certificates are not accessible, KEY MAN certificate and key is not accessible, others usually are... What seems to be broken? Mac OS X? The hardware reader (I have three Gemalto DU Prox readers, they all behave the same)? OpenSC? All of the above? |
|
@mouse07410 This looks like some timer or timeout going on. Maybe it could be retried. This spreed sheet does not format well view it in the write mode: Line Start End Diff periods diff/period |
|
Very impressive, thanks!
Yeah... Excellent to at least have an idea what to look for. Now the question is - is it a timer within PCSC (handled by Mac OS X), or with OpenSC (that we might be able to affect)? |
|
@mouse07410 A contacless reader is really a NFC reader. There are programs/drivers besides PCSC that can use the USB device. On Debian based systems at least to get PCSC to work with the contactless device required Did MacOS add some new drivers or apps that may be accessing the contactless reader while PCSC is still trying to use it for the smart card? Depending on how the duel reader works, interference of one could be caused by use of the other. |
I don't know - unfortunately Apple doesn't tell much about what their updates actually change. But the failures on the contactless side became almost regular - much more frequent than successes.
I never put two cards in this reader, and when one is used the other one appears disabled (a few months ago I experimented with that)... |
It now refuses to retrieve public keys when the token is not logged on - exactly the problem we've solved a few months ago:
The relevant (IMHO) excerpt from the log:
The text was updated successfully, but these errors were encountered: