In the beginning, smart cards were used as identification media and thus represented typical single-user systems. However, the sophisticated security mechanisms and access mechanisms of multiapplication smart cards can certainly be used to configure and use smart cards as multiuser systems. Of course, the cost and effort involved should not be underestimated. The cryptographic protective mechanisms needed for this can also quickly reach a critical level of complexity. The situation here is similar to the situation with the various file structures. In principle, a record-oriented telephone directory can be constructed using a transparent file structure, but it is much easier to use a linear variable file structure. This is the basic reason why a subset of the database query language SQL (structured query language) has been standardized for use with smart cards in ISO/IEC 7816-7 and has been incorporated into the product range of various operating system producers. The subset of SQL for smart cards defined in the ISO/IEC 9075 standard is called ‘structured card query language’ (SCQL). The primary application area for smart cards with SCQL capability is health care, since in this area, a variety of persons and organizations must access data using several different read and write access privileges. However, there is presently no large application that utilizes SCQL. SCQL, like SQL, supports table-oriented database systems. Such systems consist of a table name, a fixed number of named columns and a variable number of rows. ‘Logical views’ can be applied to this table. If a view is static, this means that a certain number of columns are assigned to this view.Adynamic view, by contrast, is a selection of rows that satisfy a particular condition (e.g., given name = “Wolfgang”). Combinations of static and dynamic views are allowed. Each view has its own name and can be used as the basis for reading and writing data.

SCQL in smart cards requires an additional type of file structure, known as ‘database’, to be included in the operating system. A file with this structure is called a database file (DBF), and it is a database object that can be located directly below the MF or under a DF. It contains the data tables and associated system tables, and it can be addressed by database commands without first being selected. A DBF is a logical structure that may be distributed across several EFs, depending on the smart card operating system. Three system tables must be set up in the DBF to manage users and privileges. The first of these is the object description table, which stores information about the tables and their associated views. This table is complemented by the user description table, which is defined by the user of the database system. The third DBF table is the privilege description table, which defines the privileges of the individual users with regard to tables and views, as well as the operations they are allowed to perform on the tables and views. The operations that can be performed on an SCQL table or view are read, insert, write and delete, all of which are governed by access privileges. A cursor is defined for read and write operations in a table or view, in order to mark the row to which an operation will be applied. There are three basic SCQL commands: PERFORM SCQL OPERATION, PERFORM TRANSACTION OPERATION and PERFORM USER OPERATION. Only three instruction codes (INS) are needed for these, since the actual SCQL operations are initiated via parameter byte P2. All data in the command body and response body are TLV-coded data objects. The three commands are summarized in Tables 7.66, 7.67 and 7.68. Although SCQL has many limitations relative to SQL, such as no sorting, no nested queries, no joins and so on, it still has definite potential for use in the multiuser area. However, the memories of currently available microcontrollers are not yet large enough for extensive SCQL databases in smart cards. It may thus take a while until there is a major application that uses SCQL.

Part 3 of the European standard for universal electronic purses, EN 1546, defines six commands for electronic purses and 12 commands for the security module in the terminal, which itself may be a smart card. The basic structures of the four most important commands used with smart card electronic purses8 are described here. These commands can be utilized to run an application in a smart card for making ‘cashless’ payments from a prepaid purse and refilling the purse. The commands for error recovery, currency conversion, parameter modification and canceling a payment are not described here, nor are those for the security module. The Common European Purse System (CEPS) specification for electronic purses defines commands that are very similar to those defined by EN 1546. The commands described herewould fit just as well under ‘Application-Specific Commands’(Section 7.16), since they are defined specifically for this one application. They can never be used for any other purpose than electronic purses, since they have been optimized for this application. However, we dedicate a section to them because electronic purses are one of the main future applications for smart cards, besides telecommunications. All electronic purse transactions are divided into three steps according to EN 1546. In the first step, the card is initialized using the command INITIALIZE IEP for Load / for Purchase. In the second step, a command is executed to perform the actual transaction, such as filling the purse or paying with the purse. In the optional third step, the transaction just performed is confirmed. All purse commands directly access files in the purse application of the smart card for both writing and reading. These files hold the purse balance, log entries and various parameters. The individual steps of a purse transaction are executed using the commands described below. The EN 1546 standard precisely defines the internal processes of each command with regard to functionality and the sequence of the individual steps. All implementations thus have at least the same general processes. The INITIALIZE IEP command can be used for several purposes. A parameter is used to select initialization of a purse loading transaction, a purchase transaction or another type of transaction.

Loading (crediting) the purse in the smart card is initiated by the command INITIALIZE IEP for Load. The transferred data, such as a currency code and amount to be loaded, are checked in the card to see whether they match prescribed values in the parameter files. Freely definable data (user-determined data) can also be stored in a log file. Next, a transaction counter is incremented and a signature S1 is generated for various data (such as the current balance and expiry date), so that this information can be transferred to the terminal without risk of manipulation. In the second step of the load transaction, the card essentially receives information about the keys to be used and a signature S2 via the CREDIT IEP command. This information comes from the security module in the terminal, and besides command. After successfully testing S, the card increases the purse balance, makes a new entry in the log file and generates signature S3 for confirmation. This signature is then used by the security module in the terminal as confirmation of correct booking of the amount to be loaded.protecting the data, it allows the card to authenticate the security module. The smart card has already been authenticated with respect to the security module in the terminal by the previous INITIALIZE IEP for Load command. After successfully testing S2, the card increases the purse balance, makes a new entry in the log file and generates signature S3 for confirmation. This signature is then used by the security module in the terminal as confirmation of correct booking of the amount to be loaded. The second process consists of making a purchase using the electronic purse. This transaction is again initiated by the INITIALIZE IEP command, this time using the ‘for Purchase’option. The smart card does not receive any data with this command, but it does increment the transaction counter. Next, a signature S1 is generated for data such as the expiry date, transaction counter and IEP identifier. This information, which is protected for transmission by signature S1, is then sent to the terminal together with some additional data. The actual payment transaction is performed by the DEBIT IEP command. It sends information to the electronic purse in the smart card regarding the amount to be debited and current key versions, as well as another signature. This signature can be used to test the authenticity of the security module in the terminal in the same manner as for loading the purse. If this test is successful, the purse balance is decreased, the purchase transaction log is updated and another signature, S3, is generated to confirm the entire transaction. This signature is placed in the response to the DEBIT IEP command. It serves as confirmation to the security module in the terminal that the amount was properly debited in the smart card. Here we have only presented a brief summary of the four most important commands for electronic purses as specified in EN 1546. This standard is extremely comprehensive and includes many options and possibilities for system design, which naturally can affect the structures of the commands.