OMNI Ring - defective product

[ckahlo]

Hi there,

first: I'm a professional JavaCard developer and followed your setup guide including Martins GlobalPlatform Pro (which is default here anyway). The reader is a Gemalto Prox-SU as this one has quite a lot of RF power and supports ISO14443-B quite well, I just wanted to be sure. The chip inside the ring seems to be an Infineon SLJ 52GLA080DL according to the specs.

I received my ring today and first tests worked like a charm. I wanted to test several applets to decide what to place on the ring. Among them was Ledgers U2F applet: https://github.com/LedgerHQ/ledger-u2f-javacard

At first everything was fine, I was able to generate FIDO keys, etc. But after a few tests the APDUs got stuck. The OMNI ring just did not respond and the reader ran into a timeout. Removing the ring and placing it back on the reader helped at first, but the APDU to generate a FIDO key got stuck again. (BTW: it needs secure random data to do this.)

So I decided to clean up the ring, delete all applet instances and packages and to start over with a small setup. The removal operations finished OK, the ring was clean, everything seemed fine.

I removed the ring to get some other work done. When I placed the ring back on the reader it didn't recognize the chip anymore. The LED only flashes in a fast intervall thus indicating an error.

So I spent a while with certain readers, mobile phones, etc. No one detecting the ring. IT IS DEAD.

After all, it took some hours to have a shiny, black, dead OMNI Ring as a developer used to write code for secure elements and USIMs.

What to do next? Is Infineon already aware of these problems with the chips?

This one is a candidate for a replacement. :-/

Best regards, Christian

[darconeous]

I've had my own problems with a sample OMNI. But even in that case I could still communicate with the chip, I was "just" locked out of the ISD. Sadly I had no other applications or security domains loaded at the time, so the ring is now apparently bricked. But hey, I can't personally complain: I got more than I paid for.

For what it's worth, I've found that my ACR122U-A9 will end up failing (returning a zero-length APDU) after doing a bunch of GP operations with the OMNI unless I remove and replace the ring after each GP operation. It seems that doing GP operations is a critical section that, if interrupted, can apparently brick the ring. I think that's what bit me above, but you aren't using an ACR122U. Plus it seems like your GP operations appeared to work fine. Maybe it really is defective hardware?

I really wish they used a different chip that was a little bit more friendly for developers, like a NXP P70. It makes is more difficult to figure out what is a hardware failure, versus "user error". But, alas.

I had another OMNI sample, onto which I was able to load this FIDO applet. I was able to use it on my mac using this tool, but because the rings are Type-B I could not use it with Android or iOS phones. I'm curious what device/software you were using with your ring before it got bricked?

[laurimihkels]

Hi Christian,

I'm sorry to hear that your ring has died. Our customer service has contacted you about the replacement ring.

If possible, can you give me more details for me to try to repeat the process as you did?

Hi Robert,

I vaguely remember having some issues with ACR122u in Linux where I had to remove the ring from the reader occasionally. Had no issues with ACR1252U and therefore thought it's the pcsc-lite compatibility issue with ACR122u.

[darconeous]

I vaguely remember having some issues with ACR122u in Linux where I had to remove the ring from the reader occasionally. Had no issues with ACR1252U and therefore thought it's the pcsc-lite compatibility issue with ACR122u.

FWIW, I'm on a Mac. I'll pick up an ACR1252u, if it has fewer problems. I could never get JCAlgTest to run to completion on an ACR122U.

[ckahlo]

Hi Robert! :-)

I've had my own problems with a sample OMNI. But even in that case I could still communicate with the chip, I was "just" locked out of the ISD. Sadly I had no other applications or security domains loaded at the time, so the ring is now apparently bricked. But hey, I can't personally complain: I got more than I paid for.

I've had a look into your gist. I suppose the ISD doesn't get any more random numbers? The issue with the SLE78 is RandomData.getInstance(RandomData.ALG_SECURE_RANDOM).generateData(). I've got two dead µSD cards (ASSDs) with a SLE78 on-board besides 8GB of flash. They died during elliptic curve key generation. I reported the issue, thought the JCRE was beta and had a glitch.

For what it's worth, I've found that my ACR122U-A9 will end up failing (returning a zero-length APDU) after doing a bunch of GP operations with the OMNI unless I remove and replace the ring after each GP operation. It seems that doing GP operations is a critical section that, if interrupted, can apparently brick the ring. I think that's what bit me above, but you aren't using an ACR122U. Plus it seems like your GP operations appeared to work fine. Maybe it really is defective hardware?

