SEARCH COMMANDS
Record-oriented structures are well suited to storing sets of related data with identical structures in a single file. A typical example is a telephone directory containing names and telephone numbers. A search command can be used to avoid having to read the entire directory, record by record, when looking for a particular name. The SEEK command can be used to search for a specified character string in a recordoriented data structure. An offset can be supplied with the command. The length of the search string is variable. The command must tell the operating system in which direction to search. This can be either from the starting location onwards (in the direction of increasing record numbers) or from the starting location backwards. The starting location for the search must also be specified. The first record, last record or current record can be specified as the starting position. If the search string is found, the operating system sets the record pointer to the location of the string and informs the terminal that the search was successful. The ISO/IEC 7816-9 standard describes two commands that can be used to search for data in transparent and record-oriented files. The SEARCH RECORD command is the ISO/IEC version of theGSM11.11SEEKcommand. The major difference between these two commands is that according to ISO/IEC 7816-9, a short FID can also be transferred within the command for implicit EF selection. The SEARCH BINARY command can be used to search for specific data in a selected transparent file. The file may be selected either explicitly by a previously transferred command

FILE MANIPULATION COMMANDS
There are several commands that allow the content of a file to be modified by means other than simple writing. The main representatives of this class are the INCREASE and DECREASE commands. They increase or decrease the value of a cyclically structured file whose content takes the form of a counter. The amount of the increase or decrease is transferred as a command parameter. The cyclic file structure is defined to meet the needs of logging functions. These commands are primarily used for simple electronic change purses and counters. For the sake of simplicity, an example cyclic file with only one record is shown in Figure 7.12. The starting value of the record is 10. On conclusion of the process, the record has the same value again. The EXECUTE command can also be considered to be a file manipulation command in a certain sense. It is used to run executable EFs (whose structure is ‘executable’). The program to be executed can receive data from the terminal via the command, and it can also send data that it generated back to the terminal as a response. This command and the related file structure are controversial, since they can potentially be used to bypass the entire security system of a smart card.

IDENTIFICATION COMMANDS
In addition to being used as secure data storage media, smart cards can also be used to identify individuals. The usual procedure involves exchanging secret information that is known only to the user and the card. This is usually a personal identification number (PIN). Everyone is familiar with PIN verification from personal experience. The PIN is entered at a terminal, and shortly thereafter the display shows whether the PIN was correct or, if not, how many attempts are still allowed. In this procedure, the smart card receives the PIN from the terminal in a VERIFY command. The PIN is usually a four-digit number, which the smart card compares with a value stored in its EEPROM. If the entered PIN matches the stored PIN, the card’s internal state changes, the terminal receives a response confirming a positive result, and the retry counter is reset to its original value of 0. If the entered PIN does not match the stored PIN, the retry counter is incremented. If it reaches its predefined maximum value, the card is blocked for further PIN verification. Many smart card operating systems allow several PINs to be used. In such cases, it is mandatory to send the identification number of the relevant PIN in all associated commands, so that it can be correctly addressed. As a rule, however, card issuers attach great importance to having only one PIN per card, even when it is technically possible to have more than one. This is essential for customer acceptance and user friendliness. The abbreviation ‘CHV’ is often used in place of ‘PIN’ in the telecommunications industry. CHV stands for ‘cardholder verification’ and means exactly the same thing as PIN. Since some of the commands described below originated in the telecommunications industry, their names use the abbreviation CHV instead of PIN. The ISO/IEC 7816-4 standard describes a PIN verification command that is largely the same as the GSM 11.11 command. Its name is VERIFY, and it can be used not only for PIN comparison, but also for verifying biometric features. Compared with PIN verification according to the GSM specification, there is only one significant difference in the coding. ISO/IEC makes a distinction in the command between a global PIN and an application-specific PIN. The command can thus be used to specify whether to verify a PIN that applies to the entire smart card or one that is only applicable to the current DF.

