[BUG] J3H145 card crash

[icedevml]

Something is very odd with J3H145 cards. One of the cards crashed entirely when I was testing the recent E-APDU fixes. Now I've took another card and loaded the master branch, it exhibits the same crash behavior. Steps to reproduce:

1. Register on https://demo.yubico.com/webauthn-technical/registration , that would create a normal FIDO2 authenticator (not resident credential)
2. Test authenticator on https://demo.yubico.com/webauthn-technical/login for once
3. Repeat step 1
4. Card goes entirely dead

I'm not able to talk to the card neither through contactless nor contact interface, it fails super early (on ISO 14443 selection). This doesn't happen with the exact same CAP file loaded on A40CR card.

For now I'm just dropping a report there, I need to order some more J3H145 cards and check if this is also reproducible.

[BryanJacobs]

I ran your stated process using my CTAP-HID bridge ( https://github.com/BryanJacobs/fido2-hid-bridge/ ) with Firefox on Linux.

It worked:

DEBUG:root:Sending CBOR to device CtapPcscDevice(HID OMNIKEY 5127 CK (010100534D4838383701542C41185730) 01 00): b'\x01\xa5\x01X v\x94\xc7T\xe6l\t\xb2@J\xcf\x85TL\xad\xe9@\xba?C\x90\x04\xb8C\xd2\x9fKe\xd8\xa3\xf0\xc1\x02\xa1bidodemo.yubico.com\x03\xa2bidX \xf1.\xcan\xd5\xa6\xee\xc3\xe9\x0b\xc9\x86/\xfe\x16UqG\xe2\xea\x0e\xe7\xeaERf\xb37\xf6\xc1\xeb\xcednamepYubico demo user\x04\x82\xa2calg&dtypejpublic-key\xa2calg9\x01\x00dtypejpublic-key\x07\xa1brk\xf4'
INFO:UHIDDevice:(UHID_INPUT2) send 6e22880d90012400a301667061636b65640258c4c46cef82ad1b546477591d008b08759ec3e6d2ecb4f39474bfea6969925d03b7410000000300000000000000
INFO:UHIDDevice:(UHID_INPUT2) send 6e22880d000000000000000000000040f1eda45a4b6636ec9c6c60530e7a85890075f861eb19ee7b8605ad8c571fbf38fe21b0591c2e4941f349e8fd48ad2d27
INFO:UHIDDevice:(UHID_INPUT2) send 6e22880d01ff029999b7ec59b3a4e2c89de3b04f40a50102032620012158203e87dbc979673db0750cdc76352b9ce98b42b4bf65faac7f0f2abe54555bd20422
INFO:UHIDDevice:(UHID_INPUT2) send 6e22880d0258205fadae39e131eb97826e610cc768668207db28364753e77c3b3e17cd82459a9903a263616c672663736967584630440220671c2624457b6550
INFO:UHIDDevice:(UHID_INPUT2) send 6e22880d031b951a4580bcf49e3417c35ac2ee67773e78c823dfb066c302203f230d808356650a0f258f0f778ca7183548fd0d862e9f5309bb480273cc806200
DEBUG:AsyncioBlockingUHID:device was closed (it now has 0 open instances)

No device crash. My testing card (ATR: 3B 80 80 01 01), also a J3H145 (of course ROM masks and such can differ):

# GlobalPlatformPro v20.08.12                                                                            
# Running on Linux 6.1.46-1-lts amd64, Java 11.0.20.1 by Oracle Corporation             
CPLC: ICFabricator=4790                             
      ICType=0503                                                                                        
      OperatingSystemID=8211
      OperatingSystemReleaseDate=6351 (2016-12-16)
      OperatingSystemReleaseLevel=0302
      ICFabricationDate=9061 (2019-03-02)
      ICSerialNumber=00567207
      ICBatchIdentifier=4888
      ICModuleFabricator=0000
      ICModulePackagingDate=0000 (2010-01-01)
      ICCManufacturer=0000
      ICEmbeddingDate=0000 (2010-01-01)
      ICPrePersonalizer=0000
      ICPrePersonalizationEquipmentDate=0000 (2010-01-01)
      ICPrePersonalizationEquipmentID=00000000
      ICPersonalizer=0000
      ICPersonalizationDate=0000 (2010-01-01)
      ICPersonalizationEquipmentID=00000000

IIN: 420100
CIN: 45080000000000000000
Card Data: 
Tag 6: 1.2.840.114283.1
-> Global Platform card
Tag 60: 1.2.840.114283.2.2.1.1
-> GP Version: 2.1.1
Tag 63: 1.2.840.114283.3
Tag 64: 1.2.840.114283.4.3.0
-> GP SCP03 i=00
Tag 66: 1.3.6.1.4.1.42.2.110.1.2
-> JavaCard v2
Card Capabilities: 
[WARN] GPData - Bogus data detected, fixing double tag
Supports SCP02 i=55
Supports SCP03 i=00 i=10 with AES-128 AES-196 AES-256
Supported DOM privileges: SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement, TrustedPath, AuthorizedManagement, TokenVerification, GlobalDelete, GlobalLock, GlobalRegistry, FinalApplication, Rece
iptGeneration
Supported APP privileges: CardLock, CardTerminate, CardReset, CVMManagement, FinalApplication, GlobalService
Supported LFDB hash: SHA-256
Supported Token Verification ciphers: RSA1024_SHA1, ECCP521_SHA512
Supported Receipt Generation ciphers: DES_MAC
Supported DAP Verification ciphers: RSA1024_SHA1, ECCP521_SHA512
Supported ECC Key Parameters: 0102030405
Version: 255 (0xFF) ID:   1 (0x01) type: AES          length:  16 (AES-128, factory key)
Version: 255 (0xFF) ID:   2 (0x02) type: AES          length:  16 (AES-128, factory key)
Version: 255 (0xFF) ID:   3 (0x03) type: AES          length:  16 (AES-128, factory key)

Current status of applets on the card:

ISD: A000000151000000 (OP_READY)
     Parent:   A000000151000000
     From:     A0000000620001
     Privs:    SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement, TrustedPath, AuthorizedManagement, TokenVerification, GlobalDelete, GlobalLock, GlobalRegistry, FinalApplication, ReceiptGeneration

APP: A0000006472F0001 (SELECTABLE) (|....G/..|)
     Parent:   A000000151000000
     From:     A000000647

PKG: A0000001515350 (LOADED) (SSD creation package)
     Applet:   A000000151535041 (SSD creation applet)

PKG: A000000647 (LOADED) (|....G|)
     Applet:   A0000006472F0001 (|....G/..|)

I'd love to figure out what happened on your end, but I haven't seen a "crash" per se myself. One thing to be aware of is that after applet install cycles, sometimes the J3H145 will return CARD_NOT_READY until its garbage collector has finished running; this requires some time sitting on the reader inactive.

I'll leave this issue open - please send more details if and as you find them. Thanks.

[icedevml]

Somehow the card went back to life after a series of random operations (iOS scan/Android scan/mashing through different PC/SC readers). Some of these actions caused the card to revive again o_O

This is the gp info out of the suspected card:

CPLC: ICFabricator=4790
      ICType=0503
      OperatingSystemID=8211
      OperatingSystemReleaseDate=6351 (2016-12-16)
      OperatingSystemReleaseLevel=0302
      ICFabricationDate=8350 (2018-12-16)
      ICSerialNumber=00428807
      ICBatchIdentifier=4652
      ICModuleFabricator=4E30
      ICModulePackagingDate=5038 (2015-02-07)
      ICCManufacturer=3530
      ICEmbeddingDate=474C (invalid date format)

It seems to be exactly equal to your card in terms of hw/sw, it's just a bit older than your card.

It must be something very specific to Windows. What allows to un-brick the card is to launch Linux and just keep the card on the reader for some time. So that really sounds like that GC problem.

I suspect that Windows is mashing the card by trying to auto-detect PIV applet etc (even if we don't do anything with the card at the moment). The card doesn't respond so the field is restarted and the card is again annoyed with a series of SELECT APDUs. So I bet Linux is not doing that, and the card has enough spare time to fix itself up, namely just to complete the GC.

[BryanJacobs]

This applet does basically nothing at all on a select, but yes, sending commands to the smartcard stops it from garbage collecting effectively.

I can't tell you that's what's going on, but still glad your card came "back to life". Note that the GC appears to only be necessary after a big applet install - I suspect that when these cards do a load-for-install they have a whole copy of the applet data waiting to be thrown away.

Once your card gets into a working steady state it shouldn't need GCs like that, and so should work reliably.

[icedevml]

Yeah I suspect that my workflow was to immediately take the card from the reader after the gradle build is finished. So I was not aware that this GC is not included in the install process itself. Sounds clear for now, I will be cautious around this. Thanks for your help!