|
 |
|
 |
 |
|
|
|
|
|
|
|
|
http://www.ecommerce-guide.com/news/trends/article.php/400961
By Mark Merkow, CCP, CISSP June 22, 2000 As we continue the series on alternative payment systems, we now turn the attention to SmartCard-based systems like e-purses (e.g. MONDEX, Visa Cash, etc.) and credit and debit card applications such as the Europay, Mastercard, and Visa (EMV) standard. As we did with reviews of alternative systems that are based on the Secure Electronic Transaction (SET) protocol, we''ll start by building a foundation for understanding SmartCards before we begin reviewing specific application software that requires them. This column, the first in a series of three, will help you understand the technology -- and challenges -- associated with the uses of SmartCards for banking applications. SmartCards are complex devices that are best viewed as a series of layers or abstractions. In this first column of the series, we focus on introducing SmartCards, looking at them from the physical perspective, and seeing how they''re used. Just What Are SmartCards? SmartCard Memory
Permanent memory is generally ROM (Read Only Memory), placed in the chip hardware at manufacturing time. It can not be changed, although its operation can be blocked through logic operations. Programmable nonvolatile memory is generally EEPROM (Electrically Erasable Programmable Read Only Memory). It can be programmed after chip manufacture, exposing both its strength and its weakness. E-squared (as it''s affectionately called) permits making changes to programs, increasing the SmartCard''s flexibility but also exposing it to various types of nasty security attacks. Volatile memory is generally RAM (Random Access Memory), used as a temporary storage area for interim operations. It loses its contents when power is removed from the chip. SmartCard programming requires special skills since programs must be written using the smallest amount of memory possible. One major factor in understanding SmartCards is realizing the implications of when a program is added to what type of memory. If a program is added in ROM, it must be added when the basic chip is manufactured, and no changes can be made to it. If programs are added to EEPROM, they can be added both prior to issuance of the card or afterwards. SmartCard Processing Power Chip Families Soft Mask and Hard Mask Cards Banks commonly use a soft mask card for pilot testing new applications and then to move on to hard mask cards for larger deployments. However, some applications have limited deployments that are never taken to hard mask, as hard masking is expensive in both time and money. Hard masks also may not be justified for some applications, such as an employee identification card for small companies. Differentiating cards into soft or hard masks works well for single application cards, but is often confusing when there are multiple applications on the same chip. That is, a single card may have one application in ROM and thus be considered a hard mask card with respect to that application, but also have another application placed in EEPROM, and so it may be a soft mask card with respect to that application. Programming Languages In 2000, a new type of card has shown up, sometimes called a re-configurable card. These re-configurable SmartCards have a more robust operating system that permits the addition or deletion of application code after the card is issued. Such cards are generally programmed in Java, Windows for SmartCards, or MEL (the Multos programming language). These cards may have a card operating system and additional layers which offer industry or application specific features. The operating system must ensure that only authorized applications can be added after the card is issued to the cardholder and that deletions of applications are only done under proper authorization. These re-configurable cards use programming languages that are very well known in the software community, which is one of their advantages. Many programmers will be able to write SmartCard programs that will run on these operating systems, although the special skill of being able to write very memory efficient programs will be needed. Application Software For SmartCards
Each of these applications may have somewhat differing security requirements, security features, roles, and environmental considerations (e.g., whether they''re used always on-line, always used off-line, usually off-line with the capability of going on-line, etc.). The security requirements for the operating soft-ware, applications, and the procedures for adding or deleting those applications must therefore clearly be identified and the security functions that are present must be appropriate to the type and intended use of the card. Applications may range from very simple to very complex. For example, a loyalty application may be no more than an identifying code, such as a hotel or airline frequent user account code. Most of the information (preferences, total points, etc.) is stored on a mainframe computer somewhere; the card is only used to access the account accurately. The application becomes more complex as more of the information and processing is moved from the computer(s) on the network to the card, which may be desired so that activity can take place off line. Payment applications are often complex, since one of the main reasons for moving from magnetic stripe only uses to SmartCards permits off line transactions to be conducted more securely. In the next installment of the series we''ll examine SmartCards from the perspective of their life cycle -- from pre-personalization to disposal -- where functionality and security concerns constantly mutate. Mark Merkow is an E-commerce Security Specialist and technology author. His books include Building SET Applications for Secure Transactions, Thin Clients Clearly Explained, and Virtual Private Networks for Dummies. His latest book, The Complete Guide To Internet Security comes out in June 2000. Mark can be reached at mmerkow@internet.com |
|
|