In some applications, the cardholder is expected to choose his or her own PIN the first time the PIN is entered. The null-PIN method can be used for this purpose. With this method, the PIN is set to zero when the card is personalized. This PIN code has a special meaning for some smart card operating systems, which reject all VERIFY commands containing a null PIN and demand that the PIN first be changed using the CHANGE REFERENCE DATA command. In this way, the user is forced to change his or her PIN, since it is not possible to alter the security state of the card if a null PIN is entered. This method is not standardized, but it can sometimes be used to advantage if it is supported by the operating system. PINs have steadily proliferated since their introduction as identification numbers for cardholders. Currently, the average card user is expected to keep track of perhaps 10 to 20 different PINs for various cards and other authorizations. The fact that this expectation is unrealistic is shown by the large number of people who jot down the PIN on the card itself. If smart cards are used, the user can be allowed to choose a PIN at will, and thus to use the same PIN for all of his or her cards. Although this may cause security problems, since anyone who illicitly acquires one PIN thereby knows all of them, it is still better than writing the PIN on the card where everyone can read it. TheCHANGECHVcommand allows the PIN to be altered. The ISO/IEC 7816-8 equivalent to this command is CHANGE REFERENCE DATA, which has the same input and output parameters. If the PIN currently stored in the card is known, it can be replaced with a new one. If the current PIN is entered incorrectly, the operating system increments the retry counter to
protect against possible attempts to use this mechanism to discover the PIN. As soon as the current PIN is correctly passed to the card, the card stores the new PIN it has received in the appropriate memory location and resets the retry counter. If a retry counter has reached its maximum value, it can be reset using the UNBLOCK CHV command with a second PIN, which is called the personal unblocking key (PUK). The PUK is usually longer than the standard 4-digit PIN (8 digits, for example). The user need not memorize the PUK, since it is only needed if the PIN has been forgotten. It is sufficient if the user has a record of the PUK somewhere at home. However, just resetting the retry counter would not help the user very much, since he or she would still not know the correct PIN. Consequently, the command UNBLOCK CHV must also provide the card with a new PIN. It should not be possible to use this command to alter the PIN of a hybrid card, which has a magnetic stripe as well as a chip. Otherwise the PIN recorded on the magnetic stripe would not match the PIN in the chip, which would cause severe problems.With such cards, the retry counter is simply reset and the customer is sent a letter with the original PIN.

The ISO/IEC 7816-8 standard has its own command for resetting the retry counter when it has reached its maximum value. This command is called RESET RETRY COUNTER. A certain security state must be achieved before this command can be executed. As a rule, this state is achieved by means of a successful authentication. Despite its name, this command can also be used to replace the current PIN with a new PIN. GSM includes two other commands that can be used to control PIN querying. They are DISABLE CHV and ENABLE CHV, which switch PIN verification off and on. If PIN verification is disabled, all file access restrictions that require prior PIN verification are disabled. Both of these commands are very popular in the mobile telecommunications area, since they eliminate the need to re-enter the PIN every time the mobile telephone is switched on. From a security perspective, these commands are questionable, since they disable protection against unauthorized use that is provided by the PIN. Of course, the user could also use CHANGE CHV to choose a trivial PIN, such as”0000”, which offers just as little protection. The ISO/IEC 7816-8 commands for these functions are called ENABLE VERIFICATION REQUIREMENT and DISABLE VERIFICATION REQUIREMENT. Depending on the application, a certain security state must be achieved before these commands can be executed. For obvious reasons, the PIN verification procedures described above are subject to attack, since a large financial gain could be realized using a lost or stolen card and the right PIN. All commands associated with PIN and PUK comparison must be protected against analysis of the card’s electrical or timing behavior. For instance, current consumption during the execution of VERIFY PIN must be constant, regardless of whether the entered PIN is correct. It is equally important for the time required to execute PIN commands to be independent of whether the PIN is correct. Varying execution times could have fatal consequences for the card’s security, and thus ultimately the security of the entire system. Such variations could be used to determine the value of the correct PIN in a very simple manner, causing all of the system’s PIN codes to be rendered worthless as a means of user identification.