GP operation means install and such things. This involves heap traversal, sometimes garbage collection - at least moving stuff around in the EEPROM. If the EEPROM is defective either from the beginning or got some hickup during the later manufacturing process the (every) chip dies sooner or later. That's why our card manufacturer does burn-in tests after producing the cards from tested modules, some may die for whatever reason during the process. They deliver dozens of millions of cards per year for public transportation. Dying cards are not allowed there. ;-) Mobile network operators and banks do burn-in tests, too.

I never had a failing UICC or eSE, though. Even with installation / uninstallation / generating lots of keying material, etc. But they either feature a ST33F1ME or SLE97-series - both are 32 bit ARM SecureCore SC300, not 16-bit tandem ECO2000-successors. (the SLE88 was a 32-bit core, too)

I really wish they used a different chip that was a little bit more friendly for developers, like a NXP P70. It makes is more difficult to figure out what is a hardware failure, versus "user error". But, alas.

Yeah, the SLE78 tandem is quite happy to die fast. It is its job to die before they lose any secret. HSMs or SAMs are good places for them. The Global CISO of the manufacturer is a friend of mine. He was the first one who heard my "this f*cking chip died within two hours!". ;-) He laughed and said "that's what they're built for, they still know you".

Infact for the hackers, makers and security folks another chip might be better suited. I assume I had pretty bad luck with my ring. It doesn't need to be a sophisticated P7x, older modules are fine as well when they come in smaller packages with lower power requirements. Infineon has some options as well, or Broadcom, Samsung has its own incredibly small SC300 line as well.

I had another OMNI sample, onto which I was able to load this FIDO applet. I was able to use it on my mac using this tool, but because the rings are Type-B I could not use it with Android or iOS phones. I'm curious what device/software you were using with your ring before it got bricked?

Regarding Type-B, that's the stubborn Google Authenticator. They are requesting Type-A instead of IsoDep. Anyone from Google here who can hit the guy to change the requested tag type? ;-) FIDELIO has a development build that completely replaces FIDO functionality of Google Authenticator and it recognizes the ring like a charm.

I wanted to upload your applet next. It was just I had the Ledger applet compiled at hand in this moment. And generating a few keys was enough to kill the chip. :-/

May be the devs at McLear could try burn-ins with some plain chips and a bit help of us. So we could see if this is a problem that's common for the SLE78 or not. If we kill more chips it's up to Infineon to fix it finally, because then it would be a known issue since I reported that years ago.

Cheers, Christian

[ckahlo]

Hi Lauri,

Hi Christian,

I'm sorry to hear that your ring has died. Our customer service has contacted you about the replacement ring.

Yes, Chris wrote a message he would prepare a replacement ring and ship it as soon as possible. Thanks a lot for that. I hope I can be of any help in the future, too.

If possible, can you give me more details for me to try to repeat the process as you did?

Basically I started with installing the Ledger applet at first. I am the guy implementing

https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03110/index_htm.html and https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03159/tr03159.html on JavaCard in behalf of state/government institutions as a contractor. The code is quite demanding, we had to wait for years until UICC manufacturers had products capable to run the cryptography in full flavour. I just wanted to see if it returns with errors or down-graded algorithms (it is designed to do so in the test-phase to check out chip capabilities on the fly while performing the whole process). It went through, once, a second time, a third time, then it started to hang. So I thought OK, that might be a power issue despite the quite professional Gemalto PROX-SU reader. I deleted the applet and went on with tests with the FIDO applet. As we build enhanced FIDO applets, too. I ran a (slow stepped) test-suite verifying that user-presence is accepted, the certificate matches, the keys are correct and so on. This suddenly died on "generate credential", the stage when it needs secure random to generate the new key for the registration operation.

