Warning: This week's column may be too technical for some. Programmers and CIOs should find it informative, though if you are a programmer or CIO and still cannot understand it, perhaps it is time to find a new, less technical job.
I woke up recently to an in-box full of information on the Thai smart ID card project, which one of the vendors involved in the bidding process had kindly agreed to give me on condition of anonymity. In a nutshell, the vendor had pointed to paragraph three of section 2.3.8 in the Terms of Reference that states that the card operating system must be compliant with version 2.0.1 or higher of the Global Platform specification. The vendor noted that nobody in Thailand, not even Nectec, had the verification equipment and that verification of Global Platform compliance needs a sample of 100 cards to be tested, not just one.
At the risk of greatly over-simplifying things (an occupational hazard in writing for a mass-circulation newspaper), one important part of Global Platform compliance is a lifecycle security management model. For instance, an ID card has stages in its life _ when it leaves the factory, when it is waiting to be initialised, when it is in use, when it has been locked-down because of multiple failed attempts to use it and when the card is terminated and no longer in use. At each stage, some functions are mandatory, some are prohibited and some are optional. All in all, the Global Platform specification spells out across 240 pages when each type of function is allowed.
For instance, before a card is initialised you would want to be able to install low-level infrastructure applets such as the 8KB fingerprint matching software (which, incidentally, costs Thai taxpayers 40 million baht) and the PKI security library. Once the card is in use, however, you may not want these program to be changed no matter what. A bug fix would be better dealt with by issuing a new card rather than to potentially compromise the entire system's security apparatus by allowing such a mission-critical applet to be re-installed in the field.
Another example is when the card is terminated. Some data for some applets should still be readable _ such as card identifiers and cause of termination. However, the vast majority of applets must be locked down so that not only are the applets not to be run, but their data must never be read again.
Now, here is the interesting point. While I am sure that the Thai smart ID card is quite probably Global Platform compliant when it leaves the factory, it is hard to see how it can still be compliant when the rather interesting memory management module is installed.
Recall how Nectec earlier reported that the card lacked the Java storage memory management class to add and remove applets without affecting other applets. For a complete Java Card 2.1.1 implementation, if you have four applets, A, B, C and D installed in that order, you can install and remove them in any order and the new ones can be bigger than the old ones. However, on the Thai smart ID card, the lack of Java Card memory management meant that if you wanted to change C, and the new C was bigger than the old C, you would be forced to uninstall and then re-install D as well. If it were smaller, you would end up with a memory hole that would be wasted.
Now, this would not be a problem in a single-issuer smartcard system, where every applet belonged to the Interior Ministry. But suppose that C is healthcare and D is your driving licence.Whoever updates C would need have access to both healthcare and the driving licence data -- clearly not practical in the real world.
To overcome this problem, the vendor had provided a backup/restore module that would effectively backup all the data from the Java area to the native mode area, carry out the changes (add or remove applets) in native mode and then copy everything back to the Java side.