Security file system for a portable data carrier

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Technical Field

This invention relates to portable data carriers such as smart cards having electrical memories for storing data, and more particular to a system for securing the data contained in such portable data carriers.

2. Description of the Prior Art

The use of credit cards for purchases and for banking and other transactions has become so popular that most travelers today do so with very little cash. The card, typically made of plastic embossed with an account number and the name of the account owner, serves solely to identify an authorized account at a bank or credit house to be charged for a transaction. A magnetic stripe on the back of some cards contains the same information, but is machine-readable to speed the transaction. All accounting information is stored at the bank or credit house.

In that transactions generally occur at a location remote from the bank or credit house, it is easy for a person to use a misappropriated card, or for a legitimate owner to inadvertently exceed his credit limit. Most merchants, therefore, require that before purchases above a relatively modest amount such as $50.00 are completed, the authorization must be verified with the bank or credit house as appropriate. Even with automatic telephone dialing, the procedure is cumbersome and time-consuming. Furthermore, a separate card is needed for each account.

With the advent of recent advances in microelectronics, however, it is now possible to put a vast amount of computing power and memory right in the card to produce a "smart card" or "portable data carrier". The card could carry the account numbers of all of the owner's charge accounts, the balances of all of the accounts, the credit limits of all of the accounts and be updated locally with each transaction. The card could also carry other such personal data as, for example, the sizes of family members for clothing purchases, personal telephone directories, etc. The types of personal data are limited only by one's imagination.

The technology for putting all of this on the standard size card is here. What still remains, however, is the problem of providing suitable security for the data on the card. Such rules of security require authentication procedures that virtually eliminate fraudulent use.

SUMMARY OF THE INVENTION

In accordance with the invention, a high security portable data carrier or smart card typically the size of a standard plastic credit card may be used in a variety of applications, from custom repertory dialing to storage of individual medical and/or banking records. Although the card looks and feels much like an ordinary credit card, it includes a computer, an electrically erasable programmable read-only memory (EEPROM), and also circuitry for receiving a combined power and timing signal from a card reader/writer optionally located with an associated station. These card components and circuitry also receive and transmit data signals between the card and, via the reader/writer, the associated station.

A customer's personal information resides in multiple files in the EEPROM on the card. Appropriate application software residing in the station, when accompanied by an appropriate password, enables the retrieval and modification of these files. A separate password is required for gaining access to each of designated levels of interaction between the card and the associated station.

The card runs an executive operating system that is accessed from the station via a set of operating system command primitives. These command primitives manipulate the card file system in accordance with rules imposed to maintain card security. In so doing, direct access to the card file system and its commands are not allowed to the normal user.

In order to provide security protection for the card file system and the card commands, and yet allow for flexibility in handling different type of applications, the card employs six different security levels. These security levels enable the card to protect two types of resources: the card file system and the card commands. Access to these resources is a function of the authorized login level, the command requested and the file to be accessed. Additional restrictions such as requiring an additional password for writing/reading to a file and also allowing a user logged in at a particular security level to only append information to a file may be imposed in accordance with the rules of card file security. In addition, encryption of data as it is provided to the card from the station is also available for those very sensitive files or can be provided by the card. And since each of the files may have its own security requirements, multiple applications may exist on the card without conflict or confusion.

Another aspect of file security is the locking of the card. The security levels available to the normal user will lock after a specified number of unsuccessful attempts to log in at each one of those levels. Any level above the locked level, however, is able to unlock the card at the lower locked level. This permits a dispersal of card maintenance to the level just above the locked level.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention and its mode of operation will be more clearly understood from the following detailed description when read with the appended drawing in which:

FIG. 1 is a functional block representation of the major functional components of a portable data carrier system and their general interconnection with each other;

FIG. 2 is a table showing six security levels for which access is available to the portable data carrier employed in the system of FIG. 1;

FIG. 3 illustrates the file system for data contained in the portable data carrier which is segmented into two regions, the header and the data segment;

FIG. 4 illustrates the three sections of each file located in the data segment region of a portable data carrier system;

FIG. 5 illustrates the hierarchical structure of the Norma Security Class Levels which employ an optional password per file and an append-only feature;

