Smart card chip operating system (COS) has traditionally been designed with no specific application in mind. However, some standard functions are always required: 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 the update and read access. Secret keys inside the POS terminal control the read and update access, card & terminal authentication. The entire system security relies on the fact that the terminal is trusted.
In a general-purpose COS, the 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 reasons, 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 is 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.
READ MORE :
- Home Security System Basics
- Different Types of Card Games
- Tips For Stress Release Especially For Moms & Professionals
- Millennium Education Development
- Performance Mufflers and Exhaust Systems
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 perform the credit function based on the secrets inside a POS terminal. Besides having read and updated access control for data files, a payment COS must also have credit and debit access for purse files. Thus, a merchant POS terminal only required to debit a banking card only needs to know the debit key. Even if the secret in the POS terminal is compromised, no one can create money fraudulently. This is a major difference between a general-purpose COS and a payment COS.
There may be a requirement to cater for substitute debit in a banking application during the case whereby goods are rejected (substitute with zero debit amount) or a data entry error by the cashier (substitute debit by another value). A general-purpose COS will use reading 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 be implemented like the credit function, i.e., there is no need to prove the credit key’s knowledge to perform this function.
Rather, it should rely on the POS terminal’s capability to prove that it is the terminal that performs the previous transaction to perform a substitute debit function. Although the substitute debit function may be a handy feature, the smart card can only ensure a secured mechanism for performing the substitute debit function. The POS terminal and the back-end host must also 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 systems that claim to be delegated for payment application can 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 can change a purse file via a dual backup incremental changes of the current and previous balance to ensure that even if the card is pulled out any time during the update, the balance is not corrupted.
In a banking application, the card needs to prove to the terminal that the amount is indeed debited from the card via a Card Debt Certificate (CDC) and a particular terminal does it.
CDC = f(debit amount, terminal certificate, debit key)
The terminal certificate should be unique to a particular terminal and for every transaction. A general-purpose COS and even some payment delegated COS is not able to do this.
The POS terminal must verify the CDC to ensure that the card’s debit command 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 there may be a potential security problem if the secrets in the terminal are exposed. To prevent this potential security problem, the card must be able 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.
The 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 $), excellent 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 a parallel process. Potentially, a double DES may be broken in the future. Thus a triple DES is recognized 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 make a product comparison but to look at the banking card system’s highest security requirements – what they are, why it is necessary, and what is the possible implication if it is not done in the way specified. These should then serve as the evaluation criteria to see any smart card command to perform the function. There are many levels of security :
- a layperson 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 smart cards’ security features. There must not be any weak points in the entire system, of which the smart card is only a tiny part, but the entire system key management and security architecture rely on.