JavaCard 3 in real world?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP



JavaCard 3 in real world?



I'm currently working on my diploma work. Part of the work includes development of JavaCard applet for regular SIM cards. First option is to use JavaCard2.X API and use APDU commands to communicate with the applet. This might be very tricky as I need to develop client-app for android (which will be communicate with this applet) and that is so far possible only trough special - not so user friendly - API called Seek-for-android. (if I'm wrong, please correct me)



However, I also came across JavaCard3 Connected Edition, which provides much more options - for example web applets. Using webapps, deployed on SIM card and accessing them through browser in mobile device would be very convenient (of course developing such applet would be much easier as well). Problem is, that I can't find any mentions of Javacard3 being used in real life, or even on real SIM cards. I can't even find any mentions of possible date of release of such cards. Actually, there is almost no information on this topic.



So, my question is - do you know anything useful about this platform? Anything about real-life usage? Which card supports Javacard3? Are there any developers smart-cards, which are "JC3 enabled"? Will there be SIM cards with this platform in the future?



Thanks a lot for answers!!!





I do know that JavaCard 3 uptake is very modest, and that implementations are pretty sparse since they do require a lot of resources (RAM, EEPROM and CPU, probably in that order) of the chip. Personally I'm not in their market as all the projects I perform have an API on the APDU level.
– Maarten Bodewes
Mar 4 '12 at 17:14






So I am about to take painful journey with Seek for Android + JavaCard2.x. Thanks for info!!
– AGO
Mar 7 '12 at 14:13





Small update: the specs require something like > 24KB RAM (currently most high end chips are at about 8KB for contactless to 16KB for contact), and a 32 bit CPU (e.g. ARM core).
– Maarten Bodewes
Mar 20 '12 at 0:57





@MaartenBodewes Any update two years later?
– vojta
Feb 24 '15 at 12:56





@vojta The CPU's that I am using still have about half of the amount of RAM available or less. I don't see much movement for now. And most of the protocols I see are still APDU oriented. If there is any change it will probably happen in the mobile sector (SIM).
– Maarten Bodewes
Feb 24 '15 at 13:13





3 Answers
3



At JavaOne 2012 Moscow representatives of the JavaCard Oracle team demonstrated a prototype device with support for Java 3 Connected Edition based on Portable Security Token ES.





I also spoke with representatives from Oracle, in my opinion, these tokens are ideal for building secure java applications. For example C3 Licensing System uses a JavaCard for storage and verification of licenses.
– MikhailDudarev
May 16 '12 at 10:22





Thats valuable info, thanks. However, it seems to me, that JC3 won't be used in mobile phones SIM cards in next few years.
– AGO
Jul 7 '12 at 13:40





Although uptake will be relatively low initialy, the SIM market is what Java Card 3 connected is all about. The question is if the market will move to these high end chips. It remains to be seen if the required hardware will be cheap enough, but Moore's "law" will take care of that eventually.
– Maarten Bodewes
Jul 23 '12 at 18:13



There is no card in the field with JavaCard 3 right now. Everything under development.
But I recommend you to have a look to JSR 177. If Android supports it you can communicate with your applet by normal APDU commands.



It's 2018 when I am writing this and I think this question needs a new answer.



Java Card 3 Connected Edition is dead in the water. It requires a large amount of RAM, which is still expensive even in the latest editions of the chips. SRAM takes large amounts of memory, and high end chips often still contain 8-10KiB of RAM max.



Furthermore, it was generated with the idea that web-developers would easily connect with it. This doesn't seem to have happened and it is questionable if a security device should be programmed by web-devs at all.



The additional overhead of the TLS protocol adds a heavy overhead without apparent benefit. The TLS protocol also requires a weird connection with the browser / end user. The idea that you can enter a PIN or password on a chip generated web page certainly has failed.



The idea of adding hardware support for browsers in general has failed. Before there were Java applets running in the browser, and the browser largely depended on add-ons. This has all gone away and it is very unlikely to return.



So even if RAM (or FRAM, MRAM, XCross or whatever hybrid memory solution will exist) ever comes cheap on a secure smart card processor, it is unlikely that JC 3 Connected will again see the light of day. Meanwhile Java Card Classic is still going strong although it is far from sexy at the moment.






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

Firebase Auth - with Email and Password - Check user already registered

Dynamically update html content plain JS

How to determine optimal route across keyboard