1. New Security Issues Raised by Open Cards Pierre GirardJean-Louis Lanet GERMPLUS R&D

2. I think it would be better if the title is: New Security issues Raised by Java Cards Just simply think they are the same thing. (They are actually the same thing anyway.)

3. Outline : Some background. –Smart cards. –Java Cards. Two special concerns about Java Card security. –Applet download framework. –Object sharing mechanism. An interesting point. (an easy point, from where you can start your attack.) Question. Conclusion.

4. Some Background: Smart Card: –A piece of plastic of the same size as a normal credit card. –Embedded with a processor and an array of memory. (not in all cards) –The most sophisticated ones contain 32-bit instruction sets, with several Mbytes of memory. (Amazing, isnt it?) Commands Results

5. Java Card: –Smart cards capable of running Java byte codes. –Java Card Architecture: Chip-dependent Chip-independent Java Card framework & JCRE

6. Java Card (continued) –Three important features: 1.Services (Applets) can run on multiple platforms. (Write once, run anywhere.) 2.Support post-issuance applet download.(like install a new software package on your PC). This can be done easily. (You can do it) 3.Multiple services (applets) can exist in one card.(like multiple software packages existing in the hard disk of your PC) Enough of background, hopefully.

7. Two special concerns about Java Card security The first concern aims to the post-issuance applet download feature. –Unlike chip-dependent applications developing. Java tech is widely spread and relatively easy to get expertise, also, the process of applet download is technically easy. So, we can expect that the popularity of the hacker community of Java Card is likely to be huge. Then, what if someone tamper a service providers codes or write a piece of malicious code and download it into a card? (Every one in the class can do that :=).

8. The first concern aims to the post-issuance applet download feature (continued). Not that easy unfortunately:=( –Solution by Open Card Download Framework: All service providers (applet code developers) must submit their codes to a publicly trustworthy third party (the checker) before their codes are downloaded to the customers cards. The checker makes an off- card inspection to the codes carefully to ensure that the code is safe, then he puts a digital signature in the code and sends the code with the signature back to the service provider. On the card side, the JVM will use the checkers public key which is stored in the card when the card is initialized, to decrypt the checkers signature. The JVM will decline to execute an applet without the signature of the checker, or in case of a tampering to the code is detected after the code is signed by the checker.

9. The second concern aims to the multi-services feature –What about if a service provider attempts to steal sensitive data (keys and values) from other services in the same card through access to the data fields and methods of other services? –Solution by the Java Card object sharing mechanism: The minimum downloadable unit is a package or an applet (not a class, Java Card doesnt support dynamic class loading). Each package has its own context (you can think it as a memory domain) in the card. If codes in one context attempt to access data or codes in another context, the JVM will invoke a program called the Applet Firewall (AF), to see whether the callee is declared as sharable by that particular caller or all other callers. If it is, the JVM will do a context switch to the callees context and execute, then do another context switch back to the callers context with the result passed back. Otherwise a runtime exception will be propagated up.

10. It seems all the back doors are tightly closed!!!! But is it really safe then????

11. An interesting point (an easy point from where you can start your attack) –My first feeling to this point is somewhat like: Everything is perfect, but……a little tail up there. –Java Card Framework (JCF) security mechanism doesnt deal with native method calls at all. That means you can embed native methods in your applets, then you can completely bypass the security guard provided by the JCRE and make direct calls to the OS libraries. That also means you can do whatever you want! –Why? I dont know. (My guess) The JCF wants to leave some flexibilities to the applet developers to use functions provided by the card OS libraries that are not covered by the JCF API. Another reason is possibly for gaining better code performance. –Then we have another problem.

12. Question: What is/are needed to avoid erroneous/malicious misuse of native methods?

13. My answer: A more sophisticated Open Card Download Framework. The OCDF should define a set of rules for restriction use of native methods. The checker (a publicly trustworthy authority) should have good knowledge of all card platforms in the market, in order to check out all potentially dangerous OS library calls, and then decline to sign the code. In a multi-card-issuers and multi-service-providers environment, things will get much more complicated. A higher level of back-end card management facility is needed.

14. Conclusion: While Java cards provide useful and convenient features to service-oriented application developers and end users, however, it is these features that introduce new security issues. Although the Java Card Frame work has provided means to cope with these problems, but the incorporation with some effective off-card, back-office check is a must- need to ensure full-scale security, and also, this back-end part is the hard part in the security system of the Java Card world.