Well, that was basically all because I deleted the stuff and wanted to finish some work. That's the thing I needed the reader for ... one hour later or so the ring didn't respond to anything. ;-(

Best regards, Christian

[ckahlo]

I vaguely remember having some issues with ACR122u in Linux where I had to remove the ring from the reader occasionally. Had no issues with ACR1252U and therefore thought it's the pcsc-lite compatibility issue with ACR122u.

FWIW, I'm on a Mac. I'll pick up an ACR1252u, if it has fewer problems. I could never get JCAlgTest to run to completion on an ACR122U.

Robert try to get another reader. From the far distance just a suggestion: https://www.amazon.com/-/de/dp/B00TA3GQG0/

The ACR122 is cool to do "hacking" stuff with chinese mifare cards to change their UID because it allows 7-bit commands. But when it comes to ISO14443-4 its a bitch as you noticed before.

May be https://github.com/vrallev @vrallev has an idea where to get suitable readers in the US. He moved across the big pond.

He is my former working student while we were building the code for the new (back in 2010 of course) eID card in Germany. We had a lot of fun with readers. We're the guys that brought (together with NXP) Samsung and Sony to put better NFC chips (with more power and extended length APDUs) in their phones. We argued with Google not to "fix" the commits to the NFC stack, the guy in question broke it again in Android 4.2.1 - it was working in 4.2. ;-) Long, old stories.

Best regards, Christian

BTW: a good old SUN buddy is selling some original Java rings from the nineties on eBay https://www.ebay.com/itm/JAVA-RING-RARE-Sun-Microsystems-JAVA-ONE-Promo-/300495374337 I've got mine from a JavaOne conference more than 20 years ago and he saved the rings when Oracle bought out Sun. I talked to him this afternoon and clicked a 2nd ring. If you want an original for your personal museum get one from him. He seems to be a pretty cool guy as well. :-)

[darconeous]

The issue with the SLE78 is RandomData.getInstance(RandomData.ALG_SECURE_RANDOM).generateData(). I've got two dead µSD cards (ASSDs) with a SLE78 on-board besides 8GB of flash.

Interesting. I wonder if their ALG_SECURE_RANDOM implementation is does any EEPROM/Flash writes. I don't have NDA access, so I can only speculate.

Yeah, the SLE78 tandem is quite happy to die fast. It is its job to die before they lose any secret.

Indeed. These sorts of chips have two distinct goals: reliable operation and attack resistance, although I feel like some of the chips I've used recently are just simply unreliable, especially when field tearing occurs. And by that I don't just mean the OMNI, I've bricked an ACOSJ card, too. I always assumed it was because these cards were intended to be personalized once and that's it. I feel like there are many edge cases with repeated app install/uninstall cycles that seem to bring out the worst in many card-format SEs. But honestly, my sample size is too small to make any sweeping claims with certainty: you seem to have a lot more experience on this front.

Infact for the hackers, makers and security folks another chip might be better suited. I assume I had pretty bad luck with my ring. It doesn't need to be a sophisticated P7x, older modules are fine as well when they come in smaller packages with lower power requirements.

I mentioned the NXP P7x because I have a couple of cards and they have been very reliable and very fast. They also support JC 3.0.5, which is nice for those of us unwilling to sign NDAs. But a NXP P60 would also be fantastic from my point of view. Most of my experience with non-NXP chips has been relatively negative, at least from a JC development point of view.

Regarding Type-B, that's the stubborn Google Authenticator. They are requesting Type-A instead of IsoDep.

iOS appears to be in the same boat.

Anyone from Google here who can hit the guy to change the requested tag type? ;-)

Heh, I can file a bug and see what happens. Although recently it seems that the webauthn stuff doesn't go through Google Authenticator anymore, it appears directly implemented in Chrome.

FWIW, I'm on a Mac. I'll pick up an ACR1252u, if it has fewer problems. I could never get JCAlgTest to run to completion on an ACR122U.

Robert try to get another reader. From the far distance just a suggestion: https://www.amazon.com/-/de/dp/B00TA3GQG0/

Yes, I have a few PN533-based dongles, including that one. I use them when I need something that works reliably with libnfc. However, you can't beat the convenience of a reader that offers a CCID interface, like the ACR122U does.

I have not yet found a reliable way to get a SCL3711 to appear as a smart card reader on a mac (which is my primary machine). At one point I did get ifdnfc kinda working on my mac, but it was very flaky.

[laurimihkels]

Thank you both for your inputs.

May be the devs at McLear could try burn-ins with some plain chips and a bit help of us. So we could see if this is a problem that's common for the SLE78 or not.

@ckahlo Your assistance would be appreciated in setting it up. Also I can send you couple of extra rings if you are willing to try testing them again with your applets.

@darconeous I tested the AlgTest with ACR122U and it failed to load the AlgTest applet on the ring turning into a brick.

lauri@Lauri-DOM:~/Downloads$ java -jar gp.jar --install AlgTest_dist_1.7.9/AlgTest_v1.7.9_jc222.cap 
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
CAP loaded
Failed to communicate with card in JnaCardTerminal{scardHandle=SCardContext{27af3e5}, name=ACS ACR122U PICC Interface 00 00}: SCardTransmit got response 0x80100016 (SCARD_E_NOT_TRANSACTED: An attempt was made to end a non-existent transaction.)
lauri@Lauri-DOM:~/Downloads$ java -jar gp.jar --list
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
ISD: A000000151000000 (OP_READY)
     Privs:   SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement, TrustedPath, AuthorizedManagement, TokenVerification, GlobalDelete, GlobalLock, GlobalRegistry, FinalApplication, ReceiptGeneration

PKG: 4A43416C6754657374 (LOADED)
     Applet:  4A43416C675465737431