FIG. 6 is a table showing command primitives used in communicating with the operating system on the portable data carrier;

FIG. 7 depict a flow chart illustrating a login sequence which aids in preventing unauthorized access to the portable, data carrier;

FIG. 8 shows the software hierarchy of the portable data carrier system arranged for operation in the protocol employed in the system;

FIG. 9 illustrates a message format suitable for use in communications between the major subsystems of the portable data carrier system;

FIG. 10 depicts a flow chart illustrating the link layer decision making process for operation of the application station in a half-duplex protocol; and

FIG. 11 depicts a flow chart illustrating the link layer decision making process for operation of both the reader/writer and the portable data carrier in a half-duplex protocol.

Throughout the drawings, the same elements when shown in more than one figure are designated by the same reference numerals.

DETAILED DESCRIPTION

With reference to FIG. 1, there is shown a portable data carrier (PDC) system which for ease of understanding may be divided into three subsystems. The first of these is a portable data carrier or card 10 which contains a memory capable of storing and updating information for a user. The second subsystem is a card reader/writer 15 which links the card with a station 18, the third subsystem. This last subsystem is a suitably configured application station which comprises a computer or dedicated workstation that runs application software necessary for accessing the memory in the card. The application software resides in the station and enables the retrieval and modification of information stored in the memory of the card 10.

The card 10 runs an executive operating system that is accessed via a set of operating system command primitives. These command primitives manipulate a file system on the card in accordance with rules required by card security.

Some of the principle components located in the card 10 are a microcomputer 110, an electrical erasable programmable read-only memory (EEPROM) 115, an analog interface circuit 130, the secondary winding 121 of a transformer 120, and capacitive plates 125 through 128.

The microcomputer 110 includes a central processing unit and memory units in the form of random-access memory and read-only memory. A microcomputer available from Intel Corporation as Part No. 80C51 may be used for microcomputer 110 with the proper programming. Operating under firmware control provided by its internal read-only memory, the microcomputer 110 formats data that is transferred directly to the EEPROM 115 and via the reader/writer 15 to the station 18. The entire EEPROM or a portion of it may be an integral part of the microcomputer, or it may be a separate element. The microcomputer 110 also interprets the command primitives from the station 18 received through the reader/writer 15.

By employing EEPROM 115 in the card 10, an authorized user has the ability to reprogram certain application files in the memory section of the card while at an authorized associated application station with new and different data as desired. EEPROMS are available from a number of suppliers, many of whom are mentioned in an article entitled "Are EEPROMS Finally Ready To Take Off?" by J. Robert Lineback, Electronics, Vol. 59, No. 7, (Feb. 17, 1986), pp. 40-41. Data may be written to and read or erased from an EEPROM repeatedly while operating power is being applied. When operating power is removed, any changes made to the data in the EEPROM remain and are retrievable whenever the card 10 is again powered.

The analog interface circuit 130 provides a means for interfacing the memory card 10 to the reader/writer 15. This interface performs a multitude of functions including providing operating power from magnetic energy coupled from the reader/writer 15 to the card 10, and also coupling data between the reader/writer 15 and the microcomputer 110 in the card 10. Power for operating the card 10 is provided to the analog interface circuit 130 via an inductive interface provided by the secondary winding 121 of a transformer 120. This transformer is formed when this secondary winding in the card 10 is mated to a primary winding 122 in the reader/writer 15. The station 18 provides the source of power for operation of both the reader/writer 15 and the card 10.

The transformer 120 may advantageously include a ferrite core 123 in the reader/writer for increased coupling between the transformer primary winding 122 and secondary winding 121. A second such core 124 may also be included in the transformer 120 and associated with the secondary winding 121 in the card for a further increase in coupling efficiency. In those arrangements where ample power is available and efficiency is not a consideration, one or both of these cores may be omitted. The use of a transformer for coupling power into a credit card was proposed by R. L Billings in U.S. Pat. No. 4,692,604 entitled "Flexible Inductor", issued on Sept. 8, 1987 and commonly assigned with this application to the same assignee.

