From allen at criticalsoftwaresolutions.com  Mon Apr  3 17:27:47 2023
From: allen at criticalsoftwaresolutions.com (Allen Curtis)
Date: Mon, 3 Apr 2023 17:27:47 -0700
Subject: [Pcsclite-muscle] unresolved symbols
Message-ID: <02524B3E-B597-4B80-8A5C-ED68CEA4A654@criticalsoftwaresolutions.com>

I am trying to compile the sample code provided for pcsclite. All the headers and libraries are installed. I can see that the following symbols are defined in the shared library but I get unresolved symbol messages when compiling. How do I resolve undefined symbols below.

Thanks

allen at css-XPS-13-9310:~/work/ideate/ntag424/IDM-ntag424/src$ gcc `pkg-config --libs libpcsclite` -lpthread ntag424_daemon.o -o aout
/usr/bin/ld: ntag424_daemon.o: in function `find_card_readers':
ntag424_daemon.c:(.text+0x40): undefined reference to `SCardListReaders'
/usr/bin/ld: ntag424_daemon.c:(.text+0x57): undefined reference to `pcsc_stringify_error'
/usr/bin/ld: ntag424_daemon.c:(.text+0x110): undefined reference to `SCardFreeMemory'
/usr/bin/ld: ntag424_daemon.c:(.text+0x147): undefined reference to `SCardFreeMemory'
/usr/bin/ld: ntag424_daemon.o: in function `main':
ntag424_daemon.c:(.text+0x1d2): undefined reference to `SCardEstablishContext'
/usr/bin/ld: ntag424_daemon.c:(.text+0x233): undefined reference to `SCardReleaseContext'
/usr/bin/ld: ntag424_daemon.c:(.text+0x243): undefined reference to `pcsc_stringify_error'
collect2: error: ld returned 1 exit status
-- 
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC



From allen at criticalsoftwaresolutions.com  Mon Apr  3 18:16:13 2023
From: allen at criticalsoftwaresolutions.com (Allen Curtis)
Date: Mon, 3 Apr 2023 18:16:13 -0700
Subject: [Pcsclite-muscle] unresolved symbols (resolved)
Message-ID: <692129BE-60B5-431A-ADB8-43280B904ACE@criticalsoftwaresolutions.com>

Never mind. I had the wrong order of the arguments.


Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC



From godfreyhkchung at gmail.com  Mon Apr  3 20:39:26 2023
From: godfreyhkchung at gmail.com (Godfrey Chung)
Date: Tue, 4 Apr 2023 11:39:26 +0800
Subject: [Pcsclite-muscle] acsccid 1.1.9 Released
Message-ID: <CAF8LfwLzuE=CqWNeZ54uoeXU6PMW8g0cUB-GsiRxbV7hZXbH2g@mail.gmail.com>

Dear All

I would like to inform you that acsccid 1.1.8 had been released.

v1.1.9 (15/3/2023)
- Add the following readers support:
  APG8201-B2RO
  ACR39U-W1 Top Reader
  ACR39U-W1 Edge Reader
  WalletMate 1S CL Reader
  WalletMate USB FW_Upgrade
  ACR1581 1S Dual Reader
  ACR1581 USB FW_Upgrade
  ACR40T ICC Reader
  ACR40 FW_Upgrade
  ACR39 FW_Upgrade
- Fix misleading read length in CCID_Receive().
- Use "buffer.h" instead of <openct/buffer.h>.
- Merge with ccid 1.4.32.
  - ccid_open_hack_pre(): fix bug for ICCD type A & B devices.
  - Fix "Bus Error" on SPARC64 CPU and Solaris C compiler.
  - Add SCARD_ATTR_CHANNEL_ID for USB devices.
  - get_ccid_usb_interface(): No need to make the function EXTERNAL.
- Merge with ccid 1.4.33.
  - Import files from ccid 1.4.33 to get Unicode support.
  - towitoko: do not use "bool" type.
  - configure: add --enable-oslog argument.
  - debug: add support of os_log(3) for macOS.
  - macOS: use --enable-oslog for macOS >= 10.12
- Enable syslog or oslog from deployment target in MacOSX/configure.
- Fix ACR1281U-C1 communication issue with NXP SAM AV3.
- Set arm64 and x86_64 for universal binary build in MacOSX/configure.
- Fix segmentation fault for multi-slot readers on macOS Big Sur.
- Merge with ccid 1.4.34.
  - T0ProcACK(): Fix a potential integer underflow.
  - Fix a potential crash in IFDHTransmitToICC().
  - CmdPowerOn: fix log messages.
  - CmdPowerOn: fix a potential infinite loop.
  - T0ProcACK: fix a potential problem.
  - CmdPowerOn: fix a potential overrun with bogus ATR.
  - IFDHSetProtocolParameters(): Fix reading past the end-of-buffer.
  - CmdGetSlotStatus: fix potential read of uninitialized buffer.
  - ReadUSB: fix potential read of uninitialized buffer.
  - IFDHSetProtocolParameters: handle ATR_GetConvention() error.
  - PPS_Match: fix potential read of uninitialized buffer.
  - Fix potential reads of uninitialized buffer.
  - dw2i: fix potential integer overflow.
  - CCID_Transmit: call memcpy() only with a non-NULL src.
  - Do not report an error if the wrong interface is used by the driver.
  - Return "no smart card" if we get notified during a transmit.
  - Display libusb error code in text.
  - Add a new field dwProtocols in struct _ccid_descriptor.
  - Fail if the requested protocol is not supported by reader.
  - Fix potential memcpy call with null dest.
- Merge with ccid 1.4.35.
  - Solve a performance issue with T=1 and CCID_CLASS_AUTO_PPS_PROP.
  - Reformat part of T0ProcACK().
  - Fix a possible buffer overflow in T0ProcACK.
  - ccid_usb: ask for bNumDataRatesSupported data rates.
  - IFDHSetProtocolParameters: set IFSC/IFSD only for TPDU readers.
  - CmdPowerOn: fix debug message about Voltage.
  - Multi_PollingProc: use slot variable.
  - configure.ac: remove AC_HEADER_STDC.
  - configure.ac: remove AC_HEADER_TIME.
  - Import files from ccid 1.4.35.
  - Use ax_pthread.m4 macro from autoconf-archive.
- Replace AM_PROG_LEX with AC_PROG_LEX([noyywrap]) in configure.ac.
- Add ACS_APG8201_B2RO to src/ccid.h.
- Disable card detection thread for APG8201-B2RO in OpenUSBByName().
- Return 6B 80 for APG8201-B2RO in CCID_Receive().
- Disable polling thread for APG8201-B2RO in IFDHGetCapabilities().
- Enable I/O controls for APG8201-B2RO in IFDHControl().
- Enable SPE pseudo APDU for APG8201-B2RO in process_spe_ppdu().
- Merge with ccid 1.4.36.
  - Code reformat: replace 4 spaces by 1 tab.
- Enable ACR1252U-MW/MV (composite device) as multi-slot reader.
- Enable the 2nd interface of ACR1252U-MW/MV as SAM slot.
- Enable ACR1581U-C1 (composite device) as multi-slot reader.
- Enable the 3rd interface of ACR1581U-C1 as SAM slot.
- Enable SAM slot for ACR40T.
- Update the status for SAM slot on macOS in CardDetectionThread().
- Disable polling thread for SAM slot in IFDHGetCapabilities().
- Remove unused TriggerSlotChange().
- Enable multislot extension for single slot readers in OpenUSBByName().
- Update the status for each slot in Multi_PollingProc().
- Use iconv.m4 macro from gettext.
- Fix compiler warnings on macOS in CardDetectionThread().
- Enable ACR1581U-C1 to use bStatus in IFDHICCPresence().

Please download it from http://acsccid.sourceforge.net/.

Regards

Godfrey


From godfreyhkchung at gmail.com  Mon Apr  3 20:41:09 2023
From: godfreyhkchung at gmail.com (Godfrey Chung)
Date: Tue, 4 Apr 2023 11:41:09 +0800
Subject: [Pcsclite-muscle] acsccid 1.1.9 Released
In-Reply-To: <CAF8LfwLzuE=CqWNeZ54uoeXU6PMW8g0cUB-GsiRxbV7hZXbH2g@mail.gmail.com>
References: <CAF8LfwLzuE=CqWNeZ54uoeXU6PMW8g0cUB-GsiRxbV7hZXbH2g@mail.gmail.com>
Message-ID: <CAF8Lfw+E2kcq04kEhgx8smP-WjQWQKQgnYaFyAcFQ3sdAfmEXg@mail.gmail.com>

>
> I would like to inform you that acsccid 1.1.8 had been released.
>

Sorry, it should be acsccid 1.1.9.


From allen at criticalsoftwaresolutions.com  Thu Apr  6 18:04:51 2023
From: allen at criticalsoftwaresolutions.com (Allen Curtis)
Date: Thu, 6 Apr 2023 18:04:51 -0700
Subject: [Pcsclite-muscle] hang when calling SCardConnect()
Message-ID: <CAFxo-rPUbeRJufD8s+e85gEMya5kSoxs35Cbiw=kSxzgpf2JSA@mail.gmail.com>

Below is debug output from PCSCD and my application. When the program
detects that a card is "present", the program attempts to open a
connection to the card. However this hangs and reports
POWER_STATE_UNPOWERED after a few seconds. The code is from the
example in the pcscd documentation directory.

Thoughts?


Monitor: ACS ACR1252 1S CL Reader [ACR1252 Dual Reader PICC] 00 00
00000179 [139765936543296] winscard_svc.c:361:ContextThread() Received
command: CMD_WAIT_READER_STATE_CHANGE from client 13
00000033 [139765936543296] winscard_svc.c:840:MSGSendReaderStates()
Send reader states: 13
00000011 [139765936543296] winscard_svc.c:361:ContextThread() Received
command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 13
Status: 0x0012: CHANGED EMPTY
00000002 [139765936543296] winscard_svc.c:442:ContextThread()
CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 13
00000014 [139765936543296] winscard_svc.c:361:ContextThread() Received
command: CMD_WAIT_READER_STATE_CHANGE from client 13
00000003 [139765936543296] winscard_svc.c:840:MSGSendReaderStates()
Send reader states: 13
05520417 [139765953328704] ccid_usb.c:1843:InterruptRead() 3/30: Slot 0: 0x00
00052402 [139765953328704] ifdhandler.c:1407:IFDHPowerICC() action:
PowerUp, usb:072f/223b:libudev:0:/dev/bus/usb/003/030 (lun: 0)
00001159 [139765953328704] eventhandler.c:406:EHStatusHandlerThread()
powerState: POWER_STATE_POWERED
00000023 [139765953328704] eventhandler.c:423:EHStatusHandlerThread()
Card inserted into ACS ACR1252 1S CL Reader [ACR1252 Dual Reader PICC]
00 00
00000010 [139765953328704] winscard_svc.c:828:MSGSignalClient() Signal
client: 13
00000006 [139765953328704] winscard_svc.c:831:MSGSignalClient() SIGNAL
rv=0x0 for client 13
00000019 [139765953328704] Card ATR: 3B 81 80 01 80 80
00000096 [139765936543296] winscard_svc.c:361:ContextThread() Received
command: CMD_WAIT_READER_STATE_CHANGE from client 13
00000015 [139765936543296] winscard_svc.c:840:MSGSendReaderStates()
Send reader states: 13
Status: 0x10022: CHANGED PRESENT
00000127 [139765936543296] winscard_svc.c:361:ContextThread() Received
command: CMD_STOP_WAITING_READER_STATE_CHANGE from client 13
00000018 [139765936543296] winscard_svc.c:442:ContextThread()
CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 13
calling SCardConnect
00000119 [139765936543296] winscard_svc.c:361:ContextThread() Received
command: CMD_WAIT_READER_STATE_CHANGE from client 13
00000015 [139765936543296] winscard_svc.c:840:MSGSendReaderStates()
Send reader states: 13
05001376 [139765953328704] ifdhandler.c:1407:IFDHPowerICC() action:
PowerDown, usb:072f/223b:libudev:0:/dev/bus/usb/003/030 (lun: 0)
00001901 [139765953328704] eventhandler.c:482:EHStatusHandlerThread()
powerState: POWER_STATE_UNPOWERED

-- 
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC


From ludovic.rousseau at gmail.com  Fri Apr  7 01:20:04 2023
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Fri, 7 Apr 2023 10:20:04 +0200
Subject: [Pcsclite-muscle] hang when calling SCardConnect()
In-Reply-To: <CAFxo-rPUbeRJufD8s+e85gEMya5kSoxs35Cbiw=kSxzgpf2JSA@mail.gmail.com>
References: <CAFxo-rPUbeRJufD8s+e85gEMya5kSoxs35Cbiw=kSxzgpf2JSA@mail.gmail.com>
Message-ID: <CAGstE8CFvSHFpLzMQcMR0W0xLUz7=6QSx6HY_XYJdUgovQ2w3g@mail.gmail.com>

Hello,

Le ven. 7 avr. 2023 ? 03:06, Allen Curtis
<allen at criticalsoftwaresolutions.com> a ?crit :
>
> Below is debug output from PCSCD and my application. When the program
> detects that a card is "present", the program attempts to open a
> connection to the card. However this hangs and reports
> POWER_STATE_UNPOWERED after a few seconds. The code is from the
> example in the pcscd documentation directory.
>
> Thoughts?

Please provide a short C-code that exhibits the problem.

Bye

-- 
 Dr. Ludovic Rousseau


From allen at criticalsoftwaresolutions.com  Fri Apr  7 08:35:02 2023
From: allen at criticalsoftwaresolutions.com (Allen Curtis)
Date: Fri, 7 Apr 2023 08:35:02 -0700
Subject: [Pcsclite-muscle] sample code
Message-ID: <CAFxo-rM-sXa49_zdVXiTh-UKe6uDYNScbh4GqPfEwkg78EFeog@mail.gmail.com>

Below is the attached code distilled down to the relevant logic. The
actual source files are attached as well for your review.

typedef struct
{
    const RfidAtr atr;
    const AesKey keys[NUM_KEYS];  ///< list of key values used for
authentication
    const TagFile files[NUM_NTAG424_FILES];

    bool connected; ///< indicate that we are current connected to the reader
    size_t command_counter; ///< counter used for ADPU construction

    AesKey encrypt_key; ///< authentication derived AES encryption key
    AesKey cmac_key;    ///< authentication derived AES-MAC key
    TI ti;  ///< authentication derived transaction identifier

    pthread_t tid; ///< Monitor thread ID

    char* reader_name; ///< name of the reader returned by the driver to use
    SCARDCONTEXT context; ///< device driver context
    SCARDHANDLE handle; ///< handle to the connected card
    SCARD_READERSTATE reader_state; ///< current state of the reader,
updated by monitor
    DWORD card_state; ///< current state of the card in the reader
    SCARD_IO_REQUEST card_protocol; ///< card protocol to be used


} Ntag424;

Ntag424 RfidTag;

int main()
{
    LONG rv;
    DWORD dwReaders;
    char *ptr;
    char *found_readers = NULL;
    char *acs_picc_reader = NULL;
    int e_code = NO_ERROR;
    Ntag424 *ntag = &RfidTag;

    /* Get Context to the driver */
    rv = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &ntag->context);
    CHECK_ERROR(rv, "SCardEstablishContext");

    /* Retrieve the available readers list. */
    dwReaders = SCARD_AUTOALLOCATE;
    rv = SCardListReaders(ntag->context, NULL, (LPSTR)&found_readers,
&dwReaders);
    CHECK_ERROR(rv, "SCardListReaders");

    /* Extract readers from the null separated string and get the total
     * number of readers */
    unsigned nbReaders = 0;
    ptr = found_readers;
    while (*ptr != '\0')
    {
        printf("Reader %d: %s\n", nbReaders, ptr);
        char *p_acr1252 = strstr(ptr, "ACR1252");
        if (p_acr1252)
        {
            char *p_picc = strstr(ptr, "PICC");
            if (p_picc)
            {
                acs_picc_reader = ptr;
            }
        }

        ptr += strlen(ptr) + 1;
        nbReaders++;
    }

    if (nbReaders == 0)
    {
        printf("No card readers were found!\n");
        e_code = ERROR_INTERNAL_ERROR;
    }

    if (acs_picc_reader == NULL)
    {
        printf("Error: ACR1252 Dual Reader PICC not found!\n");
        e_code = ERROR_INTERNAL_ERROR;
    }
    else
    {
        printf("found: %s\n", acs_picc_reader);

        ntag->reader_name = malloc(strlen(acs_picc_reader)+1);
        strcpy(ntag->reader_name, acs_picc_reader);
    }

    SCardFreeMemory(ntag->context, found_readers);

        // Get current state
        LONG rv = SCardGetStatusChange(ntag->context, INFINITE,
&ntag->reader_state, 1);

        if (rv == SCARD_S_SUCCESS)
        {
            show_reader_state(ntag->reader_state.dwEventState);
            ntag->reader_state.dwCurrentState = ntag->reader_state.dwEventState;

            printf("calling SCardConnect\n");
            DWORD dwActiveProtocol = SCARD_PROTOCOL_UNSET;
            LONG rv = SCardConnect(
                RfidTag.context,
                RfidTag.reader_name,
                SCARD_SHARE_SHARED,
                (SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1),
                &RfidTag.handle,
                &dwActiveProtocol);
        }
        else
        {
            printf("Error: %s (0x%lX)\n", pcsc_stringify_error(rv), rv);
        }\

    return rv;
}


-- 
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ntag424_daemon.c
Type: text/x-csrc
Size: 10927 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/pcsclite-muscle/attachments/20230407/30e8c95d/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ntag424.h
Type: text/x-chdr
Size: 2908 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/pcsclite-muscle/attachments/20230407/30e8c95d/attachment-0003.bin>

From ludovic.rousseau at gmail.com  Fri Apr  7 13:40:40 2023
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Fri, 7 Apr 2023 22:40:40 +0200
Subject: [Pcsclite-muscle] sample code
In-Reply-To: <CAFxo-rM-sXa49_zdVXiTh-UKe6uDYNScbh4GqPfEwkg78EFeog@mail.gmail.com>
References: <CAFxo-rM-sXa49_zdVXiTh-UKe6uDYNScbh4GqPfEwkg78EFeog@mail.gmail.com>
Message-ID: <CAGstE8BmCqoFDcwJL2WGM50jUVEYYj+uos7pNH=i-iwzq3e9=A@mail.gmail.com>

Le ven. 7 avr. 2023 ? 17:36, Allen Curtis
<allen at criticalsoftwaresolutions.com> a ?crit :
>
> Below is the attached code distilled down to the relevant logic. The
> actual source files are attached as well for your review.

Please provide a MINIMAL sample code. And a program that can run with
any reader name.

Bye

-- 
 Dr. Ludovic Rousseau


From ludovic.rousseau at gmail.com  Sat Apr  8 06:54:19 2023
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Sat, 8 Apr 2023 15:54:19 +0200
Subject: [Pcsclite-muscle] sample code
In-Reply-To: <CAGstE8BmCqoFDcwJL2WGM50jUVEYYj+uos7pNH=i-iwzq3e9=A@mail.gmail.com>
References: <CAFxo-rM-sXa49_zdVXiTh-UKe6uDYNScbh4GqPfEwkg78EFeog@mail.gmail.com>
 <CAGstE8BmCqoFDcwJL2WGM50jUVEYYj+uos7pNH=i-iwzq3e9=A@mail.gmail.com>
Message-ID: <CAGstE8DamzOxw87h3G7t4CsX+Dhxw5SfM_mcTZzkmxeHAsSikw@mail.gmail.com>

Le ven. 7 avr. 2023 ? 22:40, Ludovic Rousseau
<ludovic.rousseau at gmail.com> a ?crit :
>
> Le ven. 7 avr. 2023 ? 17:36, Allen Curtis
> <allen at criticalsoftwaresolutions.com> a ?crit :
> >
> > Below is the attached code distilled down to the relevant logic. The
> > actual source files are attached as well for your review.
>
> Please provide a MINIMAL sample code. And a program that can run with
> any reader name.

It looks like a bug on your code.
>From SCardEstablishContext() documentation
https://pcsclite.apdu.fr/api/group__API.html#gaa1b8970169fd4883a6dc4a8f43f19b67
" This must be the first WinSCard function called in a PC/SC
application. Each thread of an application shall use its own
SCARDCONTEXT, unless calling SCardCancel(), which MUST be called with
the same context as the context used to call SCardGetStatusChange(). "

>From your source code I see you use 2 threads but only one
SCardEstablishContext() call.
Fix your code and try again.

Bye

-- 
 Dr. Ludovic Rousseau


From allen at criticalsoftwaresolutions.com  Sat Apr  8 09:49:06 2023
From: allen at criticalsoftwaresolutions.com (Allen Curtis)
Date: Sat, 8 Apr 2023 12:49:06 -0400
Subject: [Pcsclite-muscle] sample code
In-Reply-To: <CAGstE8DamzOxw87h3G7t4CsX+Dhxw5SfM_mcTZzkmxeHAsSikw@mail.gmail.com>
References: <CAFxo-rM-sXa49_zdVXiTh-UKe6uDYNScbh4GqPfEwkg78EFeog@mail.gmail.com>
 <CAGstE8BmCqoFDcwJL2WGM50jUVEYYj+uos7pNH=i-iwzq3e9=A@mail.gmail.com>
 <CAGstE8DamzOxw87h3G7t4CsX+Dhxw5SfM_mcTZzkmxeHAsSikw@mail.gmail.com>
Message-ID: <DCD72DB9-652D-4B2B-BCFB-88D2CAB8EAFC@criticalsoftwaresolutions.com>

SCardEstablishContext() is the first call made to the driver. First Context is established, then all the readers are found and checked to find the PICC reader expected. (Our reader is ACS1252 which is a dual mode reader. Assume we do not want the SAM version).

Yes, there is 2 threads. The idea was that one thread would monitor for the presence of a tag in the reader. This would include determine if the tag inserted is authentic. The other thread would wait on a message queue for perform IO operations to the card based on whether it was present or not.

Are you saying that the SCardEstablishContext() is thread context sensitive and can not be shared across threads? Since the context was to a PCSC driver and there will only be 1 reader I assumed the context could be shared. Just make sure both threads did not use it at the same time.

Thanks for the help. Will make these changes and try again.

- Allen

> On Apr 8, 2023, at 6:54 AM, Ludovic Rousseau <ludovic.rousseau at gmail.com> wrote:
> 
> Le ven. 7 avr. 2023 ? 22:40, Ludovic Rousseau
> <ludovic.rousseau at gmail.com> a ?crit :
>> 
>> Le ven. 7 avr. 2023 ? 17:36, Allen Curtis
>> <allen at criticalsoftwaresolutions.com> a ?crit :
>>> 
>>> Below is the attached code distilled down to the relevant logic. The
>>> actual source files are attached as well for your review.
>> 
>> Please provide a MINIMAL sample code. And a program that can run with
>> any reader name.
> 
> It looks like a bug on your code.
> From SCardEstablishContext() documentation
> https://pcsclite.apdu.fr/api/group__API.html#gaa1b8970169fd4883a6dc4a8f43f19b67
> " This must be the first WinSCard function called in a PC/SC
> application. Each thread of an application shall use its own
> SCARDCONTEXT, unless calling SCardCancel(), which MUST be called with
> the same context as the context used to call SCardGetStatusChange(). "
> 
> From your source code I see you use 2 threads but only one
> SCardEstablishContext() call.
> Fix your code and try again.
> 
> Bye
> 
> -- 
> Dr. Ludovic Rousseau
> 
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle



From allen at criticalsoftwaresolutions.com  Mon Apr 17 16:54:27 2023
From: allen at criticalsoftwaresolutions.com (Allen Curtis)
Date: Mon, 17 Apr 2023 16:54:27 -0700
Subject: [Pcsclite-muscle] How is SCARD_SCOPE_* used?
Message-ID: <CAFxo-rN_zSBUEXvkLKTwUPV1ejxXm8Ri1zg4FVS5xfz3h7iCTQ@mail.gmail.com>

Hello,

What is the purpose of the SCARD_SCOPE parameter? I have only seen a
scope of SYSTEM. I can have multiple active contexts with SYSTEM scope
so this isn't a mutex.


-- 
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC


From s.brunner at stephan-brunner.net  Tue Apr 18 00:08:48 2023
From: s.brunner at stephan-brunner.net (Stephan Brunner)
Date: Tue, 18 Apr 2023 09:08:48 +0200
Subject: [Pcsclite-muscle] How is SCARD_SCOPE_* used?
In-Reply-To: <CAFxo-rN_zSBUEXvkLKTwUPV1ejxXm8Ri1zg4FVS5xfz3h7iCTQ@mail.gmail.com>
References: <CAFxo-rN_zSBUEXvkLKTwUPV1ejxXm8Ri1zg4FVS5xfz3h7iCTQ@mail.gmail.com>
Message-ID: <763a3d314c7c9da519448e39ebc4b03e85393af7.camel@stephan-brunner.net>

Hi,

> I have only seen a scope of SYSTEM.

AFAIK, Windows supports passthrough of smartcards via RDP.
So, under the User-Scope the card should appear, but under System-Scope not as the card should only be available for that particular user session (and only until the RDP session is disconnected).

I don't know whether PCSC-Lite supports user scopes of any kind, but the parameter surely is there for compatibility with Windows.

-- 
Mit freundlichen Gr??en / Best regards

Stephan Brunner, M.Sc.

Matrix: @boomer41:boomer41.net
PGP: 5FB325E81E548282D458A65114A30C9CE3AE4CE2

-------- Urspr?ngliche Nachricht --------
Von: Allen Curtis <allen at criticalsoftwaresolutions.com>
An: pcsclite-muscle at lists.infradead.org
Betreff: [Pcsclite-muscle] How is SCARD_SCOPE_* used?
Datum: 18.04.2023 01:54:27

Hello,

What is the purpose of the SCARD_SCOPE parameter? I have only seen a
scope of SYSTEM. I can have multiple active contexts with SYSTEM scope
so this isn't a mutex.




From ludovic.rousseau at gmail.com  Tue Apr 18 02:18:27 2023
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Tue, 18 Apr 2023 11:18:27 +0200
Subject: [Pcsclite-muscle] How is SCARD_SCOPE_* used?
In-Reply-To: <CAFxo-rN_zSBUEXvkLKTwUPV1ejxXm8Ri1zg4FVS5xfz3h7iCTQ@mail.gmail.com>
References: <CAFxo-rN_zSBUEXvkLKTwUPV1ejxXm8Ri1zg4FVS5xfz3h7iCTQ@mail.gmail.com>
Message-ID: <CAGstE8CLBf3cKaYWYQyNU4RFiLxq_5d2uBakghaJErMDoWJFtQ@mail.gmail.com>

Le mar. 18 avr. 2023 ? 01:55, Allen Curtis
<allen at criticalsoftwaresolutions.com> a ?crit :
>
> Hello,

Hi,

> What is the purpose of the SCARD_SCOPE parameter? I have only seen a
> scope of SYSTEM. I can have multiple active contexts with SYSTEM scope
> so this isn't a mutex.

https://pcsclite.apdu.fr/api/group__API.html#gaa1b8970169fd4883a6dc4a8f43f19b67

Bye

-- 
 Dr. Ludovic Rousseau


From sebastien at canihaz.net  Tue Apr 18 00:25:07 2023
From: sebastien at canihaz.net (Sebastien Requiem)
Date: Tue, 18 Apr 2023 09:25:07 +0200
Subject: [Pcsclite-muscle] Trouble using Yubikey 5 NFC
Message-ID: <f1e0bced-9022-4965-87f8-09a01f0d1028@app.fastmail.com>

Hi everyone,

I own a yubikey 5 NFC (see firmware version at the bottom) and decided to use it with gnupg via the openpgp applet. For a reminder, gpg communicates to the card via scdaemon, which in its turn communicates to pcsclite.

When using the yubikey in USB, I can import my rsa4096 key onto the key and the command gpg --card-status is able to enumerate the features and configuration of the key without problem.

However, when using the key via NFC (using ACS ACR122u nfcreader OR pn522 via UART),  I get a

$> gpg --card-status
gpg: OpenPGP card not available: Card error

(side note : when the NFC key does not contain any GPG key, the above  command succeeds.)

Debugging deeper, I found that scdaemon complains that the public key is not available and that an error has occured (see below)

DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=526 em=1
DBG:   PCSC_data: 00478100000002b600020e
apdu_send_simple(0) failed: unknown status error
reading public key failed: Missing item in object
DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=526 em=1
DBG:   PCSC_data: 00478100000002b800020e
DBG:  response: sw=9000  datalen=160
DBG:      dump: 9bc2bc67a6081d9af0d54255704f40abe284a345b5292c07fee98797494e2aeb \
DBG:  b99c262b4115ea00f01fedec0b816b307ade58a27faa8ca43d8499bb506eda80 \
DBG:  a3ba695ec0e93dcbe663317c44892db6d8eb0874eef0be90ccbfa4a95d35896f \
DBG:  9315056f082a40616c331f795295d7ff2311f60e69e3c635d234b4651e8870d9 \
DBG:  f4af1ecedb99cf2c169ddeac055bc4545d02fcf9bcdf94dbc130698203010001
response does not contain the public key data

Which lead me to debug pcsclite and see what response is sent by the token. It looks like the payload sent as a reply from the token is NOT what is expected and that makes the whole chain fail.
For a comparison, I attach a log file (see log-success.txt) when the command succeeds (via USB and not NFC), where we can see that, for the APDU 00 47 81 00, a different (and larger) payload is sent.


I must admit that I am unsure of what to do with all this. How can the yubikey reply two different payload when connected in USB and via NFC ? I searched the net in vain of anyone having the same issue but found nothing looking like it. Which makes me think that have a software issue somewhere.

I tried two NFC readers to try to isolate the issue but I got the same behavior (I think - I didnt  investigate the logs of pcsclite with pn522)

As for gpg, I tried gpg v2.2, v2.3 and v2.4 (and made sure to kill scdaemon and gpg-agent each time)  with no success.



Anyone has an idea of what is happening?




Useful information :
=======
pcsclite package version : 1.9.9-3
pcsc-lite version 1.9.9.
Copyright (C) 1999-2002 by David Corcoran <corcoran at musclecard.com>.
Copyright (C) 2001-2022 by Ludovic Rousseau <ludovic.rousseau at free.fr>.
Copyright (C) 2003-2004 by Damien Sauveron <sauveron at labri.fr>.
Report bugs to <pcsclite-muscle at lists.infradead.org>.
Enabled features: Linux x86_64-pc-linux-gnu libsystemd serial usb libudev usbdropdir=/usr/lib/pcsc/drivers ipcdir=/run/pcscd filter configdir=/etc/reader.conf.d
MAX_READERNAME: 128, PCSCLITE_MAX_READERS_CONTEXTS: 16


System : arch linux
packages :
- acsccid 1.1.9-1
- pcsclite 1.9.9-3
- ccid: 1.5.2-1
- libnfc: 1.8.0-2

Configuration : blacklist pn533, pn533_usb and nfc kernel modules

NFC reader : ACS ACR122u (USB connection))

Smart Card : yubikey 5 NFC - firmware 5.4.3


-- 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.txt
URL: <http://lists.infradead.org/pipermail/pcsclite-muscle/attachments/20230418/9204b2f7/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log-success.txt
URL: <http://lists.infradead.org/pipermail/pcsclite-muscle/attachments/20230418/9204b2f7/attachment-0003.txt>

From frankmorgner at gmail.com  Tue Apr 18 04:18:19 2023
From: frankmorgner at gmail.com (Frank Morgner)
Date: Tue, 18 Apr 2023 13:18:19 +0200
Subject: [Pcsclite-muscle] Trouble using Yubikey 5 NFC
In-Reply-To: <f1e0bced-9022-4965-87f8-09a01f0d1028@app.fastmail.com>
References: <f1e0bced-9022-4965-87f8-09a01f0d1028@app.fastmail.com>
Message-ID: <81fcd582-d05d-f2a3-94c9-4a95537bd1c9@gmail.com>

In the success case, you're transmitting/receiving extended APDUs:

[36m00000002[0m [140412329121472] winscard.c:1596:SCardTransmit() Send 
Protocol: T=1
[36m00000003[0m [140412329121472] [34mAPDU: 00 47 81 00 00 00 02 B8 
00 02 0E [0m
[36m00000002[0m [140412329121472] 
[34mifdhandler.c:1398:IFDHTransmitToICC() 
usb:1050/0407:libudev:2:/dev/bus/usb/001/024 (lun: 0)[0m
[36m00000002[0m [140412329121472] 
commands.c:1679:CmdXfrBlockAPDU_extended() T=0 (extended): 11 bytes
[36m00000005[0m [140412329121472] -> 000000 6F 0B 00 00 00 00 1B 00 00 
00 00 47 81 00 00 00 02 B8 00 02 0E
[36m00003098[0m [140412329121472] <- 000000 80 10 02 00 00 00 1B 00 00 
00 7F 49 82 02 09 81 82 02 00 B7 CC CF C6 D0 24 F6 7A FD 7F EE A0 35 E3 
26 B2 C9 C1 B2 15 A2 6C E1 91 B5 79 99 EC 7D 87 8E 2C AC 74 4C 25 28 26 
FC 37 CC 99 73 77 4A 11 A7 F1 FD D3 15 1C 88 E8 7D C3 87 54 64 E7 7A F4 
36 F8 3D 36 8F AF 30 64 35 ED EF 9B 97 45 E6 3A 12 FB 67 6A E2 B6 E4 41 
30 BF 76 F5 0A 12 63 67 9D 8F 82 CA 2E 5A 21 AF 11 A5 E2 57 91 B5 8F 2E 
60 D1 3D BF 4B DE AA A6 CE 3F DA 36 41 D4 B4 52 92 48 7F E5 67 3D 52 65 
95 44 B3 7D DB A0 9F 7C 78 54 84 05 64 80 49 7A 48 5B C1 F8 F7 91 59 C1 
B4 8D 84 42 C7 19 E2 04 01 26 A4 47 53 2B 7D 16 1B 68 67 37 1C 92 CA 12 
E6 A1 01 94 18 AF 71 79 E5 6B 08 AF 33 FA AA EF 4F E1 1C EB A9 80 A0 90 
6B 21 2C 35 BB 93 93 D3 9E 43 46 C8 4C 46 1F 9F C3 0E 5A 3B 7B 75 52 AB 
D4 03 81 A8 A1 5E EB 12 58 D4 C8 70 21 B3 99 55 DB D5 89 D4 48 06 41 AE 
C3 3A 28 62 E5 CC 7C 74 6B A6 10 F4 2A F6 A3 E1 B1 74 A7 3C BD 7E D4 40 
0E 84 B9 A5 2D 0E D9 BA 66 F6 70 C2 4E 82 60 27 98 6A A6 57 A3 63 4D E7 
B9 9F 6D 15 52 30 C4 8F E7 AE E0 A8 D5 70 76 FD BD 4A A7 35 4F A5 DA 74 
9E 47 16 5C 87 6B 26 F5 B0 F3 FA 40 6E 20 B8 9D 34 F2 B9 1B 5D 31 17 46 
22 4A A5 EB 11 16 FA DF AE F4 70 E2 3B 3E 42 69 A2 8D EC 5B 5D 76 40 77 
1C 72 51 09 DA 2E 73 79 D4 F9 CA E0 D5 07 BD EB 1A CB 2E 56 62 6B 68 A4 
37 85 15 4E 5A 6E BC B2 47 4F 01 42 E1 9F 69 4A E8 C8 25 9C 0D B2 A2 E1 
EA CC 0F B6 DA C7 C6 9B 40 C1 48 3E C5 5E B4 55 3A 62 24 81 BC EA E2 D1 
26 1E 39 DC 63 8F 7B D4 51 5C 07 9B C9 D4 29 4E 4E 46 C1 BD 6D 7B 07 01 
59 7F 4E F6 6C FC 94 4D 4E 5F 30 78 6D F4 37 DF 14 88 68 AB 3A 37 84 CC 
6D 22 FB EA 21 E4 BA C2 3F 98 E4 BD 38 E8 80 14 57 A9 82 03 01 00 01 90 00
[36m00000064[0m [140412329121472] [34mSW: 7F 49 82 02 09 81 82 02 00 
B7 CC CF C6 D0 24 F6 7A FD 7F EE A0 35 E3 26 B2 C9 C1 B2 15 A2 6C E1 91 
B5 79 99 EC 7D 87 8E 2C AC 74 4C 25 28 26 FC 37 CC 99 73 77 4A 11 A7 F1 
FD D3 15 1C 88 E8 7D C3 87 54 64 E7 7A F4 36 F8 3D 36 8F AF 30 64 35 ED 
EF 9B 97 45 E6 3A 12 FB 67 6A E2 B6 E4 41 30 BF 76 F5 0A 12 63 67 9D 8F 
82 CA 2E 5A 21 AF 11 A5 E2 57 91 B5 8F 2E 60 D1 3D BF 4B DE AA A6 CE 3F 
DA 36 41 D4 B4 52 92 48 7F E5 67 3D 52 65 95 44 B3 7D DB A0 9F 7C 78 54 
84 05 64 80 49 7A 48 5B C1 F8 F7 91 59 C1 B4 8D 84 42 C7 19 E2 04 01 26 
A4 47 53 2B 7D 16 1B 68 67 37 1C 92 CA 12 E6 A1 01 94 18 AF 71 79 E5 6B 
08 AF 33 FA AA EF 4F E1 1C EB A9 80 A0 90 6B 21 2C 35 BB 93 93 D3 9E 43 
46 C8 4C 46 1F 9F C3 0E 5A 3B 7B 75 52 AB D4 03 81 A8 A1 5E EB 12 58 D4 
C8 70 21 B3 99 55 DB D5 89 D4 48 06 41 AE C3 3A 28 62 E5 CC 7C 74 6B A6 
10 F4 2A F6 A3 E1 B1 74 A7 3C BD 7E D4 40 0E 84 B9 A5 2D 0E D9 BA 66 F6 
70 C2 4E 82 60 27 98 6A A6 57 A3 63 4D E7 B9 9F 6D 15 52 30 C4 8F E7 AE 
E0 A8 D5 70 76 FD BD 4A A7 35 4F A5 DA 74 9E 47 16 5C 87 6B 26 F5 B0 F3 
FA 40 6E 20 B8 9D 34 F2 B9 1B 5D 31 17 46 22 4A A5 EB 11 16 FA DF AE F4 
70 E2 3B 3E 42 69 A2 8D EC 5B 5D 76 40 77 1C 72 51 09 DA 2E 73 79 D4 F9 
CA E0 D5 07 BD EB 1A CB 2E 56 62 6B 68 A4 37 85 15 4E 5A 6E BC B2 47 4F 
01 42 E1 9F 69 4A E8 C8 25 9C 0D B2 A2 E1 EA CC 0F B6 DA C7 C6 9B 40 C1 
48 3E C5 5E B4 55 3A 62 24 81 BC EA E2 D1 26 1E 39 DC 63 8F 7B D4 51 5C 
07 9B C9 D4 29 4E 4E 46 C1 BD 6D 7B 07 01 59 7F 4E F6 6C FC 94 4D 4E 5F 
30 78 6D F4 37 DF 14 88 68 AB 3A 37 84 CC 6D 22 FB EA 21 E4 BA C2 3F 98 
E4 BD 38 E8 80 14 57 A9 82 03 01 00 01 90 00 [0m
[36m00000016[0m [140412329121472] winscard.c:1649:SCardTransmit() 
UnrefReader() count was: 2

In the error case, you're transmitting the same command as short APDU 
(although it is formatted as extended APDU):

[36m00000002[0m [140298807559872] winscard.c:1596:SCardTransmit() Send 
Protocol: T=1
[36m00000001[0m [140298807559872] [34mAPDU: 00 47 81 00 00 00 02 B8 
00 02 0E [0m
[36m00000002[0m [140298807559872] 
[34mifdhandler.c:1674:IFDHTransmitToICC() 
usb:072f/2200:libudev:0:/dev/bus/usb/001/013 (lun: 0)[0m
[36m00000001[0m [140298807559872] 
commands.c:1770:CmdXfrBlockAPDU_short() T=0: 11 bytes
[36m00000003[0m [140298807559872] -> 000000 6F 0B 00 00 00 00 1C 00 00 
00 00 47 81 00 00 00 02 B8 00 02 0E
[36m00111157[0m [140298807559872] <- 000000 80 00 00 00 00 00 1C 00 FE 00
[36m00000020[0m [140298807559872] [34mSW: [0m
[36m00000009[0m [140298807559872] winscard.c:1649:SCardTransmit() 
UnrefReader() count was: 2

I would assume that the card wants to return 528 bytes just like in the 
contact-based success case, but that doesn't work either due to 
limitations of the reader, its firmware or even due to the card's 
limitation via the contact-less interface. If you don't find a way 
around this, try sending/receiving only short APDUs.

Just a sidenote, does the Yubikey support secure messaging? If not, 
you're contactlessly transmitting your PIN and the signing data without 
integrity and confidentiality.


Regards, Frank.


Am 18.04.23 um 09:25 schrieb Sebastien Requiem:
> Hi everyone,
>
> I own a yubikey 5 NFC (see firmware version at the bottom) and decided to use it with gnupg via the openpgp applet. For a reminder, gpg communicates to the card via scdaemon, which in its turn communicates to pcsclite.
>
> When using the yubikey in USB, I can import my rsa4096 key onto the key and the command gpg --card-status is able to enumerate the features and configuration of the key without problem.
>
> However, when using the key via NFC (using ACS ACR122u nfcreader OR pn522 via UART),  I get a
>
> $> gpg --card-status
> gpg: OpenPGP card not available: Card error
>
> (side note : when the NFC key does not contain any GPG key, the above  command succeeds.)
>
> Debugging deeper, I found that scdaemon complains that the public key is not available and that an error has occured (see below)
>
> DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=526 em=1
> DBG:   PCSC_data: 00478100000002b600020e
> apdu_send_simple(0) failed: unknown status error
> reading public key failed: Missing item in object
> DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=526 em=1
> DBG:   PCSC_data: 00478100000002b800020e
> DBG:  response: sw=9000  datalen=160
> DBG:      dump: 9bc2bc67a6081d9af0d54255704f40abe284a345b5292c07fee98797494e2aeb \
> DBG:  b99c262b4115ea00f01fedec0b816b307ade58a27faa8ca43d8499bb506eda80 \
> DBG:  a3ba695ec0e93dcbe663317c44892db6d8eb0874eef0be90ccbfa4a95d35896f \
> DBG:  9315056f082a40616c331f795295d7ff2311f60e69e3c635d234b4651e8870d9 \
> DBG:  f4af1ecedb99cf2c169ddeac055bc4545d02fcf9bcdf94dbc130698203010001
> response does not contain the public key data
>
> Which lead me to debug pcsclite and see what response is sent by the token. It looks like the payload sent as a reply from the token is NOT what is expected and that makes the whole chain fail.
> For a comparison, I attach a log file (see log-success.txt) when the command succeeds (via USB and not NFC), where we can see that, for the APDU 00 47 81 00, a different (and larger) payload is sent.
>
>
> I must admit that I am unsure of what to do with all this. How can the yubikey reply two different payload when connected in USB and via NFC ? I searched the net in vain of anyone having the same issue but found nothing looking like it. Which makes me think that have a software issue somewhere.
>
> I tried two NFC readers to try to isolate the issue but I got the same behavior (I think - I didnt  investigate the logs of pcsclite with pn522)
>
> As for gpg, I tried gpg v2.2, v2.3 and v2.4 (and made sure to kill scdaemon and gpg-agent each time)  with no success.
>
>
>
> Anyone has an idea of what is happening?
>
>
>
>
> Useful information :
> =======
> pcsclite package version : 1.9.9-3
> pcsc-lite version 1.9.9.
> Copyright (C) 1999-2002 by David Corcoran <corcoran at musclecard.com>.
> Copyright (C) 2001-2022 by Ludovic Rousseau <ludovic.rousseau at free.fr>.
> Copyright (C) 2003-2004 by Damien Sauveron <sauveron at labri.fr>.
> Report bugs to <pcsclite-muscle at lists.infradead.org>.
> Enabled features: Linux x86_64-pc-linux-gnu libsystemd serial usb libudev usbdropdir=/usr/lib/pcsc/drivers ipcdir=/run/pcscd filter configdir=/etc/reader.conf.d
> MAX_READERNAME: 128, PCSCLITE_MAX_READERS_CONTEXTS: 16
>
>
> System : arch linux
> packages :
> - acsccid 1.1.9-1
> - pcsclite 1.9.9-3
> - ccid: 1.5.2-1
> - libnfc: 1.8.0-2
>
> Configuration : blacklist pn533, pn533_usb and nfc kernel modules
>
> NFC reader : ACS ACR122u (USB connection))
>
> Smart Card : yubikey 5 NFC - firmware 5.4.3
>
>
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle


From f.dumas at ellis.siteparc.fr  Tue Apr 18 05:23:45 2023
From: f.dumas at ellis.siteparc.fr (Frederic Dumas)
Date: Tue, 18 Apr 2023 14:23:45 +0200
Subject: [Pcsclite-muscle] SCR333v1 - STCII DFU Adapter - firmware update
In-Reply-To: <8F22D74A-5899-476A-82CA-77A7D740293E@ellis.siteparc.fr>
References: <8F22D74A-5899-476A-82CA-77A7D740293E@ellis.siteparc.fr>
Message-ID: <48014D3F-796C-4576-8122-9EAB5FDF1AF0@ellis.siteparc.fr>


Hello to all,

in case it might be useful to someone in the future, I am answering my own question about the availability of the original firmware for SCR333 readers. Under WinXP, I managed to successfully reflash two SCR333 v1 USB readers using the following utility:

	SCR333_fw5.18.zip

The flashing utility requires Windows XP to run. It also requires that only one SCR333 reader be connected to the machine at a time.

This utility is available on driverguide:

	https://www.driverguide.com/driver/detail.php?driverid=390283

At the time I downloaded it, the md5 checksum of the zip archive is: 4bcc385985d826235eaf0296298ac8ce


When they were working properly, before they froze in "device firmware update" mode (reported as STC2 DFU in the USB device tree), these SCR333 drives probably had version 5.20 firmware as standard. From sparse information on the web, it seems to me that the latest firmware version for these readers that SCM has ever released is 5.25 or perhaps 5.26. I don't know how this differs from 5.18.

I hope it helps someone else.

--
Fr?d?ric Dumas
f.dumas at ellis.siteparc.fr




> Le 30 d?c. 2022 ? 15:35, Frederic Dumas <f.dumas at ellis.siteparc.fr> a ?crit :
> 
> 
> Hello everyone on the mailing list,
> 
> Ludovic invited me to ask my question to the members of this list. It is about the SCR333 card reader, from SCM Microsystems (the company has now become Identiv by merger-acquisition). This hardware, although perfectly compatible with the current standards, is considered "obsolete" by its manufacturer, who therefore no longer offers support for it.
> 
> One of these card readers [1], and a few months later a second, advertised themselves as "STCII DFU Adapter" on the USB bus, and became inaccessible through CCID. The matter is identified in the manufacturer's documentation [2]; it would be enough to reflash the reader with the original firmware to fix it.
> 
> On its website, the manufacturer no longer provides the firmware. Its online technical support is also unable to find a copy of this firmware.
> 
> 
> Does any of you on the list have the SCM's firmware for the SCR333 card reader in your archives?
> 
> 
> The Common Access Card web page [3], maintained by a retired US military man, offers firmware for the SCR331 model and another for the SCR3310 model, available for download. Thanks to a nice guy at Cardlogix for redirecting me to this resource.
> 
> Do either of these two readers share the same PCB with the SCR333 (i.e. the same firmware)?
> 
> 
> More out of curiosity, but also a bit for practical purposes, does anyone also know what the trigger might be that causes the firmware to "corrupt"? Could an electrostatic shock have altered the flash memory of the STC microcontroller? Or would the old firmware versions be sensitive to a magic word that they see passing over the USB bus? Without understanding the cause, I could only observe that "suddenly" one or the other drive was no longer seen as a CCID device.
> 
> Thanks in advance for any advice!
> 
> 
> Fr?d?ric
> 
> [1] SCR333 V1 ; the PCB reads: rev 1.1 12 DEC 2002
> [2] Smartcard Reader - Installation & Troubleshooting Manual - Version 1.0 - November 17, 2008, p.17
> [3] https://militarycac.org/cacdrivers.htm
> 
> --
> Fr?d?ric Dumas
> f.dumas at ellis.siteparc.fr







From sebastien at canihaz.net  Wed Apr 19 10:30:41 2023
From: sebastien at canihaz.net (Sebastien Requiem)
Date: Wed, 19 Apr 2023 19:30:41 +0200
Subject: [Pcsclite-muscle] Trouble using Yubikey 5 NFC
In-Reply-To: <81fcd582-d05d-f2a3-94c9-4a95537bd1c9@gmail.com>
References: <f1e0bced-9022-4965-87f8-09a01f0d1028@app.fastmail.com>
 <81fcd582-d05d-f2a3-94c9-4a95537bd1c9@gmail.com>
Message-ID: <a8f9ee16-5df3-4a58-a831-edb7d37d1c3b@app.fastmail.com>

Hi Frank and others,

This now makes sense and you spotted the issue correctly.  Had I been a bit more careful when I bought an ACS122u I would have noticed that pcsc homepage mentions the lack of extended apdu (see https://ccid.apdu.fr/ccid/unsupported.html#0x072F0x2200 ).

Since the middleware is scdaemon from gnupg, it is futile to offer a patch that modifies the communication protocol so that extended  payload would be made by short apdu (multiple calls and  offset) knowing that the code relies heavily on extended mode and knowing that the middleware cannot know in advance if extended apdu is  available on the hardware or not.

I ended up shifting from RSA4096 to ECC 25519 which reduces the key size and everything works as expected now.

Thanks for the help!

Cheers,

On Tue, Apr 18, 2023, at 1:18 PM, Frank Morgner wrote:
> In the success case, you're transmitting/receiving extended APDUs:
>
> [36m00000002[0m [140412329121472] winscard.c:1596:SCardTransmit() Send 
> Protocol: T=1
> [36m00000003[0m [140412329121472] [34mAPDU: 00 47 81 00 00 00 02 B8 
> 00 02 0E [0m
> [36m00000002[0m [140412329121472] 
> [34mifdhandler.c:1398:IFDHTransmitToICC() 
> usb:1050/0407:libudev:2:/dev/bus/usb/001/024 (lun: 0)[0m
> [36m00000002[0m [140412329121472] 
> commands.c:1679:CmdXfrBlockAPDU_extended() T=0 (extended): 11 bytes
> [36m00000005[0m [140412329121472] -> 000000 6F 0B 00 00 00 00 1B 00 00 
> 00 00 47 81 00 00 00 02 B8 00 02 0E
> [36m00003098[0m [140412329121472] <- 000000 80 10 02 00 00 00 1B 00 00 
> 00 7F 49 82 02 09 81 82 02 00 B7 CC CF C6 D0 24 F6 7A FD 7F EE A0 35 E3 
> 26 B2 C9 C1 B2 15 A2 6C E1 91 B5 79 99 EC 7D 87 8E 2C AC 74 4C 25 28 26 
> FC 37 CC 99 73 77 4A 11 A7 F1 FD D3 15 1C 88 E8 7D C3 87 54 64 E7 7A F4 
> 36 F8 3D 36 8F AF 30 64 35 ED EF 9B 97 45 E6 3A 12 FB 67 6A E2 B6 E4 41 
> 30 BF 76 F5 0A 12 63 67 9D 8F 82 CA 2E 5A 21 AF 11 A5 E2 57 91 B5 8F 2E 
> 60 D1 3D BF 4B DE AA A6 CE 3F DA 36 41 D4 B4 52 92 48 7F E5 67 3D 52 65 
> 95 44 B3 7D DB A0 9F 7C 78 54 84 05 64 80 49 7A 48 5B C1 F8 F7 91 59 C1 
> B4 8D 84 42 C7 19 E2 04 01 26 A4 47 53 2B 7D 16 1B 68 67 37 1C 92 CA 12 
> E6 A1 01 94 18 AF 71 79 E5 6B 08 AF 33 FA AA EF 4F E1 1C EB A9 80 A0 90 
> 6B 21 2C 35 BB 93 93 D3 9E 43 46 C8 4C 46 1F 9F C3 0E 5A 3B 7B 75 52 AB 
> D4 03 81 A8 A1 5E EB 12 58 D4 C8 70 21 B3 99 55 DB D5 89 D4 48 06 41 AE 
> C3 3A 28 62 E5 CC 7C 74 6B A6 10 F4 2A F6 A3 E1 B1 74 A7 3C BD 7E D4 40 
> 0E 84 B9 A5 2D 0E D9 BA 66 F6 70 C2 4E 82 60 27 98 6A A6 57 A3 63 4D E7 
> B9 9F 6D 15 52 30 C4 8F E7 AE E0 A8 D5 70 76 FD BD 4A A7 35 4F A5 DA 74 
> 9E 47 16 5C 87 6B 26 F5 B0 F3 FA 40 6E 20 B8 9D 34 F2 B9 1B 5D 31 17 46 
> 22 4A A5 EB 11 16 FA DF AE F4 70 E2 3B 3E 42 69 A2 8D EC 5B 5D 76 40 77 
> 1C 72 51 09 DA 2E 73 79 D4 F9 CA E0 D5 07 BD EB 1A CB 2E 56 62 6B 68 A4 
> 37 85 15 4E 5A 6E BC B2 47 4F 01 42 E1 9F 69 4A E8 C8 25 9C 0D B2 A2 E1 
> EA CC 0F B6 DA C7 C6 9B 40 C1 48 3E C5 5E B4 55 3A 62 24 81 BC EA E2 D1 
> 26 1E 39 DC 63 8F 7B D4 51 5C 07 9B C9 D4 29 4E 4E 46 C1 BD 6D 7B 07 01 
> 59 7F 4E F6 6C FC 94 4D 4E 5F 30 78 6D F4 37 DF 14 88 68 AB 3A 37 84 CC 
> 6D 22 FB EA 21 E4 BA C2 3F 98 E4 BD 38 E8 80 14 57 A9 82 03 01 00 01 90 00
> [36m00000064[0m [140412329121472] [34mSW: 7F 49 82 02 09 81 82 02 00 
> B7 CC CF C6 D0 24 F6 7A FD 7F EE A0 35 E3 26 B2 C9 C1 B2 15 A2 6C E1 91 
> B5 79 99 EC 7D 87 8E 2C AC 74 4C 25 28 26 FC 37 CC 99 73 77 4A 11 A7 F1 
> FD D3 15 1C 88 E8 7D C3 87 54 64 E7 7A F4 36 F8 3D 36 8F AF 30 64 35 ED 
> EF 9B 97 45 E6 3A 12 FB 67 6A E2 B6 E4 41 30 BF 76 F5 0A 12 63 67 9D 8F 
> 82 CA 2E 5A 21 AF 11 A5 E2 57 91 B5 8F 2E 60 D1 3D BF 4B DE AA A6 CE 3F 
> DA 36 41 D4 B4 52 92 48 7F E5 67 3D 52 65 95 44 B3 7D DB A0 9F 7C 78 54 
> 84 05 64 80 49 7A 48 5B C1 F8 F7 91 59 C1 B4 8D 84 42 C7 19 E2 04 01 26 
> A4 47 53 2B 7D 16 1B 68 67 37 1C 92 CA 12 E6 A1 01 94 18 AF 71 79 E5 6B 
> 08 AF 33 FA AA EF 4F E1 1C EB A9 80 A0 90 6B 21 2C 35 BB 93 93 D3 9E 43 
> 46 C8 4C 46 1F 9F C3 0E 5A 3B 7B 75 52 AB D4 03 81 A8 A1 5E EB 12 58 D4 
> C8 70 21 B3 99 55 DB D5 89 D4 48 06 41 AE C3 3A 28 62 E5 CC 7C 74 6B A6 
> 10 F4 2A F6 A3 E1 B1 74 A7 3C BD 7E D4 40 0E 84 B9 A5 2D 0E D9 BA 66 F6 
> 70 C2 4E 82 60 27 98 6A A6 57 A3 63 4D E7 B9 9F 6D 15 52 30 C4 8F E7 AE 
> E0 A8 D5 70 76 FD BD 4A A7 35 4F A5 DA 74 9E 47 16 5C 87 6B 26 F5 B0 F3 
> FA 40 6E 20 B8 9D 34 F2 B9 1B 5D 31 17 46 22 4A A5 EB 11 16 FA DF AE F4 
> 70 E2 3B 3E 42 69 A2 8D EC 5B 5D 76 40 77 1C 72 51 09 DA 2E 73 79 D4 F9 
> CA E0 D5 07 BD EB 1A CB 2E 56 62 6B 68 A4 37 85 15 4E 5A 6E BC B2 47 4F 
> 01 42 E1 9F 69 4A E8 C8 25 9C 0D B2 A2 E1 EA CC 0F B6 DA C7 C6 9B 40 C1 
> 48 3E C5 5E B4 55 3A 62 24 81 BC EA E2 D1 26 1E 39 DC 63 8F 7B D4 51 5C 
> 07 9B C9 D4 29 4E 4E 46 C1 BD 6D 7B 07 01 59 7F 4E F6 6C FC 94 4D 4E 5F 
> 30 78 6D F4 37 DF 14 88 68 AB 3A 37 84 CC 6D 22 FB EA 21 E4 BA C2 3F 98 
> E4 BD 38 E8 80 14 57 A9 82 03 01 00 01 90 00 [0m
> [36m00000016[0m [140412329121472] winscard.c:1649:SCardTransmit() 
> UnrefReader() count was: 2
>
> In the error case, you're transmitting the same command as short APDU 
> (although it is formatted as extended APDU):
>
> [36m00000002[0m [140298807559872] winscard.c:1596:SCardTransmit() Send 
> Protocol: T=1
> [36m00000001[0m [140298807559872] [34mAPDU: 00 47 81 00 00 00 02 B8 
> 00 02 0E [0m
> [36m00000002[0m [140298807559872] 
> [34mifdhandler.c:1674:IFDHTransmitToICC() 
> usb:072f/2200:libudev:0:/dev/bus/usb/001/013 (lun: 0)[0m
> [36m00000001[0m [140298807559872] 
> commands.c:1770:CmdXfrBlockAPDU_short() T=0: 11 bytes
> [36m00000003[0m [140298807559872] -> 000000 6F 0B 00 00 00 00 1C 00 00 
> 00 00 47 81 00 00 00 02 B8 00 02 0E
> [36m00111157[0m [140298807559872] <- 000000 80 00 00 00 00 00 1C 00 FE 00
> [36m00000020[0m [140298807559872] [34mSW: [0m
> [36m00000009[0m [140298807559872] winscard.c:1649:SCardTransmit() 
> UnrefReader() count was: 2
>
> I would assume that the card wants to return 528 bytes just like in the 
> contact-based success case, but that doesn't work either due to 
> limitations of the reader, its firmware or even due to the card's 
> limitation via the contact-less interface. If you don't find a way 
> around this, try sending/receiving only short APDUs.
>
> Just a sidenote, does the Yubikey support secure messaging? If not, 
> you're contactlessly transmitting your PIN and the signing data without 
> integrity and confidentiality.
>
>
> Regards, Frank.
>
>
> Am 18.04.23 um 09:25 schrieb Sebastien Requiem:
>> Hi everyone,
>>
>> I own a yubikey 5 NFC (see firmware version at the bottom) and decided to use it with gnupg via the openpgp applet. For a reminder, gpg communicates to the card via scdaemon, which in its turn communicates to pcsclite.
>>
>> When using the yubikey in USB, I can import my rsa4096 key onto the key and the command gpg --card-status is able to enumerate the features and configuration of the key without problem.
>>
>> However, when using the key via NFC (using ACS ACR122u nfcreader OR pn522 via UART),  I get a
>>
>> $> gpg --card-status
>> gpg: OpenPGP card not available: Card error
>>
>> (side note : when the NFC key does not contain any GPG key, the above  command succeeds.)
>>
>> Debugging deeper, I found that scdaemon complains that the public key is not available and that an error has occured (see below)
>>
>> DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=526 em=1
>> DBG:   PCSC_data: 00478100000002b600020e
>> apdu_send_simple(0) failed: unknown status error
>> reading public key failed: Missing item in object
>> DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=526 em=1
>> DBG:   PCSC_data: 00478100000002b800020e
>> DBG:  response: sw=9000  datalen=160
>> DBG:      dump: 9bc2bc67a6081d9af0d54255704f40abe284a345b5292c07fee98797494e2aeb \
>> DBG:  b99c262b4115ea00f01fedec0b816b307ade58a27faa8ca43d8499bb506eda80 \
>> DBG:  a3ba695ec0e93dcbe663317c44892db6d8eb0874eef0be90ccbfa4a95d35896f \
>> DBG:  9315056f082a40616c331f795295d7ff2311f60e69e3c635d234b4651e8870d9 \
>> DBG:  f4af1ecedb99cf2c169ddeac055bc4545d02fcf9bcdf94dbc130698203010001
>> response does not contain the public key data
>>
>> Which lead me to debug pcsclite and see what response is sent by the token. It looks like the payload sent as a reply from the token is NOT what is expected and that makes the whole chain fail.
>> For a comparison, I attach a log file (see log-success.txt) when the command succeeds (via USB and not NFC), where we can see that, for the APDU 00 47 81 00, a different (and larger) payload is sent.
>>
>>
>> I must admit that I am unsure of what to do with all this. How can the yubikey reply two different payload when connected in USB and via NFC ? I searched the net in vain of anyone having the same issue but found nothing looking like it. Which makes me think that have a software issue somewhere.
>>
>> I tried two NFC readers to try to isolate the issue but I got the same behavior (I think - I didnt  investigate the logs of pcsclite with pn522)
>>
>> As for gpg, I tried gpg v2.2, v2.3 and v2.4 (and made sure to kill scdaemon and gpg-agent each time)  with no success.
>>
>>
>>
>> Anyone has an idea of what is happening?
>>
>>
>>
>>
>> Useful information :
>> =======
>> pcsclite package version : 1.9.9-3
>> pcsc-lite version 1.9.9.
>> Copyright (C) 1999-2002 by David Corcoran <corcoran at musclecard.com>.
>> Copyright (C) 2001-2022 by Ludovic Rousseau <ludovic.rousseau at free.fr>.
>> Copyright (C) 2003-2004 by Damien Sauveron <sauveron at labri.fr>.
>> Report bugs to <pcsclite-muscle at lists.infradead.org>.
>> Enabled features: Linux x86_64-pc-linux-gnu libsystemd serial usb libudev usbdropdir=/usr/lib/pcsc/drivers ipcdir=/run/pcscd filter configdir=/etc/reader.conf.d
>> MAX_READERNAME: 128, PCSCLITE_MAX_READERS_CONTEXTS: 16
>>
>>
>> System : arch linux
>> packages :
>> - acsccid 1.1.9-1
>> - pcsclite 1.9.9-3
>> - ccid: 1.5.2-1
>> - libnfc: 1.8.0-2
>>
>> Configuration : blacklist pn533, pn533_usb and nfc kernel modules
>>
>> NFC reader : ACS ACR122u (USB connection))
>>
>> Smart Card : yubikey 5 NFC - firmware 5.4.3
>>
>>
>>
>> _______________________________________________
>> pcsclite-muscle mailing list
>> pcsclite-muscle at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle

-- 
I keep my email short and concise to increase my productivity.
I encourage you to do the same when exchanging with me.


From ludovic.rousseau at gmail.com  Wed Apr 19 13:20:46 2023
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Wed, 19 Apr 2023 22:20:46 +0200
Subject: [Pcsclite-muscle] Trouble using Yubikey 5 NFC
In-Reply-To: <a8f9ee16-5df3-4a58-a831-edb7d37d1c3b@app.fastmail.com>
References: <f1e0bced-9022-4965-87f8-09a01f0d1028@app.fastmail.com>
 <81fcd582-d05d-f2a3-94c9-4a95537bd1c9@gmail.com> <a8f9ee16-5df3-4a58-a831-edb7d37d1c3b@app.fastmail.com>
Message-ID: <CAGstE8AZ-e43OogtTcweM3+ML=zASHkCszc6VTGNx8wUiwW8ug@mail.gmail.com>

Le mer. 19 avr. 2023 ? 19:32, Sebastien Requiem
<sebastien at canihaz.net> a ?crit :
>
> Hi Frank and others,

Hello,

> This now makes sense and you spotted the issue correctly.  Had I been a bit more careful when I bought an ACS122u I would have noticed that pcsc homepage mentions the lack of extended apdu (see https://ccid.apdu.fr/ccid/unsupported.html#0x072F0x2200 ).

> Since the middleware is scdaemon from gnupg, it is futile to offer a patch that modifies the communication protocol so that extended  payload would be made by short apdu (multiple calls and  offset) knowing that the code relies heavily on extended mode and knowing that the middleware cannot know in advance if extended apdu is  available on the hardware or not.

The middleware can know if a reader supports, or not, extended APDU.
See "Extended APDU support reported by PC/SC (part 2)" (from 2012)
https://ludovicrousseau.blogspot.com/2012/04/extended-apdu-support-reported-by-pcsc.html

> I ended up shifting from RSA4096 to ECC 25519 which reduces the key size and everything works as expected now.

That is a solution :-)

If you are looking for a contactless reader that supports extended
APDU you can have a look at this list:
https://ccid.apdu.fr/select_readers/index.html?features=contactless&dwFeatures%E2%89%A013

Bye

-- 
 Dr. Ludovic Rousseau


From sebastien at canihaz.net  Wed Apr 19 23:34:50 2023
From: sebastien at canihaz.net (Sebastien Requiem)
Date: Thu, 20 Apr 2023 08:34:50 +0200
Subject: [Pcsclite-muscle] Trouble using Yubikey 5 NFC
In-Reply-To: <CAGstE8AZ-e43OogtTcweM3+ML=zASHkCszc6VTGNx8wUiwW8ug@mail.gmail.com>
References: <f1e0bced-9022-4965-87f8-09a01f0d1028@app.fastmail.com>
 <81fcd582-d05d-f2a3-94c9-4a95537bd1c9@gmail.com>
 <a8f9ee16-5df3-4a58-a831-edb7d37d1c3b@app.fastmail.com>
 <CAGstE8AZ-e43OogtTcweM3+ML=zASHkCszc6VTGNx8wUiwW8ug@mail.gmail.com>
Message-ID: <895ce51e-0083-4612-bea4-85dacbaf00e8@app.fastmail.com>

On Wed, Apr 19, 2023, at 10:20 PM, Ludovic Rousseau wrote:
> Le mer. 19 avr. 2023 ? 19:32, Sebastien Requiem
> <sebastien at canihaz.net> a ?crit :

>> Since the middleware is scdaemon from gnupg, it is futile to offer a patch that modifies the communication protocol so that extended  payload would be made by short apdu (multiple calls and  offset) knowing that the code relies heavily on extended mode and knowing that the middleware cannot know in advance if extended apdu is  available on the hardware or not.
>
> The middleware can know if a reader supports, or not, extended APDU.
> See "Extended APDU support reported by PC/SC (part 2)" (from 2012)
> https://ludovicrousseau.blogspot.com/2012/04/extended-apdu-support-reported-by-pcsc.html

Ah! A piece of information that I was missing when doing my research. And I believe that this discussion got spurred EXACTLY for the same reason that the feature has been implemented. (ie: clients sending long APDU to devices that dont support it).

I can now dedicate a bit of time to submit a patch for scdaemon if technically feasible.

>> I ended up shifting from RSA4096 to ECC 25519 which reduces the key size and everything works as expected now.
>
> That is a solution :-)

If you cannot go to the sea, make the sea come to you :-)

> If you are looking for a contactless reader that supports extended
> APDU you can have a look at this list:
> https://ccid.apdu.fr/select_readers/index.html?features=contactless&dwFeatures%E2%89%A013

Thanks for that and the assistance on the issue.


-- 