lauri@Lauri-DOM:~/Downloads$ java -jar gp.jar --delete 4A43416C6754657374
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
Exception in thread "main" java.lang.IllegalArgumentException
    at java.nio.Buffer.position(Buffer.java:244)
    at jnasmartcardio.Smartcardio$JnaCardChannel.transmitImpl(Smartcardio.java:806)
    at jnasmartcardio.Smartcardio$JnaCardChannel.transmit(Smartcardio.java:688)
    at pro.javacard.gp.GlobalPlatform.transmit(GlobalPlatform.java:520)
    at pro.javacard.gp.GlobalPlatform.deleteAID(GlobalPlatform.java:933)
    at pro.javacard.gp.GPTool.main(GPTool.java:368)
lauri@Lauri-DOM:~/Downloads$ java -jar gp.jar --list
Exception in thread "main" java.lang.IllegalArgumentException
    at java.nio.Buffer.position(Buffer.java:244)
    at jnasmartcardio.Smartcardio$JnaCardChannel.transmitImpl(Smartcardio.java:806)
    at jnasmartcardio.Smartcardio$JnaCardChannel.transmit(Smartcardio.java:688)
    at pro.javacard.gp.GlobalPlatform.discover(GlobalPlatform.java:126)
    at pro.javacard.gp.GPTool.main(GPTool.java:234)

Testing it with a new ring and ACR1252U it loaded successfully with no errors and I was able to run the AlgTest. Deleted and reloaded the applet again with ACR1252 without issues. Then took the ACR122U and it failed to load the applet on, again turning the ring into a brick. So the bricking must be ACR122u caused.

[darconeous]

@laurimihkels I tested the AlgTest with ACR122U and it failed to load the AlgTest applet on the ring turning into a brick.

Oh yikes! I figured it was just a fluke, scary to see it is repeatable. I'm glad I didn't try again! I guess it's time for a strong recommendation to NOT use the ACR122U for GP operations with these rings. Do you happen to know what revision of ACR122U you are using? Is is the A9?

BTW, would love to have the full algtest results.

[laurimihkels]

@laurimihkels I tested the AlgTest with ACR122U and it failed to load the AlgTest applet on the ring turning into a brick.

Oh yikes! I figured it was just a fluke, scary to see it is repeatable. I'm glad I didn't try again! I guess it's time for a strong recommendation to NOT use the ACR122U for GP operations with these rings. Do you happen to know what revision of ACR122U you are using? Is is the A9?

BTW, would love to have the full algtest results.

The readers I used are ARC122U-A9 and ACR1252U-M1. I'll update the guide and add a note about ACR122U.

Here are the AlgTest results: algtest_result.zip

[ckahlo]

Hi Robert,

The issue with the SLE78 is RandomData.getInstance(RandomData.ALG_SECURE_RANDOM).generateData(). I've got two dead µSD cards (ASSDs) with a SLE78 on-board besides 8GB of flash. Interesting. I wonder if their ALG_SECURE_RANDOM implementation is does any EEPROM/Flash writes. I don't have NDA access, so I can only speculate.

Those random number generators comply to AIS31, basically they are doing a statistic analysis to decide if they still operate in a range of allowed parameters (minimum entropy, aging).

Yeah, the SLE78 tandem is quite happy to die fast. It is its job to die before they lose any secret.

Indeed. These sorts of chips have two distinct goals: reliable operation and attack resistance, although I feel like some of the chips I've used recently are just simply unreliable, especially when field tearing occurs. And by that I don't just mean the OMNI, I've bricked an ACOSJ card, too. I always assumed it was because these cards were intended to be personalized once and that's it. I feel like there are many edge cases with repeated app install/uninstall cycles that seem to bring out the worst in many card-format SEs. But honestly, my sample size is too small to make any sweeping claims with certainty: you seem to have a lot more experience on this front.

ACOSJ is cheap and possibly a fire&forget implementation. Mine died without any install/uninstall, reading it repeatedly with a test app (selecting card manager, retrieving CPLC data) killed the card.

Install/uninstall is always heap modification, thus EEPROM/flash writes. This should be covered in transactions every time. But what if a transaction leaves non-sense in the NVM because power is flimsy. NXP seems to have a work-around for that using kind of a transaction log. But it takes time to recover, others and me as well have observed 15 minutes under idle power until the card is awake again. This didn't work with NFC, tried a few things to power the card in a field and select it. May be someone in a cellar in Hamburg knows what to do, will keep that in mind and ask someone.

Infact for the hackers, makers and security folks another chip might be better suited. I assume I had pretty bad luck with my ring. It doesn't need to be a sophisticated P7x, older modules are fine as well when they come in smaller packages with lower power requirements.

I mentioned the NXP P7x because I have a couple of cards and they have been very reliable and very fast. They also support JC 3.0.5, which is nice for those of us unwilling to sign NDAs. But a NXP P60 would also be fantastic from my point of view. Most of my experience with non-NXP chips has been relatively negative, at least from a JC development point of view.

