CODEWITHSUNDEEP
smartcardjavacardglobalplatform
Shluch
Shluch

Reputation: 453

What is the correct approach to make a JavaCard applet updatable?

I want to be able to update the Applet after distribution to clients. I don't want to ask them to send me back the chips, if we need to update the applet. I want to give the a script to run in their card-reader.

The problem is that for updating the applet, I need to give them a script with unlock key, but I don't want to give them the key.

There is any way to sign a new applet, and the JavaCard (GlobalPlatform) will know that it's an original applet and only then it will be installed?

I thought maybe to create new Applet that have the install privilege (There is something like that?) and it will be responsible for installing a new applets.

Upvotes: 2

Views: 871

Answers (2)

vlp
vlp

Reputation: 8116

(extending answer given by k_o_)

  1. Use secure channel protocol with a pseudo-random challenge, citing GP 2.2. Amendment D:

The Secure Channel is used to personalize cards at Issuance and during Post-Issuance. The mode of the Secure Channel Protocol which uses pseudo-random card challenges allows the offline preparation of personalization scripts while the card is not present and the processing of these scripts on the card without an online connection to the entity that prepared the scripts.

Options I am aware of are:

  • SCP02 with "i" parameter having 'b7' set (typically "i=55") -- see e.g. GP Card Specification 2.3.1, sections E1.1 and E.4.2.3

  • SCP03 with "i" parameter having 'b5' set -- see e.g. GP Card Specification 2.2 Amendment D, sections 4.1.5, 6.2.2.1

You will need to store extra information (at least the counter value) for all deployed cards.

(If I recall correctly,) you will need to generate unique script for every deployed card (assuming diversified card keys are used).

Be warned that some nasty MITM attacks are possible (e.g. premature termination of personalisation script).

(I had a proof-of-concept implementation for SCP02 i=55 and it worked well)

  1. If your updates will change only small parts of your applet logic (and you know in-advance which parts) then you can:

  • make those parts configurable and perform updates by remotely changing the configuration

  • implement a virtual machine performing those parts and remotely update its bytecode

(I had a simple virtual machine implemented in a Java Card applet and the performance was sufficient for simple crypto tasks)

Some additional notes:

  • with APDU proxy (option 3 in k_o_ answer) -- use secure channel with both integrity and confidentiality (including R-MAC if possible) -- nasty MITM attacks are possible without proper protections applied (assuming update takes place in an insecure environment)

  • if your applet instance contains any state information (data) that needs to be preserved across updates it gets even more complicated

Upvotes: 1

k_o_
k_o_

Reputation: 6298

You have several options:

  1. You can create off-card scripts if you card is supporting SCP11c. This way you can just send out the install script to your client. But I have not heard of any card supporting this mode but I have also not searched for it.

    1. You create a dedicated security domain for your applet using classical SCP02/SCP03. You still have to provide the keys to this domain, but your client cannot interact with other data in other security domains anymore at least. If the card is just for one tenant you could still use the issuer security domain. The card has to support this, maybe it is not supported.
    2. To prevent your clients to install arbitrary content you can use DAP verification. The security domains must have this privilege and must be equipped with a key for it. DAP verification attaches a signature to your applet data which is checked by the security domain. It must match, otherwise the applet cannot be installed. The card has to support this, maybe it is not supported. You could also use an "Install Token" for a similar purpose also checking all installation parameters.
    3. To prevent that your code is inspected - it is byte code and could still reveal things you are doing, although it is hard to read it - you can encrypt the applet code. Ciphered Load File Block is the term to look up here in the specification, You again have to give this privilege to the security domain.

  3. Set up a server supporting remote content management. You have to provide a proxy implementation to your clients proxying the APDU data between the card reader and your server. There is the GP RAM specification describing such a system, but you could also use your own (simpler) implementation. Your server has to assemble all APDU commands, send it to the proxy and the proxy will provide the APDU responses. You could use standard tools using PC/SC under the hood together with a remote smart card. E.g. I have written GPShell, maybe it could be used together with it. But instead of scripting tools together you could also implement it as a real server, e.g. using a custom connection plugin together with GlobalPlatform. There are also java libraries available which might be more handy, if you are developing in a Java environment. This approach is the most flexible one and provides also a convenient way for your clients to be notified about updates.

Check GP 2.3.1 for more information about the hints I gave. It all depends what your card supports and if you can find some tools and libraries also supporting this.

Upvotes: 3

Related Questions