OpenSC fails to detect card when inserted after the library initialization (C_WaitForSlotEvent() does not return) #943
Comments
|
Are you saying that your card is not a mcrd card but it was selected? The APDU 00 A4 04 00 0F D2 33 00 00 00 45 73 74 45 49 44 20 76 33 35 Could it be that your CAC card returns 90 00 to this command? Is the card from the same vendor as the mcrd card? As you suggest it could be the code should have detected a card was removed, (but I don't see in your trace where the card was removed.) shold not try a reconnect, but stat over as if it is a new card. |
Yes. This is a log with CoolKey applet. I can provide more information about the card manufacturer tomorrow, but the applet itself should be open source.
It looks like we are getting
The card was removed before I started the test. It is not part of the log. This is par of the log, when the card is inserted into the empty slot. |
|
First, the mcrd ATR clashes with your cards ATR, which is bad. Maybe the ATR mask is not properly set somewhere... If you change However, you need to step through the program to find out why that only happens when there is no card inserted... |
|
It feels strange that your card succeeeds to select the EstEIDv35 AID. Are there additional applets on the card or does your applet not handle SELECT AIDs correctly? |
|
This sounds like the card wil accept some AIDS when it does not have that applet on the card. It sounds like to problem is with the Java card. You said the applet was opens source. as @frankmorgner said the ATRs may be the same as it is the ATR for a javacard, and selecting the AID does not work as expected because the javacard will return 9000 for any AID. the same problem as the EstEID card. The PIV driver might also fail, as it tries to select the AID. So any driver that tries to select the AID may fail. May be the same issue with the muscle driver? Where did you get the card? I would be interested in a trace of having just the PIV and the driver you expect to work in the opensc.conf. Who installed the applet? |
As far as I know, there are no other applets. When the card is available during the library initialization it is detected correctly.
The card should be new and was provisioned recently (~months). The applet is not any new. There are some updates in github repo, but the logic is probably still the same:
The card was provisioned (applet installed, key generated) by Enterprise Security Client (ESC), part of Red Hat Certificate System. ESC is using the CoolKey PKCS#11 module to read/write which basically supports only the CoolKey applet (in addition to CAC and PIV). I will attach the traces tomorrow. |
@dengert I added a to the https://gist.github.com/Jakuje/877eb2ab0ecca843962dd479d68867fb The detection and the initialization works as expected in this case. The card with CoolKey applet should be Gemalto/SafeNet will SC650. |
|
Somewhere between 0.15.0 and master, the name to use for the PIV driver changed from piv to PIV-II Looking at the internal list in ctx.c you will note that the drivers are in order, and starting with the mcrd driver are the drivers that do some APDU command to the card to test if it matches. In your first post it showed the mcrd driver did a SELECT command that responded 90 00, so the driver assumed it matched. . When you removed mcrd, you said the muscle driver did the same thing, but you did not provide a trace to show why the muscle driver though it matched. ( The same trace would also show why the setcos driver did not match.) There are 10 drivers before the coolkey driver that could also cause a false match. It would be nice to see if they also have a false match, and why. If you remove the mcrd driver (we know how it matched, but not why) from ctx.c can you get a debug log? Pleae send the whole log. The last log started at the C_WaitForSlotEvent, and there is a lot of other stuff before this. This would show what the setcos and muscle drivers are doing, and why the muscle driver got a match. |
|
Thanks for the reminder. I knew about that, but obviously forgot. Adding a new log with both PIV and Coolkey. Now, the reports look good: $ opensc-tool --list-drivers I posted only the The whole logs
The fail means I killed the program, because the |
|
mcrd, coolkey muscle, coolkey piv, coolkey 00 A4 04 00 is really a SELECT FILE with (P1=A4) Direct selection by DF name (data field=DF name) and also uses the SELECT FILE in section "9.3 Application selection service" Now it maybe that your card does not support "9.3" but even if it is only supporting a select file, What we don't have is a trace of starting with all the drivers without using C_WaitForSlotEvent. Can you get a dump with all the drivers, but have card in the slot, and don't use C_WaitForSlotEvent? |
|
Thanks for having a look into that. The The logs with all drivers enabled, muscle and mcrd (all passes): Interesting is that in these cases, the card returns The note about the card is that it is low power 1.8V card so we had to fix |
|
Good to see @LudovicRousseau is involved in this problem. Have you tried using a different readers? Say for example the SCM 3500: https://www.amazon.com/Micro-Systems-SmartFold-Reader-SCR3500/dp/B004RL6QUQ Some differences between having card inserted before starting pkcs11 application or opensc-tool Inserting the card may require the card's OS to "boot" and get the default applet setup. If it gets a SELECT command before it is ready it might responds with the wrong response. Try adding a sleep(1) in reader-pcsc.c after sc_log(ctx, "card inserted event"); This is for debugging, You could start pcscd with debugging to see timing and commands and responses. You could get a USB trace to see if the APDU and response from the card match what OpenSC is seeing. There are also ways to look at the card to reader interface to see what is going on. I have never tried this. There may be some timing problem |
|
I have got also "SCM Microsystems Inc. SCR 3310", but it reports "Unresponsive card" for Coolkey card (works fine with PIV Test cards).
Yes, this "solves" the problem and I am getting the events correctly. The card obviously needs some time. Now there is the question how to solve that generally in OpenSC. I will dig in the pcscd and post the logs, if there will be something suspicious. |
|
pcsc in debug mode shows the same APDU being send and received (mcrd): Not sure about the USB trace and how to get that. Is it still needed? |
|
Probably not, but keep it in mind. Is this a new card? Since it runs at 3V and required changes to pcsc it appears to be newer then any of the other cards supported by OpenSC. Are you working with the manufacture of the card? Do you have any manual on the card? What version of the coolkey applet is loaded on the card? |
|
Any developers have a muscle card that could test with the C_WaitForEvent? While looking for source code for the coolkey applet, I found this. It reports it is from Redhat 3010 // **** Most processing starts here!! The way I read this, if a command is received before the applet is selected , 90 00 is returned |
|
Looking further, selectingApplet (): |
|
Ignoring the crappy implementation of hardware and software that we build on, could you try solving the problem in software? Above I suggested to return |
|
@frankmorgner sorry, I somehow missed your comment earlier. Such change was something I had in my mind since the start and it is certainly solving the problem (at least when tested with |
|
hmm ... weird. Just build OpenSC again and I am not getting the matches of |
|
It could still be a timing problem. You referred to changes to the CCID to get the below 3V card to work. Pcscd loads CCID, so restarting pcscd it could make a difference. What version of each are you using? Based on the comments above, if Redhat is issuing cards, there may be a lot of them and this could become a big problem. @frankmorgner returning SC_ERROR_CARD_CMD_FAILED from ops->init would work, but ops->init() can allocate and change card structure expecting ops->finish to be called to clean up. (Unlike ops->match_card which is expected to do its own cleanup.) We need to address memory leaks. One way is to make sure every card's init cleans up on error, or We should also look at every card driver that may fail in init to see if they should return SC_ERROR_INVALID_CARD. The mcrd was the first card that had this problem, muscle (and others) may also fail with this problem and may even make it through init without failing! So we really need to find out why his environment or his card or reader are failing. |
|
@Jakuje "weird. Just build OpenSC again" was that with the sleep(1) test or not? |
These should be latest Fedora 25 versions: Today I can reproduce the issue again so back to the questions: @frankmorgner As @dengert pointed out, returning Sorry for the noise. Now it looks like even the To the CoolKey code, the part is the same as in the Muscle and it is considered as a good practice to do something like that (also most of the Java cards I saw look like do something like this): It is probably answering |
|
I don't see |
|
Well ... I was running with all the drivers, but when there is |
|
I misinterpreted the selectingApplet in my first comment. It is true when Java tells the applet it has been selected based on the registered AID the applet provided. So that is not the real problem which could still could be a problem with the card/reader or pcscd. mcrd should clean up, but that is only caused because the card/reader/pcscd returned 90 00 to a request to select the mcrd AID. So the real problem is why was 90 00 returned. I can not reproduce the problem. Do you have some non Redhat system to try this on? Do you have some other card that does not fail? I believe you said you have PIV and mcrd does not fail it does not fail. So this points at the card or pcsc when using the card. Any other reader to try? |
|
Just tested with my Ubuntu 16.10, but it has ancient Manual change in I don't have any other reader around here to try. I created PR #945 with the changes we came with so far. @LudovicRousseau do you have overview what could have changed in pcsc-lite* since Ubuntu versions? Fedora have |
|
CCID version 1.4.26 changed the voltage used to power a card. RedHat had issues with voltage and Coolkey cards and had already their own patch. |
|
The downgrade to "Ubuntu" versions didn't change anything (nor the change of |
Expected behaviour
Initializing pkcs11 library and then waiting for slot events (card insertion) should work.
Actual behaviour
Trying interactive tests depending on the
C_WaitForSlotEvent()fails to detect the Coolkey card (or CAC -- from #841), because the card is detected in thecard-mcrddriver and its initialization fails.Steps to reproduce
pkcs11-tool --test-hotplugor./p11test -p pin -i -s 0Logs
With
OPENSC_DEBUG=999we can observe these logs behavior (with comments):start detection in
mcrd:we just matched completely
mcrdcardthe card driver tries to initialize the card
which finally fails
but does not fail back to the detection of using different drivers
and the insertion event is lost.
Commenting out
mcrdfromctx.cwill make the same match and fail in themusclecard driver. Commenting all of them (except Coolkey) works as expected. I didn't test that further. This looks like a problem with very similar cards (eg answering successfully to the same APDU). This does NOT happen when the card is inserted during the library initialization (the weird part), which is probably handled i bit differently.Can somebody with better architecture overview have a look in these logs and confirm that my theory and probably propose what can be done about that?
The text was updated successfully, but these errors were encountered: