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.
Someone at the Interior Ministry pointed out that this broke one of the cardinal rules of Java Card security -- as a non-owner would now have unrestricted access to another applet's data. As such, it follows that this non-owner can override locks in applications and thus make a mockery out of Java Card security.
For instance, suppose that applet C is in a locked state pending the right unlocking code after failed attempts at entering a PIN code. Security would dictate that all of applet C's data is not readable until the unlocking code is provided. However, if at that time someone wants to update applet B, the backup/restore code must be able to backup applet C -- including its locked-down data.
The important point here is that security is now no longer a function of the Java applet and the (quite comprehensive) security features of Java Card. Security is only as strong as the weakest link -- the backup/restore module itself.
What if the backup/restore module had an unintentional bug or back door? What if someone writes a malicious applet that pretends to be the backup/restore module to access locked-down data?
I am not saying that the Thai smart ID card necessarily fails this point of the ToR, though I would not be too surprised if it did. What I am saying is that there is sufficient reason for the card to be re-tested with the memory management module in place; that the card with and without the memory management module are materially different and as such any guarantees of Global Platform compliance of the basic card are not automatically applicable to the card once the memory management module is installed.
After all, I am sure everyone agrees that we want a card that fully complies with the ToR today -- wouldn't we?
