Learning from Thailand: The Nitty-Gritty of Smart Card Security

Security doesn't start with a smart card; it also is affected by how the smart card stores data

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?