It is time for my yearly local conference, and this time, I am blogging live from it. I missed the first day, but here I am for the second day, and the Java Card session.
This year, it is Oberthur who presents Java Card 3.0, more precisely Vincent Guerin, one of their JCF representatives. His presentation of the basic features is nice, because it is not only talking about positive things. This is the appropriate time to do this, because the specification is getting closer to publication, and most bottlenecks have been handled.
- Yes, class files involve a size overhead, but compression is also used in JAR files, and the amount of symbolic information that needs to be kept for linking is not very large.
- Yes, bytecode verification is complex, but the overhead is only at load time. This simply means that we should not expect “instant loading” of applications.
- Yes, garbage collection is a key point, but implementers have taken a good look at it.
- Yes, multithreading is new, and it is scary. But we are here talking only about green threads, which are managed directly by the VM.
- Yes, TCP/IP and related protocols need large buffers, but we are looking at optimizing their implementation and selecting the appropriate protocols.
We here get to the point. Java Card 3 is about making the life of developers easier, and it is about getting ready for the future of cards. However, Vincent mentioned that there are plenty of implementation challenges for the developer; he also mentioned a 32KB RAM, 64KB EEPROM, 400KB ROM that is interesting, but a bit surprising because of its small amount of EEPROM. I wonder which business model we can implement with so little EEPROM.
The application proposed by OCS is a Web service, which is a nice departure from Gemalto’s Ajax stuff. Their servlet parses SOAP messages to perform user authentication.
Vincent’s conclusion is more slippery, calling for third-party developers. I definitely hope that this will happen, but the Java Card 2 experience has shown that smart card programming is not that easy for other developers. Are we close enough? Do we provide the appropriate level of API? These are tough questions, to which we don’t yet have answers.
I will come back to the first day, after looking at the slides and talking to the people, because there have been quite a few interesting talks, in particular about smart card web servers and about mobile security and mobile payment.
I attended the presentation from Gemalto about smart card web server. It was quite interesting to see a presentation of web content on the SIM. The demonstration included a OTP generation with the corresponding bar code which can be read via a web camera from mobile phone’s display. Gemalto also presented a commercial development tool (Eclipse plugin, similar to JCOP Tools) which can be used for “normal” Java Card programming as well.
I was surprised to hear that Gemalto cannot wait for the new Java Card 3 Connected Edition, but pushed their concept through the Open Mobile Alliance. Not sure if it is the right to bypass the owner of the technology.
Regarding the hardware requirements for such a SCWS we heard RAM numbers starting from 1.5kB to 20kB, I guess aiming for the lower cost SIM cards.
Overall the demonstration was good.
Eric, could you please elaborate more on the HW requirements (especially the most expensive part: RAM) for a JC 3.0 connected edition? I hear so many different numbers and would like to know a minimum.
Also I would like to understand the TCP/IP optimization you mentioned. Is it planned to make again a smart card specific protocol? (I hope not.)
Vincent mentioned 32K, and I believe that he is about right. We could do it with less memory, but then, applications need memory as well. So, 1.5k is way too small.
Actually, the problem is the same for EEPROM, which is why I found Vincent’s 64k too small. It is enough for the system, but not for the applications.
I agree with you Eric, my figures are not very accurate. 16K of RAM are enought whereas 256K of NVM seems more reasonnable. We can notice that this ratio of sizes better fits to the chips from the market.