GlobalPlatform is evolving, but it is very closely linked to Java Card, as it provides the deployment standard that Java Card needs to manage its applications.
GlobalPlatform is evolving, and the next specification (GP3) is under way. It will target the next generation of cards, and some of it has already been published in the GlobalPlatform Networked Framework. This specification supports networked cards, and it also allows the management of cards over TCP/IP, which is emerging as a new protocol on cards.
However, GP3 has the ambition of bringing back together the various documents produced by GlobalPlatform since Java Card 2.2, including all amendments. This is great news, because GP2.2 already did a great work at clearly defining and bringing together many different concepts that needed such a definition.
The future document will be based on a common architecture and security principles, with four additional parts:
- Secure communications. Building on the existing secure channel protocols, GP3 will add support for SCP81 (TLS), and for SCP20 (transport-independent security).
- Networked communications. How to manage applications over HTTP.
- Classic framework. The existing GP2.2 framework, with slight enhancements.
- Networked framework. Based on the just released GPNF, and included support for Java Card 3.0 (other frameworks could be supported in the future).
In addition, GP3 will define a set of profiles, that will implement a consistent subset of this specification. The components are mostly ready, and the intention is to work on the new specification during 2010.
Beyond specifications, there are migration issues, when someone wants to move from an APDU-based card to a networked card.
In terms of administration, there are a few major changes:
- The commands have changed from APDU’s to BER TLVs, which are defined in ASN.1 on the card.
- The secure channels have changed from specific protocols to standard Web protocols.
- Finally, although this is not related to GlobalPlatform, the formats used for downloading have changed from CAP files to WAR files.
Taken individually, all of these steps are rather easy to deal with. The principles of content management are not dramatically changed; only the protocols change. The real difficulty is to transition from APDU-based cards to networked cards. From the content management point of view, there are three solutions:
- Dual card. Such a card would fully support both mechanisms (CAP files, APDU-based GlobalPlatform on one side, WAR files and networked communication on the other). This is very simple to manage, but these cards will be too expensive.
- Migration card. In such a card, the runtime environment is unique (networked card, with WAR files), but both administration formats are supported (APDU or Web). This is an interesting intermediary point, since it will support “old” administrative tools, while allowing the deployment of Web applications.
- Connected card. In that case, all operations must be migrated to the connected network
An alternative way to deal with the migration issue is to develop an automated converter, that will transform GP2 commands into GP3 commands, and allow the management of classic applications.
From the secure channel point of view, the situation is approximately the same, with one major difference: one of the secure channel protocls (SCP81, or TLS), will be supported on all cards, at least in the SIM market.
Well, administration tool developers have some work to do. However, if card vendors produce “migration card”, things should be made quite easy on them. It is nice to see that GP is thinking about migration even before to write the final spec, as it increases the chances that we eventually get a workable migration path. This is much more important for GP than it is for Java Card, as card management tools are an important asset of the industry, making a smooth migration mandatory.