Smart card chip operating system (COS) has traditionally been designed with no specific application in mind. However, there are some standard functions which are always required ex: card authentication, terminal authentication, card-holder authentication, read and update access, secured read and updated access etc which are required by every application. This type of COS can be group under the category called general purpose COS. When used as a banking card, monetary value is stored in a file (purse file) protected by update and read access. The read and update access, card & terminal authentication are controlled by secret keys inside the POS terminal. The entire system security relies on the fact that the terminal is trusted.

In a general purpose COS, purse file is debited by letting the POS reads the value, debit the amount to be debited and update back into the file. For security reason, the access to the purse files must be ciphered with a session key. From the security point of view, the rule of need-of-know basis must apply. The POS terminal only required to debit the purse file. However, a general purpose COS will allow update access by the terminal. Thus inherently, the terminal has both debit and credit capability.

Although the terminal is trusted only to perform the debit function, the security design requirements must be very high because if the keys are compromised in a POS terminal, someone may be able to perform credit function based on the secrets inside a POS terminal. A payment COS, besides having read and updated access control for data files must also have credit and debit access for purse files. Thus, a merchant POS terminal only required to debit a banking card only need to know the debit key. Even if the secret in the POS terminal is compromised, no one is able to create money fraudulently. This is a major difference between a general purpose COS and a payment COS.

In a banking application, there may be a requirement to cater for substitute debit during the case whereby goods are rejected (substitute with zero debit amount) or an data entry error by the cashier (substitute debit by another value). A general purpose COS will make use of read and update access to the purse file to implement the substitute debit function, thus having the same security problem. A good payment chip operating system should be able to support this function. It must be noted that a substitute debit is not a credit function and must not implemented like the credit function, ie there is not need to prove the knowledge of the credit key in order to perform this function. Rather, it should rely on the capability of the POS terminal to prove that it is the terminal that performs the previous transaction in order to perform a substitute debit function. Although the substitute debit function may be a very useful feature, the smart card can only ensure that there is a secured mechanism of performing the substitute debit function. The POS terminal and the back-end host are also required to perform the complementary functions to ensure that this feature is implemented securely.

Depending on the weighting of risk and flexibility needed by the issuer, the issuer should be able to select if the substitute debit function is to be totally disabled, to allow only during the current session with the card before the card is pulled-out or can be done any time before another transaction is performed. It must be noted that not all chip operating system that claims to be delegated for payment application is able to support this function.

By the law of physics, if updating of data into a medium is interrupted, the data is corrupted, regardless of whether it is a tape, a disk or a smart card. A general purpose COS and even some payment COS can only detect that the purse file is corrupted. However, a cleverly designed payment COS is able to change a purse file via a dual backup incremental changes of the current and previous balance to always ensure that even if the card is pulled out any time during the update, the balance is not corrupted.

In a banking application, it is very important for the card to not only prove to the terminal that the amount is indeed debited from the card via a Card Debit Certificate (CDC), but also it is done by a particular terminal.

Therefore,

CDC = f(debit amount, terminal certificate, debit key)

The terminal certificate should be unique to a particular terminal and for every transactions. A general purpose COS and even some payment delegated COS is not able to do this.

The POS terminal must verifies the CDC to ensure that the debit command to the card is not intercepted from the card and a fake CDC returned to trick the terminal. But requiring the POS terminal to verify the CDC implies that if the secrets in the terminal are exposed, there may be a potential security problem. In order to prevent this potential security problem, the card must be able to produce a Card Signature Certificate (CSC) to sign the debit transaction with a key not found in the POS terminal. A general purpose COS and even some payment delegated COS is not able to do this.

Credit function is the most sensitive operation in the whole system. There are claims that a single DES operation can be broken easily, if one has lots of money ( 1 million $), very good knowledge of cryptography, a good hardware and semi-conductor ASIC designer to design an application specific IC to perform a DES computation in one clock cycle and have many of such chip in parallel process. Potentially, a double DES may be broken in the future. Thus a triple DES is recognised to be safe even in the future by the experts. Thus, the credit function must require a double or triple DES computation.

SMART CARD CHIP OPERATING SYSTEM SELECTION
It is not the intention of this paper to do a product comparison but to look at the banking card system highest security requirements - what they are, why is it necessary and what is the possible implication if it is not done in the way specified. These should then served as the evaluation criteria to see if there is any smart card command to perform the function. There are many levels of security :

- a layman cannot break the security
- an information technology personnel cannot break the security
- the equipment suppliers cannot break the security
- the system application programmers cannot break the security
- the system designer himself break the security

Also, not all smart cards have the same security. Even if the best security smart card is chosen, the system must also be designed to exercise all security features provided by the smart card and there must not be any weak points in the entire system, of which the smart card is only a very small part but the entire system key management and security architecture relies on.

Eric Wilhem
Banking and systems designer
Security in Banking
Encryption Schemes