Open yieldone opened 5 years ago
OK, so here's some JCAlgTest results for a card I bought, which might be useful to others: NXP JCOP3 J3H081 JC 3.0.4 MoTechno: https://www.motechno.com/buy/j3h081-jcop3/
Algorithm | Supported? | Comment |
---|---|---|
Cipher.ALG_AES_BLOCK_128_CBC_NOPAD | :white_check_mark: | |
Cipher.ALG_AES_CBC_ISO9797_M2 | :white_check_mark: | |
KeyAgreement.ALG_EC_SVDP_DH_PLAIN | :white_check_mark: | |
KeyAgreement.ALG_EC_SVDP_DH_PLAIN_XY | :white_check_mark: | |
KeyPair.ALG_EC_FP | ??? | Sales docs says supported |
MessageDigest.ALG_SHA_256 | :white_check_mark: | |
MessageDigest.ALG_SHA_512 | :white_check_mark: | |
RandomData.ALG_SECURE_RANDOM | :white_check_mark: | |
Signature.ALG_AES_MAC_128_NOPAD | :white_check_mark: | |
Signature.ALG_ECDSA_SHA_256 | :x: | |
Signature.ALG_HMAC_SHA_512 | :x: |
To be honest, it's a bit difficult to know even with the AlgTest, whether things will work out. I have successfully installed the pkg onto this card, as follows:
gp.exe -load wallet.cap
I'll keep you all posted on further progress.
Cheers,
Rowland
We currently use NXP JCOP3 J3H082 and there it works fine. I am surprised to see Signature.ALG_ECDSA_SHA_256 declared as not supported in J3H081 because that would be a deal breaker. Loading always succeed if the JC version matches, if the install step also succeed then it means it is compatible.
Hi @bitgamma,
Ah, nice, do you happen to have any details on suppliers of the NXP JCOP3 J3H082? I'll keep hammering with the NXP J3H081 see if I find any major issues.
Cheers,
Rowland
cc @guylouis
I didn't find the J3H082 anywhere online, but I did find the J3H145:
https://www.javacardos.com/store/products/10029
I'll try this one out too.
Hi yieldone, Indeed J3H082 is a real recent reference and it's still quite hard to get. I doubt it's available anywhere online. But they will soon for sure! Contact me at guylouis@status.im so that we understand your project and see how we can help you!
This card does not support ECC, nor key generation (including RSA, which is otherwise supported, if you do key import)
We had discussions with NXP about this in the past, and they confirmed JH082 is not just an iteration of JH081. JH081 does not support ECDSA, and is not (contrarily to JH082) designed from the ground up for strong authentification: for instance it does not have formal common criteria certification.
NXP JCOP3 J3H145 JC 3.0.4
So, I got hold of a J3H145 - bingo, it claims to have everything except ALG_HMAC_SHA_512. But AlgTestClient then bricked it for some reason, thankfully I've got two.... After waiting a few mins, the card is alive again!
Algorithm | Supported? | Comment |
---|---|---|
Cipher.ALG_AES_BLOCK_128_CBC_NOPAD | :white_check_mark: | |
Cipher.ALG_AES_CBC_ISO9797_M2 | :white_check_mark: | |
KeyAgreement.ALG_EC_SVDP_DH_PLAIN | :white_check_mark: | |
KeyAgreement.ALG_EC_SVDP_DH_PLAIN_XY | :white_check_mark: | |
KeyPair.ALG_EC_FP | :white_check_mark: | 160 - 521 |
MessageDigest.ALG_SHA_256 | :white_check_mark: | |
MessageDigest.ALG_SHA_512 | :white_check_mark: | |
RandomData.ALG_SECURE_RANDOM | :white_check_mark: | |
Signature.ALG_AES_MAC_128_NOPAD | :white_check_mark: | |
Signature.ALG_ECDSA_SHA_256 | :white_check_mark: | |
Signature.ALG_HMAC_SHA_512 | :x: |
Here's where I got it: https://www.javacardos.com/store/products/10029
NXP JCOP3 J3H145 JC 3.0.4
So, I got hold of a J3H145 - bingo, it claims to have everything except ALG_HMAC_SHA_512. But AlgTestClient then bricked it for some reason, thankfully I've got two.... After waiting a few mins, the card is alive again! Signature.ALG_HMAC_SHA_512 ❌
Here's where I got it: https://www.javacardos.com/store/products/10029
Is ALG_HMAC_SHA_512 needed for this project? Is JCAlgTests result correct?
ALG_HMAC_SHA_512 is not required, there is a software fallback implementation in case it is not supported
What about this card? Java Card JC30M48CR As available here: https://www.javacardos.com/store/products/10000
6.99$ sounds much more appealing than 34$
usually the problem is finding a card supporting KeyAgreement.ALG_EC_SVDP_DH_PLAIN_XY. This algorithm has been introduced in JavaCard 3.0.5, but some 3.0.4 cards also support it. To find out if it works, you need to contact the manufacturer (or try it out)
Has anyone managed to install this applet in any javacard? If yes, which models are compatible?
A summary for requirements for the smartcard is here: https://github.com/status-im/status-keycard
Please make sure to check our new doc site too https://status.im/keycard_api/
For our Keycard we use J3H082 from NXP (J3H145 is suitable too). Since they might not be easy to buy for now, if you need a sample please send me an email with your adress, I'll send one guylouis@status.im
What issue do you have loading the applet. Please check also our android installer, adress here : https://status.im/keycard_api/resources.html
Can anyone confirm that the J3H081 is 100% functional with this project?
@cryptoida is not. https://www.javacardos.com/store/products/10029 should be.
@cryptoida I can confirm that J3H081 is not suitable for this project, because J3H081 does not support elliptic curve crypto.
You need either J3H082 or J3H145
I supose that the J3D081 is not compatible either?
J3D081 is JavaCard 3.0.1
For those who want to be hands on some cards, we can send some J3H082 samples to you. Contact me at guylouis@status.im
Why a dual card is required is required if only the contactless (NFC) is used in this project?
Dual card is not required. Let me know if it's stated so somewhere, because it would be a mistake. You can use Keycard applet and API with a card which would contactless only, or contact only.
Thank you for your reply. In this case what type/model of contactless (NFC) card is required ?
What I mean is that Keycard framework (applet, api) works whatever the physical link of the smartcard is (contacts, nfc). In Status we have chosen a dual interface from NXP, which is J3H082 and J3H145. Do you mean you are looking for contactless only card, and you're lokking for the right reference by NXP?
Yes, which will be the requirements for a contactless only card ? (The manufacturer has no importance)
There shouldn't be surprises on this as long as the smartcard you chose supports contactless/nfc interface.
The contactless standard is ISO/IEC 14443
Well, I do not think that all contactless / nfc cards, is adapted and has a integrated secure element for sensitive and highly secure applications as credit card, payment transactions, EMV...etc
You need a JavaCard with contactless interface and the required algorithms (found in README).
Exactly, see: https://github.com/status-im/status-keycard
GitHub
Our Javacard Implementation for making secure transactions within Status and Ethereum - status-im/status-keycard
I just tested with JavaCard A22CR and get the following error when trying to run the tests:
im.status.keycard.io.APDUException: Unexpected error SW, 0x6A00
at im.status.keycard.io.APDUResponse.checkSW(APDUResponse.java:87)
at im.status.keycard.io.APDUResponse.checkOK(APDUResponse.java:64)
at im.status.keycard.KeycardTest.initIfNeeded(KeycardTest.java:176)
at im.status.keycard.KeycardTest.initAll(KeycardTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:436)
at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115)
at org.junit.jupiter.engine.descriptor.ClassTestDescriptor.lambda$invokeBeforeAllMethods$6(ClassTestDescriptor.java:239)
at org.junit.jupiter.engine.execution.ThrowableCollector.execute(ThrowableCollector.java:40)
at org.junit.jupiter.engine.descriptor.ClassTestDescriptor.invokeBeforeAllMethods(ClassTestDescriptor.java:238)
at org.junit.jupiter.engine.descriptor.ClassTestDescriptor.before(ClassTestDescriptor.java:164)
at org.junit.jupiter.engine.descriptor.ClassTestDescriptor.before(ClassTestDescriptor.java:65)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:110)
at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$2(HierarchicalTestExecutor.java:120)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.lambda$executeRecursively$3(HierarchicalTestExecutor.java:120)
at org.junit.platform.engine.support.hierarchical.SingleTestExecutor.executeSafely(SingleTestExecutor.java:66)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.executeRecursively(HierarchicalTestExecutor.java:108)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor$NodeExecutor.execute(HierarchicalTestExecutor.java:79)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:55)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:43)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:170)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:154)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:90)
at com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:74)
at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
any chance that I get it working with this card? https://www.microcosm.com/products/smart-cards#cards
unfortunately the product page does not list all supported algorithms in detail. Keycard requires the following crypto algorithms supported
In particular, KeyAgreement.ALG_EC_SVDP_DH_PLAIN_XY is only defined in JavaCard 3.0.5 but NXP supports it also in 3.0.4 cards. I don't know if Infineon does
Fidesmo is selling their locked down version of J3H145 https://shop.fidesmo.com/products/fidesmo-card-2-0
Perhaps putting this applet on the fidesmo store would make it easier to install for a lot of folks
@prajaybasu this is a great idea !! Thanks so much for pointing out they use J3H145. I will try to get in touch with Fidesmo team about this 😀
I found a card J3R180 with JavaCard 3.0.5
Hi folks,
I've been looking through JCAlgTest for a suitable card, but I've yet to find anything suitable (Infineon SLE78 Universal JCard appears the closest but doesn't support JC 3.0.4). Do you guys have any recommendations?
Cheers,
Rowland