Unable to use with REINER SCT cyberJack reader

[flokli]

I set up the REINER SCT cyberJack reader (which comes with its own pin keyboard and display), using the pcsc-cyberjack driver.

Plugging in my card while opening qdigidoc 4 correctly shows my card details, and I'm able to decrypt/sign documents.

---

Using the same card in the same reader with web-eid-app however doesn't work properly:

I used the "Authenticate" example on https://web-eid.eu/. I see a short flash of the web-eid-app window opening, but it immediately seems to "crash" and close itself again.

The website shows:

Authentication failed

[Code]
ERR_WEBEID_USER_CANCELLED

[Message]
User cancelled

My system logs show:

Apr 23 23:05:00 tp chromium-browser.desktop[2841148]: INFO: "web-eid" app "2.3.0+0" running in stdin/stdout mode
Apr 23 23:05:00 tp chromium-browser.desktop[2841148]: DEBUG: Starting "WaitForCardThread" 12156624 for command "INSERT_CARD"
Apr 23 23:05:00 tp gnome-shell[1779160]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3600008 specified for 0x3600006.
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: INFO: "WaitForCardThread" 12156624 for command "INSERT_CARD" completed successfully
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: INFO: Card "EstEID IDEMIA v1" in reader "REINER SCT cyberJack RFID standard (014230XXXX) 00 00" using protocol T=1
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: Thread 12156624 finished
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: "WaitForCardThread" 12156624 destroyed
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: Starting "CommandHandlerRunThread" 17808336 for command "AUTHENTICATE"
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: INFO: "CommandHandlerRunThread" 17808336 for command "AUTHENTICATE" completed successfully
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: Starting "CommandHandlerConfirmThread" 18148544 for command "AUTHENTICATE"
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: Thread 17808336 finished
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: "CommandHandlerRunThread" 17808336 destroyed
Apr 23 23:05:01 tp gnome-shell[1779160]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3600008 specified for 0x3600006.
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: INFO: Command "AUTHENTICATE" canceled
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: Starting "CardEventMonitorThread" 18158496 for command "AUTHENTICATE"
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: User cancelled
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: Thread 18148544 finished
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: Interrupting thread 18158496
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: "CommandHandlerConfirmThread" 18148544 destroyed
Apr 23 23:05:01 tp chromium-browser.desktop[2841148]: DEBUG: "CardEventMonitorThread" 18158496 destroyed

Command "AUTHENTICATE" canceled is the interesting bit here. I didn't cancel anything here.

This is web-eid-app-2.3.0, with the following libraries:

• Qt 5.15.8
• OpenSSL 3.0.8
• pcsclite-1.9.5

When removing the pcsc-cyberjack driver and using another reader (without pin pad), everything works, so it's definitely an issue with these reader types.

[mrts]

Thanks for the report! We will look into this as time allows.

[kristelmerilain]

This should be fixed now by #293
Can you please test if this resolves your issue?

[flokli]

Hey @kristelmerilain thanks for the heads-up! I might not be able to test this in the next 2-3 weeks, but I'll comment here as soon as I did!

[flokli]

I can confirm this works, thanks!

Two things I noticed:

• The NFC reader seems to be quite sensitive, and most of the time detects the card via NFC, even when plugging into the non-NFC slot. In case any unsupported card is available, the web-eid-app application then only shows the "The card in the reader is not supported" message. I had some more success connecting the reader to the USB port with the card plugged in, then quickly removing and re-plugging in the card. If the card doesn't support authenticating/signing via NFC, could userspace be at least more tolerant towards the NFC channel being present too to make this less brittle?
• When I get to the PIN prompt, the prompt message on the terminal itself only always asks for "PIN", there's no distinction between PIN1 and PIN2. Is there a way to signal what PIN is requested? Or would this be up to the vendor of the reader (REINER SCT) to provide info about what key slot is requested?