Some questions about SELECT APDU command in Javacards

Question

The quoted below passage is a part of an article that named How to write a Java Card applet: A developer's guide and written by Zhiqun Chen.

I saw it here

Once an applet is selected, the JCRE forwards all subsequent APDU commands (including the SELECT command) to the applet's process() method. In the process() method, the applet interprets each APDU command and performs the task specified by the command. For each command APDU, the applet responds to the CAD by sending back a response APDU, which informs the CAD of the result of processing the command APDU. The process() method in class javacard.framework.Applet is an abstract method: a subclass of the Applet class must override this method to implement an applet's functions."

Update :

And also the below passage is a part of an Oracle article that named Writing A JavaCard Applet (Here):

Examines the Header

The process method examines the first two bytes of the APDU header, the CLA byte and INS byte. If the value of the CLA byte is 0 and the value of the INS byte is 0xA4, it indicates that this is the header of a SELECT APDU command. In this case, the process method returns control to the JCRE:

// check SELECT APDU command 
if ((buffer[ISO7816.OFFSET_CLA] == 0) &&
(buffer[ISO7816.OFFSET_INS] == (byte) (0xA4)) )  
 return;

enter image description here Q0: In the above Image App1 was selected already. when the new SELECT APP2 command receive by JCRE, What it do? It refers it to the process() method of App1 and receives a return from it? Or it call deselect() method of App1 and then call select() method of App2?

If JCRE sends the SELECT App2 APDU command to process() method of App1, what happens after receiving a Return from it?!

If JCRE right after receiving SELECT App2 APDU command, call deselect() of app1 and then call select() of app2, what it do after receiving true from app2 select() method? Does it wait for next command?

Q1 : Based on the above passage(Specially the part that is in bold) I conclude that I can write an applet that as it selected, Its impossible to select another applet(Until the card remove from the CAD).For this purpose we just need to write a code in its process() method to select itself when it receive a SELECT APDU command. Is this right?

Q2 : Is there any way to deselect an applet without sending another select command or removing the card from CAD?

Q3 : Is is possible to write an applet in a way that it remains active in the background of another active applet? (something like a key-loggers in computers) I myself think it is impossible because of incompatibility of java card with multi-threading. Is that right?

Appreciate any help.

Maarten Bodewes Maarten Bodewes · Accepted Answer · 2014-09-21T15:18:11

Q0 (update): If a SELECT by NAME is received for a that does not select the current applet then:

if another Applet is selected then only the deselect method is called
if no other Applet is selected then only the process method is called

Q1: No. The system will still handle all the SELECT by NAME APDU's before it forwards it to the Applet process method. So another Applet can be selected before the SELECT is send to the currently selected applet, and the newly selected Applet will receive the APDU instead.

Note that the system will even re-select the current Applet if a SELECT by NAME is received with the current Applet's AID (so all memory and objects that are cleared on deselect will be cleared, and the select and deselect methods will be called).

Note that later API's (Chen's book is still applicable, but aging a bit) have added a method to check if the APDU was used to select the current Applet. This is also useful to check how it was selected, which primarily is useful if the Applet is also selected by default, i.e. before any APDU was received.

Q2: No, currently not. This is tricky functionality that will have firewall and security implications. So this would not be a minor update to the Java Card standard. It comes up quite a lot on the forums though. You may access other applets through the firewall of course.

Q3: There are indeed no background tasks. Adding multi-threading would completely break the API of Java Card Classic Edition, so it will never be added. To share information both Applets must be explicitly designed to do so, and the firewall rules will be in effect.

Some questions about SELECT APDU command in Javacards

2 Answers