A requirement that is frequently imposed on smart card microcontroller software is that certain parts of it must execute either completely or not at all. Operations that are indivisible and thus fulfill this requirement are called ‘atomic’ operations. They always occur in connection with EEPROM write routines. Atomic operations are based on the idea of ensuring that when an EEPROM write access occurs, the data in question must never be written only partially. This could happen if, for example, the user pulls the card out of the terminal at the wrong instant or there is a sudden power failure. Since the smart card has no buffer for electrical energy, the software in the card would immediately lose its ability to do anything at all in such cases. Particularly in the case of electronic purses in smart cards, it is essential to ensure that file contents are complete and correct at all times. For instance, it would be absolutely fatal if the balance of a purse were not completely changed to its new state if a card is suddenly pulled out of the terminal. Entries in log files must also always be complete. Since the hardware of a smart card does not support atomic operations, they must be implemented in software. The methods that are used for this are in principle not new. They have been used for a long time for databases and hard disk drives. The basic procedure of a method that is used in smart card operating systems is described here. This error recovery procedure is transparent to the outside world and thus does not require any changes to existing applications.

For purposes of demonstrating how this method works, let us assume that data destined for a particular file are sent to the smart card via its interface. This would be a typical process with an UPDATE BINARY command, for example. You can follow the exact process by referring to Figure 5.37 while reading the following description. In the EEPROM portion of the operating system, a buffer is created that is large enough to accept all of the necessary data. This buffer has a status flag, which is also stored in the EEPROM. The state of the flag can be set to either ‘data in buffer valid’ or ‘data in buffer not valid’. In addition to the buffer, there must also be suitable locations in memory for the target address and the current volume of the buffered data. The procedure works as follows. In the first step, the data starting at the target address, for example in a file, are copied to the buffer according to the specified physical address and volume of the data. The buffer flag is then set to ‘data in buffer valid’. In the following step, the operating system copies the new data to the desired address, and then changes the buffer flag back to ‘data in buffer not valid’. Whenever the operating system starts up, it checks the buffer flag before sending the ATR. If the flag is set to ‘data in buffer valid’, the data in the buffer are automatically written to the memory area specified by the stored address and volume information. This mechanism ensures that the data in the file are valid under all circumstances. If a routine is aborted at any time in the process of program execution, the data in the smart card EEPROM can always be restored. For example, if the cardholder pulls the card out of the terminal at the third step of the procedure – in which the new data are written to the EEPROM – the new data will be only partially present in the file. When the card is again activated in a subsequent session, the operating system notices that there are valid data in the buffer and copies them to the appropriate location. This restores the original status of the file, so the contents of all of the files in the EEPROM are consistent. The initial waiting time between the individual bytes of the ATR provides an excellent opportunity to make this correction.

The procedure just described has two serious drawbacks. The first is that the buffer will have the heaviest write/erase stress of all of the EEPROM. Since the number of write/erase cycles for any given region of the EEPROM is limited, it is highly probable that this important buffer region will be the first part of the EEPROM in which write errors start to occur. Such errors would mean that the smart card could no longer be used, since the integrity of the data would no longer be assured. This problem can be made less severe by using a cyclic structure for the buffer, so that the same region is not written every time. Unfortunately, this forces the buffer to take up a relatively large amount of memory. The second disadvantage of this implementation of atomic operations is that it increases program execution time, due to the obligatory write access to the buffer. In the worst case, the file access can take three times as long with this procedure as it would if the data were written directly to the file in the EEPROM. It is thus common to limit such buffering to write accesses to certain files or data elements, rather than buffering all EEPROMaccesses. This can be specified by an attribute in the header of each file. This procedure can be very easily extended to writing not just a single data element into the buffer, but instead several data elements. If this is done, it is even possible to have write accesses to several different files or data elements be performed either completely or not at all. Practically all smart cards operating systems, such as Java Card, support atomic operations, and they may also allow relatively long sequences in the program flow to be marked as being atomic, thereby protecting them against power interruptions.