JavaCard & Mifare Access (6131)

[geri-m]

Is it possible (like on the 3220) to access the Mifare Memory thru the Java Card?

[tdelazzari]

Yes I think but not tested yet. Maybe you can try with JetZ API.
Modifying it to work with 6131 does not need much work.
ExtSystem's sReadWriteMifare() method works similar to JCOP's method. Only difference is the first parameter defining what the method should do (read ExtSystem.MIFARE_PASSWORD_READ and write ExtSystem.MIFARE_PASSWORD_WRITE).

[geri-m]

Okay, but where do I get the ExtSystem Library? It is neighter part of JCOP nor part of JetZ ...

[yakdogan]

Is it possible (like on the 3220) to access the Mifare Memory thru the Java Card?

Sorry I don’t know the answer to this question.

But I am interested to know:
what is the advantage / disadvantage of between ‘Java Card Applet Access’ and ‘MIDlet Access’ to Internal Mifare Memory.

Could you give an Use Case to visualize both access ways?

Best regards.

[geri-m]

Actually the answer ist quite simple: I don't want to have my keys for mifare access stored in J2ME Appliction. With the right efford an attacker could aquire the keys from the memory or by decompiling the Application Code and the "security" for my application would be gone. (I do need Mifare as I don't want to change my existing reader infrastructure ...)

If I do have the keys in the JCOP Applet nobody would ever be able to get them. Additionally I could use AES/DES for encrypting data and save it encrypted in the Mifare Element. The seperation of data and code by splitting an application into JCOP and Mifare (if necessary) would be a good solution for me.

[yakdogan]

Yes I see the advantages, thank you.

The Applet solution has the personal key and DES/AES crypto functions available in internal smartcard whereas MIDlet solution has the key in Phone and need additional crypto libraries like SATSA or third party libs.

Splitting code and data:
Are not the same in both access ways? Code in Applet or MIDlet, data is in Mifare Memory?

[geri-m]

ad SATSA) Actually it would make sense if "new" mobile devices would use the cipher algorithms of a smartcard/SIM Card/Secure element in order to provide "good" protection against attackers. Everything running on host controller or in the memory of the device can/could be traced therefore is not secure. Actually the SATSA also provides a package for communication with a smartcard using RMI or APDUs thus if the SATSA is fully available on a device, it would make sense to make use of the smartcard for the "critical" code.

ad Splitting Code & Data) My current view for an NFC application is the following:
- the GUI is implementend in J2ME (or Symbian or PCC)
- the controller/application logic (as much as possible) is implemented on the Java Card/Secure Element
- the Memory of the MIfare Element is used for storing data (for backward compatibility)

This makes me less plattform dependend when moving applications to a different device, as long as it features a Java Card. Actually this is the problem with the 6131. The "standard" JetZ Engine is not available on the JavaCard as the Operating Systems is not from IBM but from G&D (Venyon) => plattfrom matters in this case.

I'm currently looking a bit further, as I'm working also with Java Card SIM cards too, where I can implement the GUI on the SIM using SAT. There I don't even need the J2ME at all for a GUI.

But you are right too: J2ME application - Mifare Data would have a similar (in my view less secure, less plattform independed) impact.

[tdelazzari]

My current view for an NFC application is the following:
- the GUI is implementend in J2ME (or Symbian or PCC)
- the controller/application logic (as much as possible) is implemented on the Java Card/Secure Element
- the Memory of the MIfare Element is used for storing data (for backward compatibility)

This is exactly what a NFC application should look like. Especially for mobile payment or ticketing application.

The "standard" JetZ Engine is not available on the JavaCard as the Operating Systems is not from IBM but from G&D (Venyon) => plattfrom matters in this case.

Is it SmartCafe OS ? JetZ API should work with a some small modif. Someone from Nokia can confirm ? What exactly are the changes ?

I'm currently looking a bit further, as I'm working also with Java Card SIM cards too, where I can implement the GUI on the SIM using SAT. There I don't even need the J2ME at all for a GUI.

Did not know about that, do you know where we can buy those Java SIM Card ?