Most modern smart card operating systems allow various management operations to be performed on files within limits set by specific security conditions, including extending, creating, deleting and blocking files. Nevertheless, most or even all management functions are frequently omitted in single-application cards, since these functions generally require a large amount of program code, which would increase the memory capacity and thus the cost of the card. With multiapplication cards, support for certain management functions is essential in order to avoid having to load all the applications into the card when it is personalized. With regard to system security, management functions should only be allowed to be executed following mutual authentication, since they are ideal starting points for an attack. For example, suppose an unauthorized person were to delete a file holding confidential data and then create a new file with the same name but without any read access restrictions, so that it could be still be read with its original name, therefore confidential data could be writen to the manipulated file. This type of attack is by no means new; it has been around for many years in a somewhat different form. However, it is used successfully over and over again in file management systems. Another possible point of attack is provided if management functions are used in publicly accessible terminals, which in principle are insecure. In such situations, data transfers must always be protected using secure messaging functions. Only then will an application provider be able to securely load files and applications into cards already in use, for instance via public card phones. This is a very attractive option for logistics reasons. Particularly in the case of multiapplication smart cards, which can be used by several application providers, it is necessary to partition the memory and assign authorization keys for file creation before the individual applications are generated. This prevents any individual application provider from allocating the entire available memory to his own application, leaving none for other applications. One way to prevent such behavior is to use a procedure that preallocates memory space to each application and at the same time stores card- and applicationspecific keys for creating files in the card. This can be done using the REGISTER command, which is not standardized. New files can be created at a later date if the application-specific key is known. This method creates a strict separation between allocating memory space and loading new files into the card. The issuer of a multiapplication card can thus sell memory space to several application providers without having to worry about memory piracy. The CREATE FILE command allows DFs or EFs to be created in smart cards after they have been completed. Before this command can be executed, a particular logic state must have been achieved, for example via successful mutual authentication. Depending on the environment in which the CREATE FILE command is executed, data transfers may have to be protected by secure messaging. The CREATE FILE command is defined in the ISO/IEC 7816-9 standard.

After a file has been created with all of its access conditions, attributes and other properties, it can be selected using SELECT FILE and then accessed. The operating system must make it impossible to create an incomplete file by interrupting the file creation process, since such a file could provide a basis for an attack on the card. Furthermore, it must not be possible to read out the residual contents of memory areas that are only partially overwritten when a new file is created. The file header contains the complete access conditions for the file. For example, it can store data relating to the states in which a READ or UPDATE command is allowed to access the content of the file. Particularly when a card is being personalized, as well as for extensive management procedures within the file tree, it is a major advantage to be able to access files directly without object protection. For this reason, a previous version of the ISO/IEC 7816-9 included a command called MANAGE ATTRIBUTES that could be used to change the access conditions of a previously selected file. This command could only be used following mutual authentication and within a secure environment. However, itwas made redundant by the introduction of security environments and rule-based access conditions as defined in ISO/IEC 7816-9,4 and it is no longer included in the standard. Nevertheless, it is supported by some smart card operating systems, due to the simplicity of its implementation. If the REGISTER command is available, the card issuer uses it to specify the maximum amount of memory that can later be allocated to an application. In addition, a temporary DF name, which may contain an application identifier (AID), is specified, and a key for the CREATE FILE command is stored in the card. Files can subsequently be created if this information is known. The user receives a smart card that has been prepared in this manner. If the user so desires, he or she can have an application provider load an additional application into the card, such as a card phone application. However, the application provider must know the secret download key before he can load a new application into the card, and the card issuer will naturally not provide this key unless there is a contractual relationship between the two parties. After successful mutual authentication between the smart card and the terminal, the application provider can create his files in the DF allocated to him. This can take place either on the provider’s premises or via a public card phone. Next, the provider fills the EFs with the necessary data and keys and sets the access attributes of the files. After this, the application is ready to use, and the user can enjoy his or her newly acquired functions. The procedure for loading a new application in the file tree of a smart card is illustrated in Figure 7.18.

The DEACTIVATE FILE command (defined in ISO/IEC 7816-9) and the INVALIDATE command (defined in GSM 11.11) allow the terminal to reversibly block a previously selected file. When a file is blocked, read and write accesses to the file are prohibited, and only selection is allowed. The EMV specification provides a similar command for reversibly blocking applications, called APPLICATION BLOCK. This command does not block the EFs within an application, but only the commands for file selection, authentication and financial transactions within the DF of the application. The functionality of the APPLICATION BLOCK command is otherwise similar to that of the DEACTIVATE FILE and INVALIDATE commands. The inverse functions for INVALIDATE and DEACTIVATE FILE are provided by the REHABILITATE andREACTIVATE FILE commands, which can be used to unblock a blocked file. The file must be selected before it can be unblocked. It goes without saying that execution of all these commands can only be permitted in a certain security state, since otherwise anyone would be able to block or unblock files at will. The LOCK command is the non-reversible version of INVALIDATE. A file that has been blocked with LOCK cannot be unblocked. Its state is completely irreversible. Another use for this command is to permanently block an application when it reaches its expiry date. A file that has been blocked with the LOCK command can only be selected; all other types of access will be denied by the operating system. The main drawback of permanent, irreversible blocking is that it also blocks any further use of valuable memory space in the card. A much more elegant solution is to erase the memory regions occupied by files that are no longer needed, so they can be used by other applications or new applications. When doing so, it is important to not only delete the file from the file tree, but also to physically erase the entire memory area that was used by the file(s). Only in this way can one be sure that all of the file contents, which may certainly be confidential and worth protecting, have been overwritten and are thus no longer accessible to anyone. If the memory that comes free when a file is deleted is to be made available for use by other files, deleting a file becomes a complicated and costly process. Consequently, it is not fully implemented in all operating systems.

In principle, the DELETE FILE command can be used to block and unblock files in exactly the same way as the previously described commands. A file that is implicitly selected with this command can be completely removed from the file memory of the smart card. Whether the memory space that is released as a result can be used for other files depends on the individual operating system. As a rule, free-memory management is not available, so the memory space is lost forever after this command has been executed. The command TERMINATE DF is provided in the ISO/IEC 7816-9 standard for irreversibly blocking a DF. A blocked DF can still be selected, but the functions (such as program code) and files it contains are no longer accessible. This command can be used to ‘switch off’ an application while allowing the previous presence of the application to still be recognized. The functionality of the ISO/IEC 7816-9 TERMINATECARDUSAGE command is similar to that of the TERMINATE DF command. However, this command blocks the entire card, and thus the execution of any subsequent commands. After this, the only thing the card can do is indicate its newstatus in theATR. TheEMVequivalent of this command is the CARD BLOCK command, which has similar functionality.