Status words are very important in the ISO7816 specification, since they are used to indicate specific conditions. The ISO7816-3 specification states the following:
60is the NULL byte, used to get additional time.- Status words starting by
6X(except60) have a “meaning [that is] independent of the application”. - Status words starting by
9X(except9000) have a “meaning [that] relates to the application itself”.
What that means is that the GSM specs are correctly defined, as they use 9X status words for application-specific statuses, but the Java Card spec is not correct, since it defines the 6999 status word, which is reserved by ISO7816 for future use. On the other hand, one can argue that the meaning of 6999 is independent of the application. Still, not perfectly clean.
The ISO7816-3 specification provides meanings for a few 6X status words, and the ISO7816-4 specification provide a few more. The list provided in ISO7816-4 is as follows:
61XX: Normal processing, XX indicates the amount of data to be retrieved.62XX: Warning, the state of persistent memory is unchanged. The command succeeded, possibly with restrictions. Typically used to signal blocked applications.63XX: Warning, the state of persistent memory is changed. Typically used to indicate the number of attempts left on a PIN code after a failure.64XX: Execution error, the state of persistent memory is unchanged.65XX: Execution error, the state of persistent memory is changed.66XX: Security-related issues.6700: Transport error. The length is incorrect.68XX: Functions in CLA not supported (since 2005).69XX: Command not allowed.6AXX: Wrong parameters P1-P2 (with details).6B00: Wrong parameters P1-P2.6CXX: Wrong Le field.XXindicates the appropriate length.6D00: The instruction code is not supported (usually with XX=00).6E00: The instruction class is not supported (usually with XX=00).6F00: No precise diagnosis is given
The ISO7816-4 defines many more SW2 values (around 40), and it also defined a few important rules, which can be used as good guidelines:
61XXand6CXXare different. When a command returns 61XX, its process is normally completed, and it indicates the number of available bytes; it then expects a GET RESPONSE command with the appropriate length. When a command returns6CXX, its process has been aborted, and it expects the command to be reissued. As mentioned above,61XXindicates a normal completion, and6CXXis considered as a transport error (defined in ISO7817-3).- Except for
63XXand65XX, which warn that the persistent content has been changed, other status word should be used when the persistent content of the application is unchanged. - Status words
67XX,6BXX,6DXX,6EXX, and6FXX, whereXXis not 0, are proprietary status words, as well as9YYY, whereYYYis not000.
Note that the last point extends the realm of the status words that can be defined in a proprietary way. However, Java Card’s 6999 remains a violation of the rule.
First: Great blog about the smart card world.
SW1SW2 = ‘6999’ is one of the incompatibilities between a pure Java Card and a GlobalPlatform card. MultOS gets rid of this problem by combining content management into the SC-OS. Still I think the Java Card / GP approach is the more flexible one. One just has to make sure that the specs are “in sync” with each other: JC, GP, VGP, MC and ISO.
Multos did things right in defining the content management and the application framework together, because it more or less guarantees their efficiency.
The ‘6999’ thing is really one of the most stupid decisions in the Java Card spec, and it has led to numerous headaches, and I hope that we are better now.
About your last sentence, I just love it, but I am not quite sure how to achieve such a synchronization. The main issue is that all these work groups work at the same time, and that when they synchronize, it is often too late. But we’re trying.