The P60 speaks everything that's important as JC3.0.5 API extensions on JC3.0.4 platform. (hint: compile with 3.0.5 API with 3.0.4 or even 2.2.2 target, my default config here) Only a few barely used things really changed with JC3.0.5. We chose P60 because it allows custom libraries (i.e. ed/x25519), which the P70 doesn't allow anymore. Did you see the P70 in the wild already?

Regarding Type-B, that's the stubborn Google Authenticator. They are requesting Type-A instead of IsoDep.

iOS appears to be in the same boat.

Anyone from Google here who can hit the guy to change the requested tag type? ;-)

Heh, I can file a bug and see what happens. Although recently it seems that the webauthn stuff doesn't go through Google Authenticator anymore, it appears directly implemented in Chrome.

It's the Google Play services, I scratched it off a phone and ran the decompiler through. Its not even possible anymore to extend the authentication services by catching the intent. So fixes are not possible until the play services are fixed. I was arguing about that already half a year ago.

FWIW, I'm on a Mac. I'll pick up an ACR1252u, if it has fewer problems. I could never get JCAlgTest to run to completion on an ACR122U.

Robert try to get another reader. From the far distance just a suggestion: https://www.amazon.com/-/de/dp/B00TA3GQG0/

Yes, I have a few PN533-based dongles, including that one. I use them when I need something that works reliably with libnfc. However, you can't beat the convenience of a reader that offers a CCID interface, like the ACR122U does.

Err, the SCL3711 is not CCID? Phew, didn't know that. Otherwise try to get a GEMALTO PROX-SU from eBay or so. This one has CCID as well and mostly a spare but populated SAM-slot, too.

I received a new quite well working CCID "reader" today: https://www.cherry.de/cherry-secure-board-1-0.html

I have not yet found a reliable way to get a SCL3711 to appear as a smart card reader on a mac (which is my primary machine). At one point I did get ifdnfc kinda working on my mac, but it was very flaky.

Unfortunately I can't help you here. I've got only black hardware on my desk.

Best regards, Christian

[ckahlo]

Hi Lauri,

Thank you both for your inputs.

May be the devs at McLear could try burn-ins with some plain chips and a bit help of us. So we could see if this is a problem that's common for the SLE78 or not.

@ckahlo Your assistance would be appreciated in setting it up. Also I can send you couple of extra rings if you are willing to try testing them again with your applets.

Thank you very much. I am pleased to do some more tests. Meanwhile you could try Roberts applet, its pretty much the same as the Ledger applet in its core.

send a SELECT and a U2F register command: 00010000404ACA9D66F303E50C86F47541417E5D675BE97450F69519162031313F4A3F2EBB649F611DE48448F327881B5250B5B6E346BE273ADCEEE4D235673554A88916CC00

The data is just the 32-byte hash of a challenge, could be random and the 32-byte hash of an application ID. The latter should be constant for a certain application as with "sign-in" the same key needs to be generated for a valid signature.

You could send consecutive register commands, it should repond with a newly generated key, a key handle, an attestation signature and an attestation certificate.

I got timeouts after a few attempts.

@darconeous I tested the AlgTest with ACR122U and it failed to load the AlgTest applet on the ring turning into a brick.

Well, yikes. So there are readers that actively brick the chip. Fortunately I don't have this one. But this leaves me with a bad feeling about my PROX-SU :-/

Thanks for testing and sharing the results as well as your support!

Stay sound and best regards, Christian

[laurimihkels]

Hi Christian,

I tested @darconeous applet (with his install script). Loaded the applet using Omnikey OM5422 reader.

I managed to send that static register command and get response over 50 times. Roughly half of those tries was with Omnikey reader and rest with ACR122U. With ACR122u it failed once without any response but I think that was me removing the ring too soon from the reader. The ring still kept working afterwards.

If you can think of anything else to try, let me know 👍

[ckahlo]

Hi Lauri,

just bought a HID Omnikey 5422, should be here on Thursday. I don't have the ACR122u. Did you also try a couple of install / uninstalls? The ring finally failed after uninstalling the applet. As a developer I need to install updated versions on a regular basis to verify succesful operation on a chip. (there are indeed some specific differences between JCREs)

Did you try to install a couple of more applets? Like @vletoux GIDS applet, https://github.com/Yubico/ykneo-openpgp/ and https://github.com/Yubico/ykneo-oath. Or @OpenJavaCard openjavacard-ndef? (BTW: the openjavacard-tools package might be an idea in general)

It's not so easy to find out what gave it the kick, but the rest will probably have been consequential error.

Thanks and best regards, Christian

[darconeous]

