运行某些 APDU 失败，说明无法使用协议 T0 传输。 法尔歇参数

Question

I'm having issues accessing SLE4428 cards under Windows 10 using an ACS ACR38U-I1, Python 3.7 and pyscard. I'm using the latest driver the manufacturer currently offers for Windows.

The main problem is that running certain APDUs fails, stating Failed to transmit with protocol T0. Falscher Parameter Failed to transmit with protocol T0. Falscher Parameter (= wrong parameter, error code 87). Running the exact same code with the same reader on a Raspberry Pi works flawlessly however. I have not installed any specific drivers on the Pi.

I'm using this code for running APDUs:

    from smartcard.CardType import AnyCardType
    from smartcard.CardConnection import CardConnection
    from smartcard.CardRequest import CardRequest
    
    cardtype = AnyCardType()
    cardrequest = CardRequest(timeout=1, cardType=cardtype)
    cardservice = cardrequest.waitforcard()
    cardservice.connection.connect(CardConnection.T0_protocol)
    apdu = [0xff, 0xb0, 0x00, 0x00, 0xff] #READ_MEMORY_CARD
    response, sw1, sw2 = cardservice.connection.transmit(apdu, CardConnection.T0_protocol)
    print('response: ', response, ' status words: ', "%x %x" % (sw1, sw2))

This code works fine on both platforms. Trying to authenticate using [0xff, 0x20, 0x00, 0x01, 0x03, 0xff, 0xff] however results in the crash described on Windows . I've tried the stock Windows driver as well as playing around with different protocols, no success.

Another weird behaviour that is exclusive to Windows: When inserting a card, the reader's LED flashes quickly and it takes around 9 seconds before the card can be accessed at all.

This is the first time I'm trying to interface with hardware, so it's probably something obvious, but I cannot figure it out. I'd appreciate any input and/or recommendations for (still available) readers that are known to work in this configuration.

Answer 1

Your three liner pretty much solved all the problems I was fighting for hours, thank you!

About the APDU: I took it from the ACR38X reference manual and you're right, it was for a different card. I don't know how I didn't notice that, since all the other APDU codes are structured similarly. The (wrong) code works does work fine under linux though, I just tested it again to make sure. Under Windows [0xff, 0x20, 0x00, 0x01, 0x02, 0xff, 0xff] (the last two bytes being the PIN/PSC) now responds with the expected answer (SW1 = 0x90, SW2 = 0xff for the PSC being correct, 0x00 for the card being locked or the actual error counter if both are not applicable).

About the certificate propagation service: Killing that service does not immediately solve the problem of the flashing & unresponsive reader. After plugging in the reader and killing the service, the same behaviour occurs for the first 3-4 cards. After that, it responds immediately after inserting new cards and the led stays lit. Still weird, but at least it's usable after a few cards now!

Answer 2

APDU CLA value 'FF' isn't allowed according to ISO 7816-4. Manufacturers of PC/SC readers sometime support APDU commands with CLA=FF to implement some specific functions like access to MIFARE cards or tuning of communication protocol settings.