Java Card: Can applets be installed by other applets?

Question

In Java Card, is it generally possible for new applications to be installed from within the context of an existing application on the card, for example by sending the new code via an application-defined messaging format and then creating a new application instance using some card manager API?

Or is this only possible externally using the corresponding APDUs?

If this is something not covered by the Java Card and/or the GlobalPlatform specification, can it be done using vendor-specific methods?

Saiz

Answer 1

Theoretically this could be possible for normal Java Cards, given that:

• you can install an applet with the Security Domain privilege (support for this is optional);
• the Security Domain has the option to perform INSTALL [for Load] (support for this is optional);
• the applet can receive and alter the APDU buffer before the Security Domain functionality is invoked (using SecureChannel.processSecurity) - as processSecurity should itself retrieve the command data according to specifications this is more unlikely then you might first think;
• the applet has been given access to the keys to recalculate the MAC (these are keys are kept hidden from the Applet itself), assuming that the card is in GP_SECURE mode.

In this case you could convert your own APDU's into specific APDU's that comply with the GP specifications and simply call SecureChannel.processSecurity to get them processed.

Practically I don't think above will ever be the case, but you never know. You'd explicitly go around the security protocols defined for the card implementation, so I'm pretty sure you'd be asked very explicit questions by anybody auditing the solution.

---

Now if you just want to install applets through your own security domain then this is explicitly covered by Global Platform. You'd just check the manuals of the product if security domains and INSTALL [for Load] is supported and you're good to go.

---

As vojta has already indicated, there is no API for handing over INSTALL [for Load] commands, so programmatically you'd be stuck.

---

An incredibly stupid way to do it would be to program your own VM and install it as an applet. Probably not practical in 99.999% of the cases. It would still only be reachable as the VM itself of course, it would not be given its own Application ID (AID) by the card.

Iridescent

Upvoted for finding new crazy ways to complete the mission! "Impossible" is just a word :-). – Break

Your answer is probably more practical. I would not choose this as an answer, just using the security domain is the only practical option in my answer. – Iridescent

Answer 2

No, it is not possible.

You cannot send APDUs from your applet to Card Manager applet, which is what you need to install a new applet. Card Manager also doesn't provide any Shareable interface for this task (usually).

The only way is to send APDUs via the terminal, but it is not what you probably want. This way would be easy: your applet would need to hold the complete binary of the new installed applet and keys of the Card Manager.

However!

You can install an applet by another applet on SIM card using so called proactive commands, see this SO answer. Provided the device allows it, you can send PERFORM CARD APDU command from the first SIM slot to the second SIM slot and install a new applet this way. Then you could use this new applet on SIM2 to install another applet back on SIM1.

Moreover, you could send OTA commands using proactive commands and install a new applet instance remotely. I tried this a few years ago with a very simple pair of applets and a test SIM card and it worked.

Theoretically, it might be possible to implement a Java Card applet which will spread itself over the mobile network provided you have all the necessary keys. However, this is closely related to the Java Card quine, which is not solved as far as I know.

Break

Wow, that sounds like an interesting approach! This would require power cycling the second SIM card to select the card manager AID on it though, right? Or are the command performed in this way sent over a new logical channel independent from the GSM applications etc.? – Saiz

@Ixgr See Annex G of the specification. The problem is that some phones do not recognize the second SIM slot as another card reader. – Break

Ah, I see, it seems that the second card will be warm reset once the first card opens a session using the proactive command. Wouldn't this interfere with an active USIM application on the second card though, or did you use a dedicated card without the normal GSM/3G stuff on it for this? This doesn't actually apply to the area for which I'm researching this (the first part of your answer already confirmed what I needed to know), but now you got me interested. Really fascinating stuff :) – Saiz