[Pcsclite-muscle] Trouble using Yubikey 5 NFC

Sebastien Requiem sebastien at canihaz.net
Wed Apr 19 10:30:41 PDT 2023


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:
>
> 00000002 [140412329121472] winscard.c:1596:SCardTransmit() Send 
> Protocol: T=1
> 00000003 [140412329121472] APDU: 00 47 81 00 00 00 02 B8 
> 00 02 0E 
> 00000002 [140412329121472] 
> ifdhandler.c:1398:IFDHTransmitToICC() 
> usb:1050/0407:libudev:2:/dev/bus/usb/001/024 (lun: 0)
> 00000002 [140412329121472] 
> commands.c:1679:CmdXfrBlockAPDU_extended() T=0 (extended): 11 bytes
> 00000005 [140412329121472] -> 000000 6F 0B 00 00 00 00 1B 00 00 
> 00 00 47 81 00 00 00 02 B8 00 02 0E
> 00003098 [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
> 00000064 [140412329121472] SW: 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 
> 00000016 [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):
>
> 00000002 [140298807559872] winscard.c:1596:SCardTransmit() Send 
> Protocol: T=1
> 00000001 [140298807559872] APDU: 00 47 81 00 00 00 02 B8 
> 00 02 0E 
> 00000002 [140298807559872] 
> ifdhandler.c:1674:IFDHTransmitToICC() 
> usb:072f/2200:libudev:0:/dev/bus/usb/001/013 (lun: 0)
> 00000001 [140298807559872] 
> commands.c:1770:CmdXfrBlockAPDU_short() T=0: 11 bytes
> 00000003 [140298807559872] -> 000000 6F 0B 00 00 00 00 1C 00 00 
> 00 00 47 81 00 00 00 02 B8 00 02 0E
> 00111157 [140298807559872] <- 000000 80 00 00 00 00 00 1C 00 FE 00
> 00000020 [140298807559872] SW: 
> 00000009 [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.



More information about the pcsclite-muscle mailing list