Did you try to install a couple of more applets? Like @vletoux GIDS applet, https://github.com/Yubico/ykneo-openpgp/ and https://github.com/Yubico/ykneo-oath.

For what it's worth, ykneo-oath is broken on the OMNI. The codes are all wrong, and every entry will have the same code (although it does change).

Also, I wasn't able to simultaneously install ykneo-oath and my ledger-u2f fork. I assume it is some resource restriction, maybe on TRANSIENT_RESET or TRANSIENT_DESELECT memory.

[darconeous]

I managed to send that static register command and get response over 50 times. Roughly half of those tries was with Omnikey reader and rest with ACR122U. With ACR122u it failed once without any response but I think that was me removing the ring too soon from the reader. The ring still kept working afterwards.

FYI: If you personalize the instance with flags set to 01 instead of 00, you will be able to test in rapid succession without needing to remove and replace the ring.

[ckahlo]

BTW: Indeed I've just one SLJ52GCA150 that hasn't NFC - the rest is at @OpenJavaCard / @promovicz and @c-base / zet. The others are Oberthur DragonFly V3.2 (ST33F1M) and V4 (SLE97), NXP J3H145 (P60), G&D Sm@rtSIM (BCM SPS), THALES eSE and a few more. I had never problems with any applet on them.

[ckahlo]

Did you try to install a couple of more applets? Like @vletoux GIDS applet, https://github.com/Yubico/ykneo-openpgp/ and https://github.com/Yubico/ykneo-oath.

For what it's worth, ykneo-oath is broken on the OMNI. The codes are all wrong, and every entry will have the same code (although it does change).

Also, I wasn't able to simultaneously install ykneo-oath and my ledger-u2f fork. I assume it is some resource restriction, maybe on TRANSIENT_RESET or TRANSIENT_DESELECT memory.

Wow, I didn't test that any further. It is in my default install testscript. The buffers they require are quite huge (>2k). TRANSIENT_RESET memory can be a serious problem. TRANSIENT_DESELECT isn't as long as you're not operating on logical channels as I do on UICCs and eSEs. Indeed ykneo-oath and your applet were installed at the same time I suppose. That's an argument to leave that applet alone. Unfortunately for every-day-carry tokens some people keep asking for that.

But all this stuff never runs on a UICC or eSE. The applications wouldn't have access to the chips anyway.

[laurimihkels]

Did you also try a couple of install / uninstalls? The ring finally failed after uninstalling the applet. As a developer I need to install updated versions on a regular basis to verify succesful operation on a chip. (there are indeed some specific differences between JCREs)

@ckahlo I tried to install the applet over 20 times, no issues there.

I managed to send that static register command and get response over 50 times. Roughly half of those tries was with Omnikey reader and rest with ACR122U. With ACR122u it failed once without any response but I think that was me removing the ring too soon from the reader. The ring still kept working afterwards.

FYI: If you personalize the instance with flags set to 01 instead of 00, you will be able to test in rapid succession without needing to remove and replace the ring.

Thanks! Now I was able to test the register command APDU over 1000 times without any issues.

Did you try to install a couple of more applets? Like @vletoux GIDS applet, https://github.com/Yubico/ykneo-openpgp/ and https://github.com/Yubico/ykneo-oath. Or @OpenJavaCard openjavacard-ndef?

Last year I tried:

• tiny and full variants of openjavacard-ndef - worked just fine.
• ykneo-openpgp - seemed to work but didn't test extensively.

I also tried the GIDS applet - got it installed and initialized but I can't test any further at this point.

[ckahlo]

Hi @laurimihkels,

[...]

@ckahlo I tried to install the applet over 20 times, no issues there.

OK, sounds good. The HID 5422 arrived today, first tests seem to be positve.

FYI: If you personalize the instance with flags set to 01 instead of 00, you will be able to test in rapid succession without needing to remove and replace the ring. Thanks! Now I was able to test the register command APDU over 1000 times without any issues.

OK, well. Then it is something else or it is a rare crash of the chip I got. This ring is on its way back to you since yesterday.

Did you try to install a couple of more applets? Like @vletoux GIDS applet, https://github.com/Yubico/ykneo-openpgp/ and https://github.com/Yubico/ykneo-oath. Or @OpenJavaCard openjavacard-ndef?

Last year I tried:

• tiny and full variants of openjavacard-ndef - worked just fine.

OK.

• ykneo-openpgp - seemed to work but didn't test extensively. I also tried the GIDS applet - got it installed and initialized but I can't test any further at this point.

I could do this here with Windows workstation logon.

Thanks a lot for your feedback and best regards, Christian

[ckahlo]

@laurimihkels: a couple of rings arrived today, but they are all the wrong type: NTAG216. No JavaCard-based OMNI rings. So I can't do any tests with them,

