Cannot use Italian Electronic ID Card software with remote smart card

[callegar]

Hi,

I am trying to use your software in order to employ my mobile phone as a smart card reader, in order to use the CIE (Electronic ID card) software on my computer together with my CIE.

A little background:

Italy is now issuing Electronic ID Cards, that — among other things — can be used to authenticate with the government web sites and to electronically sign documents. To this aim the government releases a dedicated application called CIEid. This is available for multiple operating systems including Linux which is what I am using and Android. The PC version of the application is delivered as a JAVA jar file.

I have tested the Android version of the application and it works fine, proving that my mobile phone NFC reader is up to the task.

Because working with the phone is not that comfortable in some cases, I'd like to use the desktop version of the application as well. And because I'd rather not buy a PC NFC reader just for this, I'd like to use your remote smart card reader application for the purpose.

So I have installed your Remote Smart Card Reader for Android from F-droid and your vpcd software on my linux host.

• Compiling and installing vcpd on linux went fine, to the best of my understanding and pcscd -f -d logs the Virtual PCD startup.

Only puzzlement at this stage is that vpcd-config shows two host/port combinations rather than one:

PCD hostname:  192.168.10.100
VPCD port:      35963
On your NFC phone with the Remote Smart Card Reader app scan this code:
https://api.qrserver.com/v1/create-qr-code/?data=vpcd://192.168.10.100:35963

VPCD hostname:  192.168.10.100
VPCD port:      35964
On your NFC phone with the Remote Smart Card Reader app scan this code:
https://api.qrserver.com/v1/create-qr-code/?data=vpcd://192.168.10.100:35964

At this point, if I start the remote smart card application on the phone and input the first host/port combination the application seems able to connect to the VPCD and to see the ID CARD. If I put the card next to the phone the application logs:

Discovered ISO/IEC 14443-A tag
timeout set to 250
Disconnected from VPCD
Connecting to 192.168.8.100:35963
Connected to VCPD
Powered up card with ATR
<some hex data>
Powered down the card (cold reset)

Seems OK (even if it is not totally clear to me if the "power down" and cold reset at the end is expected).

At the same time, pcscd logs

eventhandler.c:406:EHStatusHandlerThread() powerState: POWER_STATE_POWERED
eventhandler.c:423:EHStatusHandlerThread() Card inserted into Virtual PCD 00 00
Card ATR: <some hex data>  
eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED

Now I fire up the CIEid software. At first usage, this software is expected to do a pairing with the smart card using a PIN. When I start the pairing, CIEid seems to recognize whether there is an ID card close to the phone or not, but the pairing hangs (there is a progress bar and it stops progressing almost immediately).

At the same time pcscd logs

winscard.c:430:SCardConnect() Active Protocol: T=1
00000010 [140663324665600] winscard.c:456:SCardConnect() hCard Identity: <some short hash>
00000012 [140663324665600] winscard.c:518:SCardConnect() UnrefReader() count was: 2
00000009 [140663324665600] winscard_svc.c:513:ContextThread() CONNECT rv=0x0 for client 26
00000159 [140663324665600] winscard_svc.c:361:ContextThread() Received command: GET_ATTRIB from client 26
00000027 [140663324665600] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 1
00000011 [140663324665600] ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 590595
00000008 [140663324665600] winscard.c:1434:SCardGetAttrib() UnrefReader() count was: 2
00000013 [140663324665600] winscard_svc.c:764:ContextThread() GET_ATTRIB rv=0x8010001F for client 26
00000170 [140663324665600] winscard_svc.c:361:ContextThread() Received command: DISCONNECT from client 26
00000025 [140663324665600] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 1
00000008 [140663324665600] winscard.c:881:SCardDisconnect() Active Contexts: 1
00000005 [140663324665600] winscard.c:882:SCardDisconnect() dwDisposition: 1
00154174 [140663324665600] ifd-vpcd.c:236:IFDHGetCapabilities() Got ATR (20 bytes)
00000029 [140663324665600] winscard.c:920:SCardDisconnect() Reset complete.
00000013 [140663324665600] Card ATR: <some hex data> 
00000008 [140663324665600] winscard.c:1017:SCardDisconnect() powerState: POWER_STATE_GRACE_PERIOD
00000006 [140663324665600] ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 4018
00000005 [140663324665600] winscard.c:1043:SCardDisconnect() UnrefReader() count was: 2
00000008 [140663324665600] winscard_svc.c:550:ContextThread() DISCONNECT rv=0x0 for client 26
00094271 [140664045238016] eventhandler.c:494:EHStatusHandlerThread() powerState: POWER_STATE_POWERED
00620550 [140664045238016] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED

So I have this questions:

• why does the power state switch to unpowered?
• are the unknown tag messages (with the two different codes 590595 and 4018 relevant
• should the remote smart card work with Italian ID cards
• is there a way to debug what is going on, given that I have no possibility to try the CIEid software with a physical reader?

[frankmorgner]

What is the log on the phone (remote reader) showing?

If you compile yourself, you could try to tweak the timeout configuration value in the app (not currently on F-Droid)

[smanet80]

I have been able to read Italian id card on mac OS and huawei mate 20 pro

[smanet80]

On a separate note, the same phone/app doesn't seems to work with 2x Windows 10 20H2 (one virtual machine and one laptop). I am getting a lot of Tag was lost or the VPCD communications seems to break at very early stages as opposed to a working communication with the Mac. What could be useful to provide for investigation (should I raise a new bug?)

[smanet80]

Testing with Linux, I am getting a similar (same?) problem:

14601011 ifd-vpcd.c:236:IFDHGetCapabilities() Got ATR (20 bytes)
00000025 eventhandler.c:406:EHStatusHandlerThread() powerState: POWER_STATE_POWERED
00000003 eventhandler.c:423:EHStatusHandlerThread() Card inserted into Virtual PCD 00 00
00000004 Card ATR: [hex]
00497798 eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED

The APP says (can't copy and paste):

Powered up the card with ATR
[hex]
Powered down the card (cold reset)

[frankmorgner]

I'll close this issue since the initial problem is most likely related to the phone's hardware.

The other issue should be fixed with 2721cd3afba85b715cb004aab677449f86f63495

[frankmorgner]

Sorry, I did not carefully read the the initial problem description... What is happening is the following: pcscd (or some PC/SC application) requests a cold reset of the card, which causes the android app to explicitly terminate the connection to the card.

So actually both issues brought up here are fixed with 2721cd3afba85b715cb004aab677449f86f63495 (unfortunately, not currently on F-Droid)

[callegar]

Is there a build including the fix that can be tried? I have noticed that there is an apk for 2.3 in the releases page, but it does not install on my phone. Incidentally, the commit you mention seems to be from 2014 and git tag --contains 2721cd3 mentions almost all tagged releases of remote-reader including 2.2 which I understand is the one in F-droid. Am I missing something? Unfortunately, the fact that F-Droid appears to rename things adds to my confusion. Is the F-droid "Smart Card Reader" application what you call the "Remote Smart Card Reader" App, right?

[frankmorgner]

https://github.com/frankmorgner/vsmartcard/releases/download/remote-reader-2.3/remote-reader-debug-2.3.apk

adb install remote-reader-debug-2.3.apk

if that doesn't work, please open a seperate issue

[callegar]

Thanks, I have managed installing that apk.

Unfortunately, using the card is still impossible. The log on the mobile phone still ends with "Resetted the card (warm reset)" and "Powered down the card (cold reset)".

The application that should use the card reader says "connected" but then hangs (there is a progress bar that does the first bit and then stays there).

In a couple of occasions I got the daemon on the computer (pcscd) logging

00000186 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 16
00000029 [139703860844288] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 16
00000190 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 16
00000027 [139703860844288] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 16
01001292 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 16
00000035 [139703860844288] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 16
00000136 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 16
00000035 [139703860844288] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 16
00000114 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 16
00000023 [139703860844288] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 16
00000110 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 16
00000023 [139703860844288] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 16
01001210 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 16
00000035 [139703860844288] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 16
00000156 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 16
00000029 [139703860844288] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 16
00000173 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 16
00000030 [139703860844288] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 16
00000169 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 16
00000027 [139703860844288] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 16
01001265 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 16
00000035 [139703860844288] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 16
00000142 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 16
00000034 [139703860844288] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 16
00000113 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 16
00000024 [139703860844288] winscard_svc.c:442:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 16
00000119 [139703860844288] winscard_svc.c:361:ContextThread() Received command: CMD_WAIT_READER_STATE_CHANGE from client 16
00000022 [139703860844288] winscard_svc.c:834:MSGSendReaderStates() Send reader states: 16

over and over... this seems a bit different from before...

However, usually I still get

00000011 [140379789715200] winscard.c:430:SCardConnect() Active Protocol: T=1
00000010 [140379789715200] winscard.c:456:SCardConnect() hCard Identity: 764cd705
00000011 [140379789715200] winscard.c:518:SCardConnect() UnrefReader() count was: 2
00000013 [140379789715200] winscard_svc.c:513:ContextThread() CONNECT rv=0x0 for client 11
00000171 [140379789715200] winscard_svc.c:361:ContextThread() Received command: GET_ATTRIB from client 11
00000031 [140379789715200] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 1
00000010 [140379789715200] ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 590595
00000006 [140379789715200] winscard.c:1434:SCardGetAttrib() UnrefReader() count was: 2
00000008 [140379789715200] winscard_svc.c:764:ContextThread() GET_ATTRIB rv=0x8010001F for client 11
00000193 [140379789715200] winscard_svc.c:361:ContextThread() Received command: DISCONNECT from client 11
00000031 [140379789715200] readerfactory.c:848:RFReaderInfoById() RefReader() count was: 1
00000009 [140379789715200] winscard.c:881:SCardDisconnect() Active Contexts: 1
00000006 [140379789715200] winscard.c:882:SCardDisconnect() dwDisposition: 1
00164495 [140379789715200] ifd-vpcd.c:236:IFDHGetCapabilities() Got ATR (20 bytes)
00000031 [140379789715200] winscard.c:920:SCardDisconnect() Reset complete.
00000013 [140379789715200] Card ATR: 3B 8F 80 01 80 31 80 65 B0 85 04 00 11 12 0F FF 82 90 00 8A 
00000009 [140379789715200] winscard.c:1017:SCardDisconnect() powerState: POWER_STATE_GRACE_PERIOD
00000006 [140379789715200] ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 4018
00000005 [140379789715200] winscard.c:1043:SCardDisconnect() UnrefReader() count was: 2
00000012 [140379789715200] winscard_svc.c:550:ContextThread() DISCONNECT rv=0x0 for client 11
00033329 [140379894372096] eventhandler.c:494:EHStatusHandlerThread() powerState: POWER_STATE_POWERED
00518545 [140379894372096] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED

With the unpowered state issue.

[callegar]

A few more notes. I have seen that the middleware for the Italian Electronic Identity Card (CIE) is on github at https://github.com/italia/cie-middleware/. This may perhaps provide some hint at the expected exchanges with the CIE.

Furthermore, I have been instructed to test a pkcs11-tool --module /usr/local/lib/libcie-pkcs11.so -I -L which should return some card details. However, in my case, I get:

Slot 1 (0x1): Virtual PCD 00 0
CIE non riconosciutaCIE non riconosciuta:84f6bc40EXCLOG->EXC: :84f6bc40<-EXCLOG  (token not recognized)
Using slot 1 with a present token (0x1)

where "CIE non riconosciuta" means "CIE card not recognized".

What I know is that the same card works if the same middleware is run directly on the mobile phone in its android version.

[frankmorgner]

Is there anything else shown on the App? can you upload a full log of pcscd -fd --apdu for both, the good and the bad case? (please check if your PIN is not included in this log)

[callegar]

My problem right now is that I do not have a "good" case, because I don't have a USB NFC reader to get it. I know people who do and who are telling me that the CIE works with its middleware, but I do not know if they are willing to share information here. The best I can do is to share my "bad" case data tomorrow.

I have opened an issue on the github site where the CIE middleware is developed (https://github.com/italia/cie-middleware-linux/issues/36) to make them aware of your project and encourage them to share information with you to try reaching compatibility between the CIE middleware and the remote smart card reader. I hope this is appropriate and can lead to cooperation and to the logs you need.

[smanet80]

The cie card works for me with the current app and mac OS x Catalina but not with Windows. At the moment, I can't test with Linux. If useful, I can provide logs from both sides, I just need to know if I need to provide any special parameter to pcscd and how on the mac. Also, what phone are you using for this test @callegar?

[frankmorgner]

let's start from the beginning...

@callegar please do the following

1. run pcscd -f -a -d
2. start the app and make a screenshot when app and pcscd are connected
3. run pkcs11-tool --module /usr/local/lib/libcie-pkcs11.so -I -L
4. make an other screenshot of the app if something changed
5. upload the complete log of pcscd and both screenshots of the app.

@smanet80 if macOS is working, but Windows isn't, can you see some connection problem on Windows, maybe caused by a Firewall? As a start, you could use OpenSC on both platforms to do a very simple opensc-tool -a -n -vvv and then upload the two complete logs here. Then we can check if we can spot a difference.

[smanet80]

@frankmorgner I will try to get some output for you tomorrow, but I can confirm that I have opened the firewall to both the application and to the TCP port required. In fact, I can see the connection happening but the issue is very similar to what @callegar described here. Based on that, I think the issue is more on the application for Windows (and Linux) other than the Android app.

[smanet80]

@frankmorgner I am unable to gather information on windows as opensc doesn't detect the smart card reader while I can see it healthy in the device drivers. I was able to collect the information on the mac.

[smanet80]

The windows log from the app is very short compared on when connecting to windows.

• Windows:

• Mac:

[frankmorgner]

It's strange to see that the app has received APDUs from Windows, but OpenSC doesn't even see the reader. On Windows, could you please also try the builtin command certutil -scinfo?

[smanet80]

I guess you always learn something new but there is also something that I can't explain. The good news is that it works on both my Windows machines now, I just don't know why as it wasn't working last time I have tried. No changes on the firewall/network, but updates to both phone and Windows. I did try to upgrade the app but failed, so I am still using version 2.2 though. The command above "certutil -scinfo" made me think that I can't use the smart card via a remote session (RDP), unless I try to share the virtual smart card from my Mac, which I haven't tried yet.

This is the error received if I try to share smartcards:

C:\Windows\system32>certutil -scinfo
The Microsoft Smart Card Resource Manager is running.
Current reader/card status:
SCardListReaders: The stub received bad data. 0x6f7 (WIN32: 1783 RPC_X_BAD_STUB_DATA)
SCardListReaders failed for SCARD_ALL_READERS
A list of smart card readers could not be determined.

Done.
CertUtil: -SCInfo command FAILED: 0x6f7 (WIN32: 1783 RPC_X_BAD_STUB_DATA)
CertUtil: The stub received bad data.

If I don't have the smartcard checkbox selected, the service is not even running:

C:\Windows\system32>certutil -scinfo
The Microsoft Smart Card Resource Manager is not running.
WaitForSingleObject: Service is in an unknown state.
CertUtil: -SCInfo command FAILED: 0x80070102 (WIN32/HTTP: 258 WAIT_TIMEOUT)
CertUtil: The wait operation timed out.

Once I have connected to the VM's console, it has just worked. My laptop works as well. Maybe the usual power it off and on again has made the trick for the laptop, but really puzzled now.

I have the logs from both Mac and Windows, but I guess they're not useful anymore.

[frankmorgner]

Looks like you stumbled across this bug https://github.com/FreeRDP/FreeRDP/issues/7214

[callegar]

Here are my logs... taken on ubuntu 20.04 pcscd-log.txt

[frankmorgner]

Just to be clear, all problems of @smanet80 are resolved, right? Windows works without freerdp (and reboot), macOS works out of the box.

[frankmorgner]

@callegar, you're first connecting with the built-in dummy card (ATR 3B 68 00 FF 38 2B 41 52 44 6E 73 73) by pressing on the yellow button without an attached card to test the connection to vpcd. That test works, the connection to pcscd is done. In a second step you're holding a card to the app, with a propagated ATR of an italian ID card. Four SCONTEXT are created (client 11-13), which are reading the latter ATR without actually sending any data to the card. There is no error reported in the pcscd log, which looks as if the ATR doesn't get accepted by the CIE middleware. And indeed, the ATR doesn't contain the required pieces: https://github.com/italia/cie-middleware-linux/blob/5e4cdceb3449a109efe708f1f83bc12a7400ca2b/cie_sign_sdk/src/CSP/IAS.cpp#L265-L292 The source code shows that the cie middleware has some logging mechanism. Could you try to find out, how to enable this? Maybe their log shows some more information on what's going wrong internally...

[psytester]

Just to be clear, all problems of @smanet80 are resolved, right? Windows works without freerdp (and reboot), macOS works out of the box.

Hmm... This part of the issue smells like a familiar behavior to me. It seems that when accessing Windows via (native) RDP, smart card readers are no longer present/lost in the RDP session. A reboot was necessary. No idea if it is a bug or security feature. This was already seen in Win7 times. With VNC it worked anyway. I worked intensively with smart cards in 2012 - 2016, long time ago

[smanet80]

@psytester A reboot will not resolve the issue as it seems that Microsoft decided to disable the physical readers while in RDP sessions. I can test it next time I restart the VM for patching though. @frankmorgner I believe I am good now. I would be happy to test Ubuntu but I don't have a Linux desktop VM available at this time.

[dengert]

How many real and virtual readers are defined?

https://docs.microsoft.com/en-us/troubleshoot/windows/win32/limitation-10-smart-card-readers#:~:text=Starting%20in%20Windows%208%2C%20the,All%20other%20readers%20are%20ignored.

"Starting in Windows 8, the Windows platform supports a maximum of 10 smartcard readers. If more than 10 smartcard readers are available, APIs such as SCardListReaders return a maximum of 10. All other readers are ignored."

TPM readers may also count: https://docs.microsoft.com/en-us/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-get-started

[smanet80]

@dengert I have no physical smart card reader on the Windows VM. So only the virtual one. While connected to the console, I can list only that one as well.

[callegar]

@frankmorgner If I am not getting it wrong, my ATR looks a lot like the Gemalto_ATR in the middleware file apart form a 2-byte header and a 2-byte trailer... and I suspect the IndexOf there may be meant to match a substring. Hence, I wonder, if the middleware was meant to recognize my ATR as the Gemalto one and why it does not.

[smanet80]

@callegar @frankmorgner I am getting the exact same behaviour on Ubuntu 20.04 with my card/phone.

azureuser@ubuntu-test:~/Downloads/git/vsmartcard/virtualsmartcard$ sudo pcscd -f -d 00000000 [140217924126656] debuglog.c:299:DebugLogSetLevel() debug level=debug 00000073 [140217924126656] configfile.l:293:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 00000016 [140217924126656] configfile.l:329:DBGetReaderListDir() Skipping non regular file: .. 00000004 [140217924126656] configfile.l:329:DBGetReaderListDir() Skipping non regular file: . 00000004 [140217924126656] configfile.l:369:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/libccidtwin 00000036 [140217924126656] configfile.l:369:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/vpcd 00000021 [140217924126656] configfile.l:210:evaluatetoken() Add reader: Virtual PCD 00000051 [140217924126656] readerfactory.c:1074:RFInitializeReader() Attempting startup of Virtual PCD 00 00 using /usr/lib/pcsc/drivers/serial/libifdvpcd.so 00000072 [140217924126656] readerfactory.c:950:RFBindFunctions() Loading IFD Handler 3.0 00000022 [140217924126656] ifd-vpcd.c:116:IFDHCreateChannel() Waiting for virtual ICC on port 35963 00000033 [140217924126656] ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 4019 00000005 [140217924126656] readerfactory.c:391:RFAddReader() Using the pcscd polling thread 00000037 [140217924126656] readerfactory.c:524:RFAddReader() Driver is slot thread safe 00000006 [140217924126656] readerfactory.c:1074:RFInitializeReader() Attempting startup of Virtual PCD 00 01 using /usr/lib/pcsc/drivers/serial/libifdvpcd.so 00000006 [140217924126656] readerfactory.c:863:RFLoadReader() Reusing already loaded driver for /usr/lib/pcsc/drivers/serial/libifdvpcd.so 00000006 [140217924126656] readerfactory.c:950:RFBindFunctions() Loading IFD Handler 3.0 00000012 [140217924126656] ifd-vpcd.c:116:IFDHCreateChannel() Waiting for virtual ICC on port 35964 00000011 [140217924126656] ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 4019 00000005 [140217924126656] readerfactory.c:558:RFAddReader() Using the pcscd polling thread 00000039 [140217924126656] pcscdaemon.c:663:main() pcsc-lite 1.8.26 daemon ready. 04971572 [140217915729664] ifd-vpcd.c:236:IFDHGetCapabilities() Got ATR (20 bytes) 00000030 [140217915729664] eventhandler.c:406:EHStatusHandlerThread() powerState: POWER_STATE_POWERED 00000004 [140217915729664] eventhandler.c:423:EHStatusHandlerThread() Card inserted into Virtual PCD 00 00 00000009 [140217915729664] Card ATR: 3B 8F 80 01 80 31 80 65 B0 85 04 00 11 12 0F FF 82 90 00 8A 00577350 [140217915729664] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED

I have compiled it from git and also tried the official release, no changes.

[aleclearmind]

I've forced it the middleware to recognize the CIE I have as CIE_Gemalto.

diff --git a/cie-pkcs11/CSP/IAS.cpp b/cie-pkcs11/CSP/IAS.cpp
index 6149b48..4a88645 100644
--- a/cie-pkcs11/CSP/IAS.cpp
+++ b/cie-pkcs11/CSP/IAS.cpp
@@ -309,7 +309,8 @@ void IAS::SelectAID_CIE(bool SM) {

 uint8_t NXP_ATR[] = { 0x80, 0x31, 0x80, 0x65, 0x49, 0x54, 0x4E, 0x58, 0x50, 0x12, 0x0F, 0xFF, 0x82, 0x90 };
 uint8_t Gemalto_ATR[] = { 0x80, 0x31, 0x80, 0x65, 0xB0, 0x85, 0x04, 0x00, 0x11, 0x12, 0x0F, 0xFF, 0x82, 0x90, 0x00 };
-uint8_t Gemalto2_ATR[] = { 0x80, 0x31, 0x80, 0x65, 0xB0, 0x85, 0x03, 0x00, 0xEF, 0x12, 0x0F, 0xFF, 0x82, 0x90, 0x00 };
+// uint8_t Gemalto2_ATR[] = { 0x80, 0x31, 0x80, 0x65, 0xB0, 0x85, 0x03, 0x00, 0xEF, 0x12, 0x0F, 0xFF, 0x82, 0x90, 0x00 };
+uint8_t Gemalto2_ATR[] = { 0x3B, 0x8F, 0x80, 0x01, 0x80, 0x31, 0x80, 0x65, 0xB0, 0x85, 0x04, 0x00, 0x11, 0x12, 0x0F, 0xFF, 0x82, 0x90, 0x00, 0x8A };
 uint8_t STM_ATR[] = {0x80, 0x66, 0x47, 0x50, 0x00, 0xB8, 0x00, 0x7F};
 uint8_t STM2_ATR[] = {0x80, 0x80, 0x01, 0x01};
 uint8_t STM3_ATR[] = {0x80, 0x01, 0x80, 0x66, 0x47, 0x50, 0x00, 0xB8, 0x00, 0x94, 0x82, 0x90, 0x00, 0xC5};
@@ -324,6 +325,14 @@ ByteArray baSTM3_ATR(STM3_ATR, sizeof(STM3_ATR));
 void IAS::ReadCIEType() {      
        init_func
                size_t position;
+
+               type = CIE_Type::CIE_Gemalto;
+               // type = CIE_Type::CIE_NXP;
+    // type = CIE_Type::CIE_STM;
+    // type = CIE_Type::CIE_STM2;
+    // type = CIE_Type::CIE_STM3;
+    return;
+
     if (ATR.indexOf(baNXP_ATR, position)) {
                type = CIE_Type::CIE_NXP;
         LOG_INFO("IAS::ReadCIEType - CIE NXP detected");

Attached there's a commented output of pcscd -f -d.

Some relevant portions of it:

$ grep ifd-vpcd pcscd.log
00000025 ifd-vpcd.c:116:IFDHCreateChannel() Waiting for virtual ICC on port 35963
00000033 ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 4019
00000004 ifd-vpcd.c:116:IFDHCreateChannel() Waiting for virtual ICC on port 35964
00000004 ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 4019
04564633 ifd-vpcd.c:236:IFDHGetCapabilities() Got ATR (20 bytes)
00185537 ifd-vpcd.c:236:IFDHGetCapabilities() Got ATR (20 bytes)
00000001 ifd-vpcd.c:317:IFDHSetProtocolParameters() Ignoring IFDHSetProtocolParameters (Lun=1 Protocol=2 Flags=0 PTS1=0 PTS2=0 PTS3=0)
00000027 ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 590595
00115978 ifd-vpcd.c:236:IFDHGetCapabilities() Got ATR (20 bytes)
00000001 ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 4018

Here's the debug log of libcie-pkcs11.so:

:253  [INFO] [PKCS11] C_GetFunctionList
:253  [INFO] [PKCS11] C_Initialize
:258  [INFO] InitSlotList - reader:Virtual PCD 00 00
:263  [INFO] InitSlotList - reader:Virtual PCD 00 01
:269  [INFO] InitSlotList - reader:*REDACTED*
:275  [INFO] InitSlotList - reader:*REDACTED*
:284  [INFO] [PKCS11] C_Initialize success
:284  [INFO] [PKCS11] C_GetSlotList
:284  [INFO] [PKCS11] C_GetSlotList
:284  [INFO] [PKCS11] C_GetSlotInfo
:284  [INFO] [PKCS11] C_GetSlotInfo
:284  [INFO] [PKCS11] C_GetSlotInfo
:284  [INFO] [PKCS11] C_GetTokenInfo
:512  [INFO] CSlot::GetATR() - no card inserted
:992  [ERROR] :84247f46
:992  [ERROR] [PKCS11] EXC: :84247f46
:992  [ERROR] [PKCS11] P11Error: e1
:992  [INFO] [PKCS11] C_GetSlotInfo
:992  [INFO] [PKCS11] C_Finalize
:998  [INFO] [PKCS11] DllMainDetach

I hope this helps making some sense out of it. Let me know if you need more testing.

[frankmorgner]

Thanks for looking into this again. The strange thing is that the ATR that's calculated and sent from the android app is {0x3B, 0x8F, 0x80, 0x01, 0x80, 0x31, 0x80, 0x65, 0xB0, 0x85, 0x04, 0x00, 0x11, 0x12, 0x0F, 0xFF, 0x82, 0x90, 0x00, 0x8A }, which exactly contains the original Gemalto_ATR[]. So the middleware should automatically detect the card as CIE_Type::CIE_Gemalto, see https://github.com/italia/cie-middleware-linux/blob/04041b017f6ef96868b94eb6422bdda7e91f5199/cie-pkcs11/CSP/IAS.cpp#L326-L328 It's strange to see that you have to hard code this.

[aleclearmind]

Turns out that the ATR is empty, after some step-by-step debugging I think these are the relevant messages:

00000842 winscard_svc.c:361:ContextThread() Received command: GET_ATTRIB from client 21
00000008 readerfactory.c:866:RFReaderInfoById() RefReader() count was: 1
00000002 ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 590595
00000001 /var/winscard.c:1432:SCardGetAttrib() UnrefReader() count was: 2
00000002 winscard_svc.c:774:ContextThread() GET_ATTRIB rv=0x8010001F for client 21

Basically this fails with error code 0x8010001F:

long ret = SCardGetAttrib(this->hCard, SCARD_ATTR_ATR_STRING, (uint8_t*)ATR, &atrLen);

I suspect ifd-vpcd.c:290:IFDHGetCapabilities() unknown tag 590595 is the culprit. 590595 (aka 0x90303) is SCARD_ATTR_ATR_STRING. Looks like it's not supported indeed.

[aleclearmind]

Actually, it turns out that if I mask with 0xFFFF the tag things proceed! The card is recognized as Gemalto and we're all happy!

@frankmorgner is this a bug on vsmartcard-side or on cie-middleware-linux-side? In the former case, I can open a PR, in the latter, I'll fork the repo with some more fixes.

[frankmorgner]

https://pcsclite.apdu.fr/api/group__IFDHandler.html#ga799aa26945bbd3f61aaa57107f63ae0b implementation of SCARD_ATTR_ATR_STRING is optional, but very easy...

diff --git a/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c b/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c
index 7b4b72eb..6c2b7f24 100644
--- a/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c
+++ b/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c
@@ -223,6 +223,7 @@ IFDHGetCapabilities (DWORD Lun, DWORD Tag, PDWORD Length, PUCHAR Value)

     switch (Tag) {
         case TAG_IFD_ATR:
+        case SCARD_ATTR_ATR_STRING:

             size = vicc_getatr(ctx[slot], &atr);
             if (size < 0) {

Yeah, just open a PR so I can see... I'm not sure what you mean by masking the tag...

[aleclearmind]

I'm not sure what you mean by masking the tag...

SCARD_ATTR_ATR_STRING & 0xFFFF == TAG_IFD_ATR There's some sort of relation between the two.

Yeah, just open a PR so I can see...

I'll do some more work just to make sure there aren't other changes needed to do the whole thing (i.e., enable the CIE and actually use it for authentication purposes).

Thanks for the support!

[frankmorgner]

in reader.h:

#define SCARD_ATTR_ATR_STRING SCARD_ATTR_VALUE(SCARD_CLASS_ICC_STATE, 0x0303) /**< Answer to reset (ATR) string. */

in ifdhandler.h:

#define TAG_IFD_ATR                     0x0303  /**< ATR */

Hence, with my suggested diff above, the request for the ATR by cie-middleware-linux should work.

[callegar]

Couple of notes:

• there is a new release of the Italian CIE middleware that is said to solve the issue, but doesn't https://github.com/italia/cie-middleware-linux/issues/37

• tried the patch with the case SCARD_ATTR_ATR_STRING: branch in the switch statement, but cannot compile. Getting a

  ifd-vpcd.c: In function ‘IFDHGetCapabilities’:
  ifd-vpcd.c:226:14: error: ‘SCARD_ATTR_ATR_STRING’ undeclared (first use in this function)
  226 |         case SCARD_ATTR_ATR_STRING:
    |              ^~~~~~~~~~~~~~~~~~~~~

  do we miss the inclusion of reader.h somewhere?

[callegar]

Tried manually including reader.h now the code compiles. However with the newer cie middleware and the patch, still KO.

But something significant has changed. Now pkcs11-tool --module /usr/local/lib/libcie-pkcs11.so -I -L segfaults

File INI:/usr/local/lib/ciepki.ini
Inizio Sessione - versione: May 13 2022 21:18:01Lib log level: 3
Lib log level: 3
Lib log level: 3
Lib log level: 3
Lib log level: 3
Lib log level: 3
Lib log level: 3
Lib log level: 3
Cryptoki version 2.10
Manufacturer     IPZS
Library          CIE PKCS11 (ver 1.0)
Lib log level: 3
Lib log level: 3
Available slots:
Slot 0 (0x2): Lib log level: 3
Lib log level: 3
Virtual PCD 00 0
  (empty)
Slot 1 (0x1): Lib log level: 3
Lib log level: 3
Virtual PCD 00 0
Lib log level: 3
Lib log level: 3
Lib log level: 3
Lib log level: 3
Lib log level: 3
Lib log level: 3
  (token not recognized)
Lib log level: 3
Lib log level: 3
Lib log level: 3
Lib log level: 3
Using slot 1 with a present token (0x1)
Lib log level: 3
Lib log level: 3
free(): double free detected in tcache 2
Aborted (core dumped)

[frankmorgner]

This should work:

diff --git a/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c b/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c
index 7b4b72e..fcdf25e 100644
--- a/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c
+++ b/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c
@@ -222,6 +222,11 @@ IFDHGetCapabilities (DWORD Lun, DWORD Tag, PDWORD Length, PUCHAR Value)
         goto err;

     switch (Tag) {
+#ifdef SCARD_ATTR_ATR_STRING
+        case SCARD_ATTR_ATR_STRING:
+#else
+        case 0x00090303:
+#endif
         case TAG_IFD_ATR:

             size = vicc_getatr(ctx[slot], &atr);

[callegar]

Tried again. Still getting transactions that are very short and end with "pwered down the card (cold reset)"

Only once I managed getting something containing R-APDU C-APDU sequences, but they were going on indefinitely and the middleware for the Italian Id Card was still hanging.

[zuzzurro]

I am trying to use the italian CIE and it still it still doesn't work, with the same symptoms: "pwered down the card (cold reset)". Can this issue be reopened?

[zuzzurro]

Let me add to my previous comment. I realized yesterday that the change from May 23 has not been released yet, to I tried ading it as a patch to the Fedora COPR rpm I was using for testing it. I have to report that even with that change I still am unable to have this working properly using the latest release of the CIE client framework. Happy to provide more details to help. I am really keen to use this software for using the CIE card using my phone's NFC reader.

[frankmorgner]

on the computer run pcsc_scan -> you should see the virtual reader displayed as empty on the phone's app tap the card -> the app should connect to the virtual reader so that pcsc_scan shows the card with a card on the computer run opensc-tool -n (from the OpenSC project) -> the tool may not successfully identify the card, but it will send some commands to the phone for identification. these commands will be displayed in the app as C-APDU and R-APDU.

If the above works as described, the virtual reader works correctly with the remote reader app. Then your struggle should be related to the limitations of the CIE client framework. For this, please take and modify their source code or open an issue there.

[callegar]

For reference of those trying to triage whether the issue is on the remote smart card side or in the cie client framework, I would like to mention that there are two open issues on the CIE github repo related to these problems:

• https://github.com/italia/cie-middleware-linux/issues/36 (compatibility between the CIE middleware and the remote smart card software)
• https://github.com/italia/cie-middleware-linux/issues/49 (software hangs at CIE connected)

[zuzzurro]

@callegar, that's very useful, thanks. One more point from my side. As I said, in order to run my second tests, I manually applied the 68ca1fb patch to 0.8 and only that. Are there other relevant fixes that I should apply?