10-04-2013 07:29 AM
I have found an interesting problem when I'm trying to send apdu to my javacard applet.
I have defined the CLA 80 for my applet's cla and a have sent this apsu to:
I have debugged, the BB app sendind this apdu:
I have debugged a bit and found the following results:
sending CLA 80 resulting 82
sending CLA 81 resulting 82
sending CLA 82 resulting 82
sending CLA 89 resulting 8a
It seems BB don't like non iso standard cla and it will modify.
Any reason for this?
10-04-2013 09:26 AM
Let me do some digging and see what I can come back with.
10-04-2013 12:04 PM
10-05-2013 01:24 PM
Thanks for the reply. I'm not planning to use multi selectable applets. Are there any to communicate with my applet through secure element without logical channels?
10-07-2013 03:24 AM
No. All carrier/GSMA requirement specifications as well as the OpenMobile spec forbid access to the basic channel on the UICC for applications so we do not allow it.
10-07-2013 05:22 AM
Thank you for the help! I have solved the problem on the applet side, but I have an other problem now:
I'm using pin code on the applet to restrict some features. If I authenticate with the pin, it will be authenticated when I turn off the phone or select applet again.
On Blackberry, when I send an APDU it will first select the applet, so I cannot use the pin feature, because on the next command it will select the applet again and the pin will be unverified again.
Now I made a workaround on the applet to store the authentication state separately, but it has security problems.
The question is:
Can I run multiple APDU commands without selecting the applet after every command?
10-07-2013 06:32 AM
Yes you can send multiple APDU after selecting the applet. To be clear, by "select" you mean calling nfc_se_session_open_logical_channel from the application which of course performs the ISO7816-4 SELECT behind the scenes.
Can you clarify the issue you're seeing and share the related fragment of your code please?