Intelligent card chip operating program (COS) has traditionally been developed with no specific application in mind. Nonetheless, 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 and so on which are needed by every single application. This kind of COS can be group under the category known as general purpose COS. When employed 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 whole system security relies on the reality 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 ought to be ciphered with a session key. From the security point of view, the rule of will need-of-know basis need to apply. The POS terminal only necessary to debit the purse file. However, a general purpose COS will enable update access by the terminal. Therefore inherently, the terminal has both debit and credit capability.
Although the terminal is trusted only to perform the debit function, the security design requirements ought to be really high since if the keys are compromised in a POS terminal, a person may possibly 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 information files need to also have credit and debit access for purse files. Therefore, 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 1 is able to develop money fraudulently. This is a major distinction between a general purpose COS and a payment COS.
In a banking application, there may be a requirement to cater for substitute debit throughout 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, therefore having the same security problem. A good payment chip operating system really should be able to support this function. It ought to be noted that a substitute debit is not a credit function and need to not implemented like the credit function, ie there is not require to prove the information of the credit key in order to perform this function. Rather, it need to 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 could be a quite helpful feature, the smart card can only make sure that there is a secured mechanism of performing the substitute debit function. The POS terminal and the back-end host are also necessary to perform the complementary functions to ensure that this feature is implemented securely.
Depending on the weighting of risk and flexibility necessary by the issuer, the issuer need to be able to pick if the substitute debit function is to be totally disabled, to enable only during the present session with the card just before the card is pulled-out or can be completed any time just before one more transaction is performed. It need to be noted that not all chip operating program that claims to be delegated for payment application is able to support this function.
By the law of physics, if updating of information into a medium is interrupted, the information is corrupted, regardless of 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. Nonetheless, a cleverly developed payment COS is able to alter a purse file via a dual backup incremental modifications of the present and prior balance to constantly make certain that even if the card is pulled out any time throughout the update, the balance is not corrupted.
In a banking application, it is really essential 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 performed by a certain terminal.
Consequently,
CDC = f(debit quantity, terminal certificate, debit key)
The terminal certificate really should be distinctive to a certain terminal and for every transactions. A general purpose COS and even some payment delegated COS is not able to do this.
The POS terminal should verifies the CDC to make certain 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 dilemma. In order to avoid this prospective security difficulty, the card must be able to generate a Card Signature Certificate (CSC) to sign the debit transaction with a key not identified 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 entire system. There are claims that a single DES operation can be broken simply, if one has lots of cash ( 1 million $), extremely great understanding of cryptography, a great hardware and semi-conductor ASIC designer to style an application specific IC to perform a DES computation in one clock cycle and have several of such chip in parallel method. Potentially, a double DES may be broken in the future. Thus a triple DES is recognised to be secure even in the future by the professionals. Therefore, the credit function need to call for a double or triple DES computation.
Intelligent CARD CHIP OPERATING Program Selection
It is not the intention of this paper to do a item comparison but to appear at the banking card system highest security requirements – what they are, why is it necessary and what is the feasible implication if it is not carried out in the way specified. These ought to then served as the evaluation criteria to see if there is any intelligent card command to perform the function. There are many levels of security :
- a layman cannot break the security
- an information technologies personnel can’t break the security
- the equipment suppliers cannot break the security
- the system application programmers cannot break the security
- the method designer himself break the security
Also, not all intelligent cards have the identical security. Even if the very best security intelligent card is chosen, the method need to also be designed to physical exercise all security functions provided by the intelligent card and there must not be any weak points in the entire method, of which the smart card is only a really small component but the whole system key management and security architecture relies on.