Data reception to and transmission from the card 10 are provided by a capacitive interface connected to the analog interface 130. This capacitive interface comprises four capacitors formed when electrodes or plates 125 through 128 on the card 10 are mated with corresponding electrodes or plates 155 through 158 in the reader/writer 15. Two of these capacitors are used to transfer data to the card 10 from the reader/writer 15 and the remaining two are used to transfer data to the reader/writer 15 from the card 10. The combination of the inductive interface and the capacitive interface provides the complete communication interface between the reader/writer 15 and the memory card 10.

The organization of some of the components in the reader/writer 15 functionally mirror those in the card 10. Such components are, for example, an analog interface circuit 140 and a microcomputer 150. In addition, the reader/writer 15 also includes a power supply 162 and an input/output interface 160. The power supply 162 is used to provide power and also to couple a clock signal from the reader/writer 15 to the card 10 through the transformer 120. The input/output interface 160 is principally a universal asynchronous receiver transmitter (UART) and may be advantageously included in the microcomputer 150. This UART communicates with the application station 18, which could be an office editing station, factory editing station, issuer editing station, public telephone station or other suitably configured station.

The security concerns for the PDC system is divided into two broad areas. The first area is directed to aspects of identification and authentication, to insure that the station is both (1) communicating with an authentic card and (2) communicating with an authentic application file on the card. The second area is directed to controlling access to files on the card and limiting the exercise of card commands by an application at the station, an application being an account, or the like, which accesses specific data in a file on the card.

Without a suitable authentication procedure, those with the intent of defrauding the system might be able to simulate the protocol at the station thereby gaining information about the PDC system.

A method of insuring that the station is communicating with an authentic file on an authentic card is achieved by assigning each card a unique serial number and using this number, or subset thereof, along with a concealed application password residing in the station. These numbers are manipulated algorithmically to produce an authentication code which is stored in the application's file on the card at the time of creation. During subsequent transactions, this code must be favorably compared to a similar code generated independently by the station.

In order to provide security protection for the card file system and the card commands, and yet, allow for flexibility in handling different types of applications, the card employs six different security levels. These security levels enable the card to protect two types of resources: the card file system and the card commands. Access to any of these resources is a function of the authorized login level, the command requested, the file to be accessed, and such additional restrictions as are imposed by the owner of the card.

Referring now to FIG. 2, there is shown these six login security levels. The first four lower levels are placed in a Normal Security Class category and are available for use in a public environment. The first and lowest level in the hierarchical security level is a PUBLIC login level for general information and does not require a password for access. Medical information and insurance identification numbers or library card information are examples of public data that a person might want to include at this level. When the card is initialized on power-up or reset at a station, it comes up at the PUBLIC login level.

The second level is the USER level and requires a user's password for access. A user may have certain credit and debit accounts at this level. The third level is the SUB ISSUER level which also requires a password for access and is generally the level used in an application licensed by the MASTER ISSUER or the owner of the card.

The fourth level of security is that retained by the MASTER ISSUER. It is at this level that the card is formatted and from which it is issued. An example of how these levels may be utilized is as follows: a bank issues cards containing credit or debit accounts. This bank also licenses the use of its card to retail vendors who establish their own credit or debit accounts on the card. The bank in this example is the MASTER ISSUER and the vendors are SUB ISSUERS. The card holder, of course, is the USER. Each account in this example is handled by a separate file on the card and only persons or programs with the proper credentials for a particular file may access that file at an appropriate application station.

The two top security levels, DEVELOPER and SUPER USER are placed in an Extended Security Class category which permit the use of commands that are not available to the levels in the Normal Security Class category.

The fifth level or SUPER USER level is the factory which is responsible for construction, testing, and initializing blank cards in such a way that security is facilitated and misappropriated blank cards may not be used.

Finally the sixth and highest level is the developer level of the card. Both the SUPER USER and DEVELOPER security levels are capable of accessing the entire contents of the card file system including the card system header, to be discussed in greater detail later herein.

Since multiple files each with their own credentials exist on the card, multiple applications may respectively exist in these separate files without conflict or confusion. It is easy to visualize a person having 10 or more separate credit or debit accounts, an electronic checkbook, and a security pass for access to his apartment, all on the same card. The issuers as well as the user need have little fear of the consequences of misappropriation since the card requires a user to identify himself by means of a password before access to files other than those at the public level is permitted.