[laurimihkels]

@laurimihkels: a couple of rings arrived today, but they are all the wrong type: NTAG216. No JavaCard-based OMNI rings. So I can't do any tests with them,

Oh no! I am terribly sorry about this! I'll talk with UK staff to send out correct products asap.

[ckahlo]

Hi @laurimihkels,

very good news: the rings arrived a few minutes ago! :-) I've to do some official "JavaCard on embedded secure elements" work today and tomorrow. But we've a long weekend this week and I hope I can do some further in-depth tests. :-)

Thanks a lot for your great support.

Best regards, Christian

[laurimihkels]

Hi Christian,

I'm glad to hear that. Keep us updated with your findings 👍

[ckahlo]

Hi @laurimihkels,

so, finally I got some time to do tests and write about it. :-)

A) the size: this is just FYI and to whom it might concern: I measured a size 9.5 and you sent me an additional size 9 and 10 ring as well. This is great to compare because size 9 is a "perfect fit" as a ring if I don't have to remove it that often. Size 9.5 fits as expected and is a bit easier to remove from the finger if the reader doesn't accept it. While size 10 is definitely a bit too lose for every day carry. May be this info helps others to choose the right size for the intended usage.

B) environment: I've got some stronger RF fields here ... homebrew "high-power" 13,56MHz circuit, ham radio, LoRa transceivers, etc. I was wearing one of the rings all the time and it didn't die. This is good to know because I already feared my environment might be technically hostile (some EMIs).

C) initialization: the OMNIKEY5422 is definitely a good decision, the ring is instantly accepted and seems to be powered well. I had no install / delete errors with this reader so far. However on the first run of the eID applet the certificate chain is updated and thus every single certificate is verified by the current (last updated) root and stored in EEPROM. After a full initial run I get "6985" when I try to select the applet again without removing the ring from the reader. The error code is not thrown by the applet code. But this happens only in this special "once in a lifetime" scenario. Applet versions for production include the current root CVC (lifetime 3 years).

D) runtime: FIDO is working quite well and with https://play.google.com/store/apps/details?id=de.cotech.hw.fido.example you can test it even if Google doesn't support ISO14443-B. And with https://play.google.com/store/apps/details?id=de.cotech.hw.fido.browser&hl=de from @cotechde you can verify the operation of the ring with test apps on the web. Also my local testcases do work now without sudden deaths or interruptions.

E) eID tests: while EEPROM access seems to be fast, cryptographic operations are not. While everything works quite well with the OMNIKEY and just takes a bit of time I am running into trouble with other readers (i.e. CHERRY SECURE BOARD). I got timeouts and communication interruptions on cryptographic operations and I will investigate this further to get a more detailled idea about the issue. (man in the middle protocol analyzer and power measurement) I'll also transfer one of those testcases into an Android application to test with the current Sony (Z1&Z2 compact), SAMSUNG (S9, S10, S20) and Pixel 4 phones I've got on my table.

I've got a rough idea about what this might be. The SLJ 52 is a two-core tandem CPU design, they compare every computational result and lock themselves up if they detect certain errors. This tandem design might be particularly secure but it consumes twice the power and a bit of more time this power has to be applied than a classic single secure core design. This leads me to a preliminary conclusion that the chosen CPU design was a good idea regarding security but won't really fit to the power situation of an antenna inside a finger ring. Please don't get me wrong, this is no critics and the modified antenna design is doing a very great job. But a chip with a faster, less power but similar secure core might be better for every-day scenarios. Did you already try other chips? I am not sure if the tandem operation mode could be switched of during OS personalization.

More to come and thanks a lot for your support and this inspiring device. Some frieds should have ordered a couple of rings now as well. ;-)

Best regards, Christian

[JohnMcLear]

@ckahlo please provide a link to donate to a charity you support. Thanks for everything you are doing / have done here. I'm officially not involved (I'm just a shareholder now) but I'm following these ongoing developments with a personal interest :)

[laurimihkels]

Hi @ckahlo,

Thank you for the great feedback.

Did you already try other chips?

On daily basis we deal with variety of chips to accommodate the requirements of our B2B clients. At the time when @JohnMcLear decided to make these rings for the community, as an alternative form factor to the conventional white ID1 cards, the SLE78's were the most convenient for us to use for such project. Will this remain as one off project or not is yet to be seen. If we ever end up doing another project like this we will create feature request issue :).

[ckahlo]

Hi @JohnMcLear, Hi @laurimihkels,

