Javacard Optimizations missing

[frankmorgner]

I find your code a very good starting point. However, your code looks like it's written for Java, not JavaCard. There are some scientific articles about JavaCard optimizations. But I found reading this guide highly interesting: http://www.ruimtools.com/doc.php?doc=jc_best. Maybe you want to have a look into it, too.

[martinpaljak]

The article you referenced is useful read, but not entirely true or relevant either. These days cards are quite well performing and I would not "optimize" unless there are realistic concerns on usability because of speed. Readability is a must and security a bigger priority than bitfidling speed optimizations. Notice that the information there references things from the 10+ year past and talks about a single card experience ("the operating system" is not really relevant, there are several vendors with different features)

Can you point out some exact changes that are necessary ? I find the implementation of file systems always intriguing (a concept that IMHO should be a thing of the past, but well..)

Also, some of the stuff that you find from academic papers is not relevant either on latest and greatest cards, so while it won't hurt (or provide some protection when moving from one card to another) it might not be useful either. YMMV.

[frankmorgner]

You should always verify other peoples opinions, especially when found on the internet. I was first referring to missing use of transient arrays. This, however, turns out to be a misuse of grep on my part, sorry. Anyway, I still find the article worth reading.

[philipWendland]

Hello Frank, thanks for the feedback and the hint to that article, but it is not unfamiliar to me. Still, I decided to not follow it strictly. The IsoApplet is ment to be for "mordern" java cards, with the muscle applet being the applet that should be chosen for older, slower cards.

If you are refering to the OO-design of the filesystem, the reason to implement this in OO (with filetypes as classes and files as objects) were

• Code readability and maintainability
• The approach of the muscle applet was to allocate a massive byte array that contains all the data, with the disadvantages of unused space or not enough space (with the limitation of the range of the short datatype, the array can only be about 16KB big)
• the fitness (i.e. the integrity) of the file structures is easier to garantee/achieve - with byte-orientated filesystems one wrong byte could break the complete file tree structure.

(class hierarchy of the file system)

After most of the implementation was done, I did a performance evaluation and was quite happy with it (I knew I was taking a risk with the design of the filesystem). Signing with RSA is done in ~1.1s to ~1.8s, depending on the smartcard that was used for the test. "Signing" in this context includes pin verification, reading in the complete PKCS#15 file structure by OpenSC etc. Still, I am assuming the sign()-operation takes most of the time, but that has to be proven.

I don't want to sacrifice readability by massively "re-using local variables" etc.

Nevertheless, I will have another look at the code myself the next days. There is definitely room for improvements. Maybe the DFS search of files should be the place to look at first when trying to optimize performance. This is executed often and I kind of dislike the way it is currently implemented..