Referring now to FIG. 3, there is shown the card file system which is segmented into two regions, the header which is the administration portion and the data segment that contains the application files.

The high security header 35 contains information such as the card serial number, the passwords for each login level, the number of unsuccessful password attempts for each level, a lock byte for indicating login levels are locked, size of the fixed records in the database and memory size in kilobytes of the EEPROM 115. Direct access to the header section is available only to the two top security levels.

The data segment 30 of the card is divided into fixed records whose lengths of n bytes are set by the MASTER ISSUER. Each utilized record 31, 32, 33 is assigned to a particular file. Identification of the appropriate file is through the first byte of each record which is assigned that file's identification number.

The card has no file Directory and there are no pointers between the different records of the same file. File data order is indicated not by contiguous records but by linear order. The operating system of the card scans the address in the EEPROM from the lowest to the highest address. The first record located with a particular file identification number is the first record in that file, and the last record located with that file's identification number is the last record in that file. The card operating system reads the records of a file as each record in the particular file is encountered. The maximum size and number of files permitted on the card is limited only by the size of the memory in the EEPROM. A station's application software reading a file sees only a contiguous stream of bytes which is independent of the card internal file structure.

Referring next to FIG. 4, there is shown in greater detail the three sections of each file in the data segment region of a card file system. A prefix section 41 which is located in the first record of each file contains the file identification number 42 and protection bytes 43, 44 and 45. The file identification number is a number between between 1 and hex FE, inclusive. Hex number 00 and hex number FF are reserved for respectively indicating an unused record and the end of available memory in the EEPROM.

The protection bytes 43 through 45 specify the file permissions. The first byte 43 represents read permission designating the minimal level at which the file may be read, and the second byte 44 represents read/write permission designating the minimal level at which the file may be both read and written into.

Thus read permission for a file is separable from read/write permission for a file. Different security levels may also be specified for the read verses the read/write access. For example, the read permission for a file may be at PUBLIC level allowing public access to public information, but the write permission could be specified at USER level which prohibits writing to the file without the user's consent.

With reference briefly to FIG. 5, there is shown the hierarchical structure of the Normal Security Class levels which may employ optional passwords and an append-only feature. For increased flexibility in the use of the card, each file on the card may include in its protection bytes a requirement that an optional password be provided before allowing access to a particular file. This is in addition to the requirement that a user has to be at the required security level of the card's operating system for gaining access to a file protected to that level. Thus, by way of example, a file with read/write permissions for a user which includes an optional write password requires (1) logging into the card at user level and (2) opening the file in order to read it. To write to this file, however, the user must (1) log into the card at user level and (2) open the file for `write` by providing the optional password. This does not apply to a person logging in at a higher level than the access permissions of a file require. A person logging in at such a level may gain access to that file even though an optional password is required at the designated security level.

The hierarchical structure of the Normal Security Class levels is such that the MASTER ISSUER is able to read and write to any file at and beneath its level; the SUB ISSUER is able to read and write to any file at and beneath its level. Similarly, the card holder is able to read and write to any file at its level or the public level.

In an application where it is deemed appropriate, the protection byte 45 in FIG. 4 may be set to implement an `append-only` mode which permits the user to only add data to a file but not overwrite existing data. Records reflecting the appropriate application file are created for accepting this data as it is entered. Thus a file may be designated for read/append permission as well as read/write permission.

An information section 46 of a file contains the actual data located in each record of that file. And a suffix section 47 with a number M in the last byte 48 of the last record N indicates the number of application data bytes in that last record.

The executive operating system on the card is accessed by the Normal Security Class levels through use of the commonly understood command primitives shown in FIG. 6. These command primitives control the security access for the card, file creation and access and also administrative and testing activities. Additional command primitives are available for the SUPER USER or DEVELOPER login levels.

Operation of these command primitives may be illustrated through a description of the operation of the `login` command. In order to log into the card, the user is required to specify a login level and a password. This password is checked internally by the card algorithmically against the appropriate password at the same login level in the card header. If a card user is attempting to gain access to a file with a login level lower than that required by the file, permission to open the file either for read or for read/write is denied.

The passwords for each security level are placed in the card header when the card is manufactu