well, regarding the eID tests from point E I've got some really positive feedback for you. While I still should investigate things with desktop readers I gave it a try with Sony XPeria M (Android 4.2.2 - extended length capable firmware), Z3 compact, XZ1 compact, XZ2 compact, Samsung S7, S9, S10, S20 and Google Pixel 4. The result is: it is NOT a power issue. :-) The antenna design is obviously a real game changer! It is just a timing issue. While the Samsungs seem to use more tolerant timing settings by default and work out-of-the-box I simply changed a few parts in my code (this happens at different places of course, but these are the essential lines):

this.iso = IsoDep.get(tag);
this.iso.connect();
this.iso.setTimeout(2500); // accept up to 2,5s before timeout

So the new time-out is set to 2,5 seconds which is far enough and still a reasonable value to detect a lost tag. Now the Sony and Google phones work like a charm as well. Even with ISO 7816-4 AES secure messaging, long secure random number generation, ECC signature verification, ECDH key agreements, etc.

The interesting question now is if it is possible to influence power and time-out settings on USB desktop readers with vendor specific commands (FF 9A P1 P2 ...) over CCID. Never had a deeper look into that before but I expect that such functions exist. I am sure I read this once in a couple of datasheets.

@JohnMcLear: I really appreciate your idea to help a charity. If you want to do so and you're asking me what I would prefer let me explain my idea: I believe in the chances of the future, in one Europe and in helping the small ones in our society. That's why https://www.eurochild.org/ comes to my mind at first (i.e. "Children in Scotland" and "Children in Wales" are included as well). Does that fit your idea, too?

Thank you very much and have a nice weekend!

Cheers, Christian

[ckahlo]

Ah, I forgot to mention an important point: all tests done with ring on finger. I.e. holding the phone in the hand.

[andrea6407]

Thank you both for your inputs.

May be the devs at McLear could try burn-ins with some plain chips and a bit help of us. So we could see if this is a problem that's common for the SLE78 or not.

@ckahlo Your assistance would be appreciated in setting it up. Also I can send you couple of extra rings if you are willing to try testing them again with your applets.

@darconeous I tested the AlgTest with ACR122U and it failed to load the AlgTest applet on the ring turning into a brick.

lauri@Lauri-DOM:~/Downloads$ java -jar gp.jar --install AlgTest_dist_1.7.9/AlgTest_v1.7.9_jc222.cap 
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
CAP loaded
Failed to communicate with card in JnaCardTerminal{scardHandle=SCardContext{27af3e5}, name=ACS ACR122U PICC Interface 00 00}: SCardTransmit got response 0x80100016 (SCARD_E_NOT_TRANSACTED: An attempt was made to end a non-existent transaction.)
lauri@Lauri-DOM:~/Downloads$ java -jar gp.jar --list
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
ISD: A000000151000000 (OP_READY)
     Privs:   SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement, TrustedPath, AuthorizedManagement, TokenVerification, GlobalDelete, GlobalLock, GlobalRegistry, FinalApplication, ReceiptGeneration

PKG: 4A43416C6754657374 (LOADED)
     Applet:  4A43416C675465737431

lauri@Lauri-DOM:~/Downloads$ java -jar gp.jar --delete 4A43416C6754657374
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
Exception in thread "main" java.lang.IllegalArgumentException
  at java.nio.Buffer.position(Buffer.java:244)
  at jnasmartcardio.Smartcardio$JnaCardChannel.transmitImpl(Smartcardio.java:806)
  at jnasmartcardio.Smartcardio$JnaCardChannel.transmit(Smartcardio.java:688)
  at pro.javacard.gp.GlobalPlatform.transmit(GlobalPlatform.java:520)
  at pro.javacard.gp.GlobalPlatform.deleteAID(GlobalPlatform.java:933)
  at pro.javacard.gp.GPTool.main(GPTool.java:368)
lauri@Lauri-DOM:~/Downloads$ java -jar gp.jar --list
Exception in thread "main" java.lang.IllegalArgumentException
  at java.nio.Buffer.position(Buffer.java:244)
  at jnasmartcardio.Smartcardio$JnaCardChannel.transmitImpl(Smartcardio.java:806)
  at jnasmartcardio.Smartcardio$JnaCardChannel.transmit(Smartcardio.java:688)
  at pro.javacard.gp.GlobalPlatform.discover(GlobalPlatform.java:126)
  at pro.javacard.gp.GPTool.main(GPTool.java:234)

Testing it with a new ring and ACR1252U it loaded successfully with no errors and I was able to run the AlgTest. Deleted and reloaded the applet again with ACR1252 without issues. Then took the ACR122U and it failed to load the applet on, again turning the ring into a brick. So the bricking must be ACR122u caused.

Does the ACR122U being used happen to have the ACS logo? If it doesn't, it is a counterfeit version. Would be interesting to do further testing to see if all ACR122Us cause this issue, or if its only the counterfeit ones that do this