Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-05-19
2003-03-18
Baderman, Scott (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C707S793000, C235S380000
Reexamination Certificate
active
06535997
ABSTRACT:
DESCRIPTION
1. Field of the Invention
The invention relates to data integrity in applications employing smartcards, in particular smartcards in connection with remote stations like personal or desktop card readers or similar inexpensive terminals. In such applications, unless properly handled, any interruption of a data transfer between the smartcard and a terminal can result in making the smartcard unusable and/or corrupt the data, any of which in turn often greatly affects the user.
2. Background
Smartcards today have many different uses of which the use in the financial and banking field is a prominent one. In this field, the data integrity issue is of particular importance since personal financial data are usually highly sensitive and a failing smartcard may, at times, present a significant problem.
Data integrity in the context here means error-free data transmission between a data source or receiver and the smartcard, an error-free record of the occurred transmission and consistent data on both sides giving an accurate, uncorrupted picture of the transaction that has occurred, whether completed or not. Data corruption may be caused by various events: a line breakdown to the terminal, a power failure, human interaction—e.g. someone removes the smartcard from a terminal—or even intentionally by a fraudulent attempt.
Whereas normal software techniques may guarantee the validity of the data content through secure messaging protocols and the appropriate realization in the smartcard, situations may occur where the traditional methods do not successfully work. One of the potential threats, as mentioned above, is the power loss situation. While the smartcard alters data in its memory, it may reach states where the data to be modified is lost, neither the old value nor the new value is available after the power loss. Furthermore the smartcard can be in a state where only a restricted functionality is available or, worst case, the card does not work at all. While there are other exposures to the card which may scratch the data, e.g. temperature exposure, mechanical break, electromagnetic radiation, the power loss situation, no matter whether by intent of the user or not, is the most probable threat which may occur.
From the field of database systems, different approaches to solve these problems are already known. Generally, a database (like a smartcard can be regarded as) has to “know” only two states which may be defined as before changes and after changes caused by a transaction. Any other situation must be avoided. Database technology has defined the terms commitment and atomicity in this respect. A data commitment is an external trigger which tells the database that the data being submitted is complete and therefore is relevant to change the content of the database. Atomicity describes the idea that only two states (before and after) can exist. If a database guarantees the atomicity of a transaction, then it has a technical functionality to guarantee only these two states. In the following, some of the techniques known today shall be described and some of the used terms explained.
Atomic Transactions
For a better understanding, the term atomic transaction shall be explained in some detail. An atomic transaction is any computerized transaction, e.g. banking or reservation transaction, that appears to be instantaneous and indivisible in the sense that it either runs to successful completion or completely fails, leaving no trace in any computer, as if it has never started. The concept was formulated to deal with transactions such as bank transfers, which involve multiple information updates, e.g. subtracting money from one account A and then adding it to another account B, yet should not be interrupted by failures of a computer or network, or by conflict with other transactions taking place in between the update operations. The main reason is that this could leave the affected database records in an inconsistent state, e.g. money debited from A but not credited to B or vice versa.
All existing database and transactions processing systems (e.g. IBM's DB2 database system as well as others) implement a variety of mechanisms for making such transactions atomic, i.e. for allowing to roll them back without a trace or to force them to a successful completion in spite of inevitable failures or conflicts. Known techniques as Write-Ahead Logs (WAL), Intention Lists (ILs), Commit Records (CRs), Two-Phase Commit Protocols (TPCP) in distributed systems, etc., are documented in any classical textbook on the subject, e.g. P. A. Janson: Operating Systems Structures and Mechanisms, Academic Press, Inc., London, 1985, pp.175 et seq. An earlier reference is by W. H. Kohler: A Survey of Techniques for Synchronization and Recovery in Decentralized Computer Systems, ACM Computing Surveys 13, Vol. 2, pp. 149-184.
Write Ahead Log
Here, data being modified is written into a buffer separate from the database, the Write Ahead Log. Beside the data, additional information is available in this log related to the correct address where the data has to be placed into. The log is marked invalid during this time. When the data modification is committed, the log will be marked valid. The data contained in the log is now written to the database. If all data was written out of the log, it is marked invalid again.
If a power failure occurs while data is written into the Write Ahead Log, the system will find the Buffer invalid and the data will remain at the same state as before, i.e. prior to the update.
If a power failure occurs when the Write Ahead Log is valid, then the whole Log or at least all entries which have not been assigned as written will be transferred to the database. Multiple power failures during this phase will never stop the update of the database until the final new state is reached. The database will, then end always in the committed and updated state.
Backtracking
Another method which is just the inverse of the Write Ahead Log, is the Backtracking method. Again, a separate buffer, the Backtrack Buffer, is used. However, data being modified is written directly to the database, after the “old” data has been written to the Backtrack Buffer. Using this method, each such “backup” entry has to be marked valid individually after it has been written; then the new data is written to the database. When the input data is committed, the Backtrack Buffer is declared invalid. All backup entries are then discarded.
The advantage of this method is that the new data is earlier available in the database and does not have to be locked until the data input is committed.
If the power fails while the Backtrack Buffer is being written, all valid entries of the Backtrack Buffer will be rewritten to the database in order to bring the database back to the “old” state. If the power fails while new data is written to any database location, the appropriate backup data will be tagged as valid. Therefore, the data location will be restored with the old backup data on the next power bring-up. The data base will also end up with the “old” state. If the power fails after the commitment, the backup buffer is declared invalid and the new data content will remain in the database.
Background System
Small data bases typically have a duplicated “shadow” of the actual database, e.g. RAID systems in a server environment. There, the Write Ahead or Backtrack Buffers are replaced by a full spare data base, which serves as spare in case of a disaster other than a power failure, e.g. in case of a head crash on fixed disks. There are several possible solutions to synchronize this shadow database with the master database. Generally it can be said that those approaches are not relevant to smartcards because of their limited memory size.
Vector Reference Swapping
A modified scheme of the above described Write Ahead or Backtrack Buffer techniques is the idea to use a “spare” entry in a database. A list might have a particular number of rows plus one spare row. Whenever new data comes in, it will be written to the spare location. After the dat
Janson Philippe A.
Scherzer Helmut
Baderman Scott
Herzberg Lewis
International Business Machines - Corporation
Tuchman Ido
LandOfFree
Data integrity in smartcard transactions does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Data integrity in smartcard transactions, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Data integrity in smartcard transactions will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3011543