Tiêu chuẩn kỹ thuật của thẻ chứng minh nhân dân điện tử của Thailand

Chia sẻ: Monkey68 Monkey68 | Ngày: | Loại File: PDF | Số trang:80

0
88
lượt xem
15
download

Tiêu chuẩn kỹ thuật của thẻ chứng minh nhân dân điện tử của Thailand

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bản version 1.0, từ tài liệu này, dự án của Thailand đã triển khai năm 2004. Không biết đến khi nào chúng ta có CMND điện tử đây?

Chủ đề:
Lưu

Nội dung Text: Tiêu chuẩn kỹ thuật của thẻ chứng minh nhân dân điện tử của Thailand

  1. THAILAND Smart Card Standard Application Requirements Version 1.0 Thailand Smart Card Working Group 01 April 1999 Released Number: 1.1 Thailand Smart Card Standard Application Version 1.0 Page 1
  2. Thailand Smart Card Standard Application Requirements INDEX 1. Introduction ...........................................................................................................................4 1.1. Smart card Scheme Overview ..........................................................................................4 1.1.1. Scope .......................................................................................................................4 1.1.2. Scheme Structure......................................................................................................5 1.2. Smart card Requirements.................................................................................................8 1.2.1. Compliance Requirements.........................................................................................8 1.2.2. Data Elements and Files............................................................................................9 1.2.3. Standard Commands...............................................................................................10 1.3. Terminal Requirements..................................................................................................11 1.3.1. Terminal Types ......................................................................................................11 1.3.2. Terminal Capabilities..............................................................................................11 1.4. Application Requirements..............................................................................................12 1.4.1. Application Scope...................................................................................................12 1.4.2. Application Selection.............................................................................................13 1.4.3. Transaction Processing ...........................................................................................13 1.4.4. Data Integrity .........................................................................................................15 1.4.5. Year 2000 Support .................................................................................................15 1.5. Network Requirements ..................................................................................................16 1.6. Settlement and Clearing Requirements ...........................................................................17 2. Security Requirements.........................................................................................................18 2.1. Smart cards Delivery.....................................................................................................18 2.2. Symmetric Key Management .........................................................................................18 2.2.1. Symmetric Key Generation .....................................................................................18 2.2.2. Key Distribution.....................................................................................................19 2.2.3. Key Loading Process ..............................................................................................19 2.3. Asymmetric Key Management .......................................................................................19 2.3.1. Public Key Pairs Generation ...................................................................................19 2.3.2. Certification Authority............................................................................................20 2.4. Card Personalization .....................................................................................................20 2.4.1. Chip Personalization...............................................................................................20 2.4.2. Magnetic Stripe Encoding and Embossing...............................................................21 2.5. Post Personalization ......................................................................................................21 2.5.1. Files Access Conditions ..........................................................................................21 2.5.2. Files And Application Locking................................................................................22 2.5.3. Secret Code Protection............................................................................................22 2.6. Cryptographic Security Requirements ............................................................................22 2.6.1. Temporary Session Key Generation ........................................................................22 2.6.2. Card Authentication................................................................................................22 2.6.3. Cardholder Authentication ....................................................................................23 2.6.3. Secure Messaging...................................................................................................23 3. ID Card Application.............................................................................................................24 3.1. Functional Requirements ..............................................................................................24 3.2. Application Owner ........................................................................................................25 3.3. Data Requirements ........................................................................................................25 3.4. Card Surface Requirements ...........................................................................................26 3.5. Security Requirements...................................................................................................27 3.6. Application Transactions ...............................................................................................27 Thailand Smart Card Standard Application Version 1.0 Page 2
  3. 4. Credit/Debit Card Application..............................................................................................28 4.1. Functional Requirements ..............................................................................................28 4.2. Application Owner ........................................................................................................28 4.3. Data Requirements ........................................................................................................28 4.4. Card Surface Requirements ...........................................................................................29 4.5. Security Requirements...................................................................................................29 4.6. Application Transactions ...............................................................................................30 5. Electronic Purse Application ................................................................................................31 5.1. Functional Requirements ...............................................................................................31 5.2. Application Owner ........................................................................................................32 5.3 Data Requirements .........................................................................................................32 5.3. Card Surface Requirements ...........................................................................................33 5.4. Security Requirements...................................................................................................33 5.5. Application Transaction ................................................................................................34 6. Loyalty Application..............................................................................................................36 6.1. Functional Requirements ...............................................................................................36 6.2. Application Owner ........................................................................................................36 6.3. Data Requirements ........................................................................................................37 6.4. Card Surface Requirements ...........................................................................................38 6.5. Security Requirements...................................................................................................38 6.6. Application Transaction ................................................................................................38 7. Pilot Project .........................................................................................................................41 7.1. Producing specifications ................................................................................................41 7.2. Developing prototypes and conducting test .....................................................................41 7.3. Building system facilities and network ...........................................................................41 7.4. Conducting pilot run......................................................................................................41 7.5. Rolling out as commercial .............................................................................................42 7.6. Refining and evaluating achievement..............................................................................42 7.7. Ongoing operations for open-end ...................................................................................42 Appendix A - Terminal Types ..................................................................................................44 Appendix B - BER-TLV Data Object .......................................................................................45 B.1. Coding of BER-TLV Data Objects..............................................................................45 B.1.1 Coding of the Tag Field of BER-TLV Data Objects...............................................45 B.1.2 Coding of the Length Field of BER-TLV Data Objects ..........................................46 B.1.3 Coding of the Value Field of Data Objects.............................................................46 Appendix C – Transaction Message Format .............................................................................48 C.1. Credit Card Transaction Message Formats..................................................................49 C.2. Debit Card Transaction Message Formats ...................................................................59 C.3. Electronic Purse Transaction Message Format ...........................................................68 C.4. Loyalty Program Transaction Message Formats ..........................................................73 Appendix D - Normative References.........................................................................................78 Thailand Smart Card Standard Application Version 1.0 Page 3
  4. 1. Introduction 1.1. Smart card Scheme Overview 1.1.1. Scope Form a past decade smart cards are widespread popular solution in many parts of the world. A group of international card associations has developed the open standard smart card specifications for payment application and more applications in the future. The Thailand smart card working group was formed by the commencement of National Electronics and Computer Technology Center (NECTEC) to develop the smart card standard application requirements for Thailand. The primary purpose of Thailand smart card standard requirements is to ensure interoperability between products from different manufacturers and application venders. The standard requirements shall pave a way for all smart card players to build up a same application scheme and a same network that allow all parties sharing their benefits out of their terminals and networks. However the requirement is not mandated the interoperability between others different commercial applications. This requirement specification has objectives as following: • Ensure a common framework for all smart card application providers • Provide sufficient flexibility to accommodate interoperability of products from different manufacturers • Address industry-specific business practices • Offer opportunities to expand smart card markets and to leverage existing terminals, network and IT infrastructure The scope of functions is opened for one or more card applications to be co-exist on the same multi purpose smart card. The following are applications that are referenced in this specification: 1) ID Card Application 2) Credit/Debit Card Application 3) Electronic Purse Application 4) Loyalty Card Application There are key words expressed in these standards that tell you what is mandatory and what is optional. WILL or SHALL or SHOULD are mandatory while MAY is an optional term. The Thailand smart card working group is responsible to develop the preliminary standard application requirements for multi-purpose smart card. The smart card Scheme Provider or the application provider whose propose to implement the national standard smart card scheme should submit the technical details specification to the Thailand smart card committee before the implementation shall be commenced. The Thailand smart card working group reserves the right to amend or delete any part of this requirements specification or any document forming part of this specification in the future without Thailand Smart Card Standard Application Version 1.0 Page 4
  5. prior notice in order to have effect to the change of international standards, technologies, government policies or to correct any error, ambiguity that may arise. 1.1.2. Scheme Structure An open multi-purpose smart card scheme consists of the following seven participants: 1) Smart card Scheme Provider 2) Card Holder 3) Service Provider or Merchant 4) Card Issuer 5) Value Issuer 6) Value Acquirer 7) Clearing House A single entity may perform functions for two or more roles of the smart card scheme participants. In non-financial smart card schemes such as ID card, the application may perform fewer functions and fewer participants than that is shown in the figure 1. However there is no limited if more functions of other scheme applications shall be co-exist on the same multi-purpose card. Smart Card Scheme Relationships Fund Pool Scheme Issuer Issuer Provider Acquirer Acquirer Value Issuer Value Issuer Clearing House Clearing House Merchant Merchant / /Service Service Cardholder Cardholder provider provider (OHFWURQLF 9DOXH Figure 1 : Open Smart Card Scheme Participants Thailand Smart Card Standard Application Version 1.0 Page 5
  6. 1) Smart Card Scheme Provider The smart card scheme providers play a key role because they establish the smart card application scheme and guarantee the security and the valuable information contained within the system. The identifying characteristics of a smart card scheme provider are: • Develop the specifications, rules and conditions • Establish security procedures and keys management • Grant membership (certifies, authorizes and monitors) • Guarantees the trust of information or electronic value in the smart card system 2) Card Holder Card holders are consumers or people who use smart cards for storing information, identifying themselves or exchanging electronic value in cards with products and services from joining scheme participants. Cardholder activity can be off-line or on-line, traceable or anonymous depending on the function mechanisms used to implement a smart card application scheme. The identifying characteristics of cardholder are: • Valid to carry a card (certified by Card Issuer) • Abide by rules and condition of the card scheme • May or may not associate with institutions ownership • May have relationship with other scheme participants • May willing to keep money/points as electronic value in the smart card 3) Service Provider or Merchant Service providers or merchants exchange their information, products and services with the information and/or electronic value stored in cardholder’s smart cards. Service providers and merchants can be any individual establishments, e.g. municipal governments, telephone companies, transportation companies, retail merchants, fast food restaurants, convenience stores, vending machine etc. Smart card acceptance terminals are specially designed devices to meet functionality and purpose of usage applications. Such as, the payment acceptance terminal can transfer electronic value from cardholder’s smart card to store in a terminal. The identifying characteristics of service provider or merchant are: • Trusted and certified by Scheme Provider or Value Acquirer to access value in cards • Abide by rules and conditions of the smart card scheme • May or may not associate with institutions ownership • May accept cards from multiple issuers and • May have relationship with more than one scheme acquirers • May collected value with fund pools of Card Issuers through a Value Acquirer 4) Card Issuer Card issuers are participants granted by the smart card scheme provider to personalize, distribute the smart cards and operate the smart card system. The identifying characteristics of a Card Issuer are: • Authorized and quarantined by the scheme provider • Personalize and distribute cards to card holders • May incorporate additional functions in the card • May co-issue/later join with other scheme participants • Response to manage a database and/or a fund pool Thailand Smart Card Standard Application Version 1.0 Page 6
  7. 5) Value Issuer Value issuers are related with financial or commercial requirements. Value issuers are responsible for loading electronic value into smart cards. The value recharging function is performed through a special reload terminal ( or specially equipped ATM), which has a certain high degree of reliability and security. The identifying characteristics of value issuer are: • Authorized and certified by the Card Issuer • Load and update electronic value to the card • Perform only online by a trusted device and under a secured environment • May operate the device to accept bank notes or transfer value from bank account 6) Value Acquirer Value acquirers are related with financial or commercial requirements. Value acquirers are responsible for accepting electronic value from service provider and merchants and exchanging it for a credit to their deposit account. As concentrators, Value Acquirers collect service providers and merchant smart card transactions and forward them to the clearing house. Depending on the scheme operating regulations, Value acquirers may forward all of the details transaction data or just summary totals to the clearing house. The identifying characteristics of Value Acquirer are: • Authorized and certified by the scheme provider • Response to collect electronic value from merchant/service providers • Provide devices, terminal, network and manage black lists • Manage terminals and verify collected transactions • May forward all transactions to be exchanged at clearing house • May accept for more than one card issuers or more than one scheme participants 7) Clearing House The clearing house are related with financial and commercial requirements. The clearing house accommodate financial reconciliation system for fund transferring from Card Issuers to Value Acquirers. The amount transferred is equal to the accumulated electronic value collected by the Value Acquirers from Merchants and Service Providers and submitted to the clearing house. The identifying characteristics of clearing house are: • Authorized and certified by the scheme provider • Receive transactions batches from value acquirers • Response to reconcile and accommodate transferring funds from card issuers to value acquirers • May forward all details transactions from value acquirers to card issuers • Usually operate by a scheme provider or its sub-contractor Thailand Smart Card Standard Application Version 1.0 Page 7
  8. 1.2. Smart card Requirements 1.2.1. Compliance Requirements All smart cards shall comply with the following international standards: - ISO 7816 Part 1 : Physical characteristics - ISO 7816 Part 2 : IC contacts - ISO 7816 Part 3 : Electronic signals and transmission protocols - ISO 7816 Part 4 : Industry commands for interchange - ISO 7816 part 5 : Numbering system and registration procedure for application identifiers - EMV ICC Specification Part 1 : Electromechanical characteristics, logical interface, and transmission protocol - EMV ICC Specification Part 3 : Application selection - All relevant sections of ISO 10373 : Test methods The followings are additional requirements for cards to be used for financial transactions : - EMV ICC Specification Part 2 : Data elements and commands - EMV ICC Specification Part 4: Security aspects - ISO 7811 Part 1 : Recording technique – Embossing - ISO 7811 Part 2 : Recording technique – Magnetic stripe - ISO 7811 Part 3 : Recording technique – Location of embossed characters - ISO 7811 Part 4 : Recording technique – Location of magnetic read only tracks -Tracks 1and2 - ISO 7811 Part 5 : Recording technique – Location of read-write magnetic track – Track 3 - ISO 7812 Identification cards: Numbering System and Registration Procedure for Issuer Identifiers (1987) - ISO 7813 Identification cards: Magnetic stripe encoding Further more, smart cards may comply with the following international standards: - ISO 639 : Codes for the representation of names - ISO 3166 : Codes for the representation of languages and countries - ISO 4217 : Codes for the representation of currencies The physical mechanism of smart card should include the following hardware security features: • A fuse that disables access to the EEPROM manufacturing test mode. • A unique and unalterable serial number for each card to avoid cloning. • Power On reset for power supplies outside a specific range. • Diversified system key to protect the card during manufacturing and transportation to the card issuer. • Read and write access to EEPROM controlled by ROM software and issuer application • Read and write access to ROM prohibited. • Low voltage detection. • Low frequency detection. Thailand Smart Card Standard Application Version 1.0 Page 8
  9. 1.2.2. Data Elements and Files An application in the smart card includes a set of data information. These data information may be accessible to the terminal after a successful application selection. A data element is the smallest unit of data information in the smart card that may be identified by a name, a format, and a coding. 1.2.2.1 Data Objects Referring to the data object defining in EMV specification, a data object is formed in tag, length, value format (TLV). A tag, coding in hexadecimal number, uniquely identifies a data object within the environment of an application. The length is the number of byte of the data object. The value is content of the data object. A data object may consist either of a data element or of one or more data objects. A data object that encapsulates a data element is called a primitive data object. A data object that encapsulates more than one data elements is called a constructed data object. The mapping of data objects into records is left to the smart card application designed during the pilot project. The detail description of which data elements are to be used shall be comprised in the smart card application specification that will be submitted by the pilot issuers. Note: The data objects in TLV format is mandated for debit/credit application in order to be in line with EMV ICC specification. Other application's data objects to be found in this document are presented in TLV form. However, the implementation of TLV for applications, such as ID card, electronic purse and loyalty program are optional, the issuers may redefine data records in fixed format for a reason to save the smart card memory space. 1.2.2.2 Files The file structure, referencing method and level of security is based on the purpose of the file. The layout of the data files accessible from the smart card are left to the discretion of the pilot issuers except for the directory files described on the following: The smart card should support the file organization that complies with the basic file organizations as defined in ISO/IEC 7816-4, which has two types of file categories: • Dedicated file (DF) • Elementary file (EF) The data structure for an elementary file allows four options: • Linear Fixed • Linear variable • Cyclic • Transparent Master File(MF) is a dedicated file which is the root of the file structure as shown in figure 2. Thailand Smart Card Standard Application Version 1.0 Page 9
  10. MF DF DF EF EF EF EF EF EF EF Figure 2 : smart card File and Data structure The application selection of the standard applications should conform to the EMV ICC specification, the path to the set of applications in the smart card is gotten by selecting the Payment System Environment (PSE). See more in section 1.4.3.the application selection. Other applications conforming to ISO/IEC 7816-4 but not conforming to the EMV specification may also be present in the smart card as individual proprietary application. 1.2.3. Standard Commands 1.2.3.1 Message Structure The terminal and the card shall implement the physical data link, and transport layers as defined in ISO 7816 part 2 and 3. The command messages to be communicated between the terminal and the card should conform to the standard transmission protocol as defined in ISO 7816 part 3 and the standard instruction byte is defined in ISO/IEC 7816-4. The application protocol of the command message that sent from the terminal and the response message that returned by the card to the terminal shall be Application Protocol Data Units (APDU). The structure of the APDU command-response and command codes is defined in ISO 7816 part 3, part 4 and EMV ICC specification. All other commands may be defined as extended requirements by specific applications such as electronic purse and loyalty program. Thailand Smart Card Standard Application Version 1.0 Page 10
  11. 1.3. Terminal Requirements 1.3.1. Terminal Types In order to leverage capabilities and limitations of different kind of terminals in the market. The terminal requirements are more restricted to functionality, security and capability of terminal that meet with one or more functions of application than to mandate with all functions. The broad types of multi purposed terminals should be defined following to the EMV ICC terminal specification for payment system - Part 1 terminal types and capabilities. See more details of Terminal Types in Appendix A. 1.3.2. Terminal Capabilities Terminal type and terminal capability are pre-requisite decision criteria for determining the purpose of use and the functionality of each terminal. Smart card acquirers or venders who want to certify each kind of terminals with a standard smart card scheme should declare terminal capabilities in accordance with the EMV ICC terminal specification for payment system - Part 1 terminal types and capabilities. The capabilities of each terminal type need to be declared as follows: • General physical characteristics – describes all details of hardware specification, device components and hardware interfaces. • Software architecture – describes operating system architecture, data management and system operation. • Card data input capability – describes all the methods supported by the terminal for entering the information from the card into the terminal. • Cardholder Verification Method (CVM) capability - describes all the methods supported by the terminal for verifying the identity of the cardholder at the terminal. • Security capability – describes all the methods supported by the terminal for authenticating the card at the terminal and whether or not the terminal has the ability to capture a card. • Transaction type capability - describes all the types of transactions supported by the terminal. • Terminal data input capability - describes all the method supported by the terminal for entering transaction-related data into the terminal. • Terminal data output capability – describes the ability of the terminal to print or display messages. All terminal types suppose to provide adequate operation security. The terminal shall be constructed in such a way that: • Card Definition Table, Terminal Definition Table, Product Definition Table and other parameters are initialized in the terminal before the terminal ready in its operational state. • Terminal initialized parameters are set up in the terminal at the moment of installation. • All terminal parameters cannot be modified unintentionally or by unauthorized access. Thailand Smart Card Standard Application Version 1.0 Page 11
  12. 1.4. Application Requirements Application requirements address necessary functions to ensure that all smart cards can perform the set of common core functions in terminals. The common core functions for multiple smart card applications should be incorporated in the same way as functions and transaction processing flows declared in EMV ICC Application Specification Version 3.1.1, Visa ICC Specification Version 1.3.1 and Mastercard ICC Application Specification for Debit and Credit on Chip Version 1.0. Application functions unique to individual application and those functions not needed of interchange is left to discretion of application issuer to fulfill specific requirements that not effect the interoperability. 1.4.1. Application Scope The smart card applications referred in this document are means to support a number of current government and financial applications, such as: • National ID - besides a visual identification, an electronic identification opens access to government facilities and public networks • Taxation - enhances information on ID card to support personal taxation and duty payment • Welfare - enhances functionality to serve people getting welfare services • Driving License – enhances functionality to ID card, including a record of outstanding traffic violations to control enforcement • Medical – includes basic personal medical information to support diagnosis and treatment in emergency and general care situations • Debit – payment application provided by financial institution that is internationally accepted • Credit – payment application provided by financial institutions that is internationally accepted • Electronic Purse – a stored-value application that can be either anonymous or account linked • Loyalty – a value added application for the debit, credit, electronic purse or even cash application to enhance sales activity and give benefit to cardholders The smart card scheme provider who wants to implement a pilot program shall use this document as guidelines for developing a standard application specification. The full detail specification shall be submitted to Thailand smart card committee before the pilot project will be commenced. The detail specifications are supposed to meet the following commitments: • Openness – specifications shall incorporate open standards that allow future participants without incurring high development cost. • Upgradability – specifications should allow for future flexibility to provide all government applications and payment applications on the same card, if required. Specification should also accommodate installation of terminals that can run more than one application, if required. • Inter-operability – specifications shall be sufficiently detailed to ensure that different components (cards, acceptance terminals, etc.) developed by different venders will work together seamlessly. • Security – a well security designed specification and cryptographic procedures shall be incorporated to ensure that the security of the system is protected and preserved the privacy of the cardholder. • Expandability – specifications shall allow for additional government or private applications to be easily accommodated at a later date. Thailand Smart Card Standard Application Version 1.0 Page 12
  13. • Upward compatibility – hardware and software requirements shall be upgradable to ensure upward compatibility with evolving international standards. 1.4.2. Application Selection Application selection is always the first application function needed to perform. This application process shall be conformed to procedures defined in Part III of the EMV ICC Specification for Payment Systems. The domestic smart card scheme providers or card issuers shall get a Registered Application Provider Identifier (RID) of 5 bytes that are uniquely assigned conforming to ISO/IEC 7816-5 from the Thailand standard smart card committee. The foreign or the international smart card scheme provider that want to launch their program in Thailand may report their reserved RID to the Thailand standard smart card committee for the acknowledgement. A Proprietary Application Identifier Extension (PIX) of any 0-11 byte value can be assigned by the application provider to identify each of different applications. The following example: PIX is defined in 4 digits application ID and additional one or two digit is used to identify an individual released version of application as shown in table 1. PIX Card Type ‘0010X’ ID Card ‘1010X’ Credit Card ‘2010X’ Debit Card (No PIN) ‘3010X’ ATM/Debit Card (With PIN) ‘6010X’ Electronic Purse ‘9010X’ Loyalty Note : X is a number used to identify application released version, other applications that are not declared in the above table shall get the PIX number from Thailand smart card committee at later. Table 1 : Application PIX assignments The set of information that resides in smart card to support multiple applications shall be defined in an application definition file (ADF). Referring to a Part III of the EMV ICC Specification for Payment Systems, the ADF given the name ‘1PAY.SYS.DDF01’ shall be selected by the terminal using a select-by-name command. The terminal shall determine which applications are available to support by a smart card. The terminal should select the highest priority application, which terminal is eligible to process according to Application Priority Indicator designated by the issuer as a default application. To offer the cardholder the ability to select an application or confirm the selection, the terminal may list applications that supported by both card and terminal in priority sequence according to the card’s Application Priority Indicator if terminal support display screen and can offer the ability to confirm a selection. 1.4.3. Transaction Processing After application selection has taken place, the terminal shall perform transaction processing following to application function requirements. The transaction processing may be unique to individual smart card application, the detail processing is left to discretion of the application provider for a pilot program. The EMV ICC specification for payment system has given Thailand Smart Card Standard Application Version 1.0 Page 13
  14. guidelines to support the financial transactions on following paragraph. The more or less processed may be defined for suitable. There is also no restricted for other transaction types that may have differ processes to perform each individual application functions • Initial application processing – the first function terminal will perform after application selection • Read application data – terminal shall read the files and related records depending on the application function needed to perform from smart card • Data authentication – terminal shall design a sequence criteria for data authentication • Processing restrictions – terminal shall determine the processing restrictions according to the application being performed • Cardholder verification – terminal may perform cardholder verification which a cardholder is requested to enter PIN according to the cardholder verification rules • Terminal risk management – terminal risk management may be performed according to conditions and rules defined for each transaction scheme, such as the following checking : - Velocity checking (Optional) - if number of times exceed limited for offline transaction - Floor limit checking (Optional) - if number of accumulated amounts exceed a limit threshold value. - Random transaction selection (Optional) - if random number is less than or equal to the calculated transaction target percent. - Blacklist checking (Optional) - if card’s PAN is found in the black list PAN table • Terminal action analysis – this function may be performed after terminal risk management and cardholder has completed entering transaction data, terminal will make decision to reject the transaction, complete it online or complete it offline based on terminal verification results. • Card action analysis – this function may be performed to let smart card making a decision for approve the transaction offline, complete the transaction online, request a referral or reject the transaction. • Online processing – the terminal may generate online transaction message sending to host and receive transaction response back from host. • Script processing – Script processing may be provided to allow functions that may differ to each card manufacturers and are outside the scope of this specification. • Completion – this function shall be a last function to be done before transaction processing is completed. Thailand Smart Card Standard Application Version 1.0 Page 14
  15. 1.4.4. Data Integrity When an exceptional event occurs during normal transaction processing, such as sudden card withdrawal from the terminal’s card reader, sudden power supply micro-failure, etc., card exception procedures shall be implemented to protect the integrity of the application and related data. Strict integrity shall be ensured for the application software program, its data file structure, its security management parameters, and its static data elements (in other words, those data elements that are initialized during personalization and are not allowed to be updated after card issuance). This implies the information shall not be lost nor modified in case of exceptional events. Protection shall be ensured for the application data integrity. The protection mechanisms should be consistent when applied to all application data elements sharing the same memory cell. 1.4.5. Year 2000 Support The smart card application software and hardware should ensure their support for the Year 2000. The terminal vender should test the smart card acceptance terminal with the application software to certify that the product is Year 2000 compliant. A determination criteria of the application dates for Year 2000, in the four digit year format, year should support Year 2000 for both A.C.(After Christ Era) and B.E.(Budda Era). For example, February24, 2000 is expressed as 20000224 in YYYYMMDD format for A.C. and 25430224 in YYYYMMDD format for B.E. To support the year 2000 of the one- or two-digit year format, the international credit card association has currently specified the format of the specific date- related data element, the two-digit year that less than 50 are presumed Year 2000. For the last example, February24, 2000 is expressed as 0002 in YYMM format, 000224, in YYMMDD format, and 0055 in YDDD format. It is recommended that one- or two-digit year format is just implied for A.C.(After Christ Era). Thailand Smart Card Standard Application Version 1.0 Page 15
  16. 1.5. Network Requirements The network and communication infrastructure should meet the following requirements : • The network and communication equipment comply with present industrial standards • The network is constructed on a flexible and scaleable architecture that can support present and future network technologies • The system should provide high reliability and high availability to ensure minimum failure of service. The system should provide alternate communication channels or back up network channels to maintain availability of service during the normal channel is occupied or out of service • The network system should support all relevant existing and future network protocols for host systems, on-line terminals and off-line terminals. Protocols that are currently employed in financial and business network are ASYNC, BISYNC, X.25, SNA/SDLC, SNA/X.25, SDLC, APPN and TCP/IP • The network system should support data transmission through different networks and through use of high-speed data file transfer • The network system should support data switching of varying criteria parameters and in financial application, the system may need to support data reformat according to data format defined by each network processors • The network system should provide real time network management facility capable of monitoring links and devices, reporting errors and statistical data Thailand Smart Card Standard Application Version 1.0 Page 16
  17. 1.6. Settlement and Clearing Requirements The transaction settlement and clearing system is required for financial and payment transaction processing. The settlement and clearing service should support the following requirements: • The system shall be highly reliable and support 24 hour operations seven days a week • The hardware and software components shall be scalable and upgradable to meet future processing requirement • All transaction messages shall be based on ISO 8583 standard format • The system can receive and store messages from other acquiring hosts or direct from terminals • The system provides all functional capabilities to process all types of transactions • The system can authenticate, record and validate all received transactions • The system can perform transaction reconciliation and generate net clearing position at pre-set cut-off time • The system supports batch data information interchange to and from the member host processors • The system allows inquiry of member clearing position for participating members • The system provides all aspects of security and privacy controls required for the system • The system provides all necessary operational reports, management reports and audit trial For international chip-based credit/debit card support, the settlement and clearing system should comply with international chip-based credit/debit data and network processing requirements such as requirements by VisaNet and Mastercard Banknet. The credit/debit transaction shall be authenticated by chip-based credit/debit card authentication service and be cleared and settled under chip-based credit/debit operating rules. Thailand Smart Card Standard Application Version 1.0 Page 17
  18. 2. Security Requirements This part addresses the secured procedures for smart cards delivery, key management and card personalization of the smart card production life cycle to provide trace ability related to those entities that can impact the future reliability or authenticity of the smart card. Security is an important element in a smart card application. Smart card must sufficiently provide security at pre-personalization level and post-personalization level. 2.1. Smart cards Delivery The smart card manufacturer shall manage secure transportation of card from the card factory to the card issuer premises for personalization. Each smart card shall be initialized with a unique personalization key so that even when the personalization key for a particular card is compromised, the rest of the smart cards are not affected. Furthermore, the use of temporary key derived personalization key and card random number enhances the security of the smart card. The unique personalization key can be derived from a master key through some unique data pre- initialized into each smart card. The unique personalization key shall be delivered to the card issuer in secure protection, e.g. stored in a Batch Key Card with Personal Identification Number (PIN) protection. 2.2. Symmetric Key Management The key management system should be set up to allow the smart card Issuers to generate, store, transport and distribute all keys in a secure and controllable manner for a symmetric-key based smart card application. There may be different classes of keys that are defined in a system to allow key partitioning of the following key space: Shared Keys – allow all participants to use a same key for sharing their applications Private Specific Keys – specify for private used by application providers or card issuers Value Added Keys – specify added-on keys used by other related applications Administrative Keys – specify for system maintenance or system administration purpose The symmetric key management shall be comprised with the following sub-processes: 2.2.1. Symmetric Key Generation In the smart card production life cycle, Master key generation is a part to be given a highest level of security considerations in the card issuance process. Secret keys, which protect access to the smart card for each of applications, shall be generated and injected into the cards before and during the issuance process. Symmetric-Key generation is a process to generate all related Master key components, which are required for one or more applications in the smart card system. Each individual keys generated should be stored securely in separated keys cards. Symmetric-key generation should provide the following security aspects: Thailand Smart Card Standard Application Version 1.0 Page 18
  19. • The hardware/software should be stored and kept in secured places • The hardware/software access should be controlled by an access PIN control or any biometrics authentication techniques • The key generation should be done in a secured room environment • The Master keys are generated from secrets input by high level authorized holders and uses an algorithm to generate keys in a single pass, non parts or results of keys generated will be kept in computer or in any medium. These keys shall be loaded into the key cards, which address a different key space. This in turn shall allow the support for multiple issuer and multiple application cards system • The reading of the keys from these key cards is possible only upon successful presentation of PINs or any biometrics authentication techniques 2.2.2. Key Distribution The master key cards shall be kept securely by high level authorized holders. The key cards shall never be distributed to anyone directly but should be transferred to the relevant key injection cards for injecting into the final target environment. The target systems that will receive the keys may be the terminals, the host security modules, the card production system and other related systems. In the multiple smart card schemes environment, a proper management procedure should be built to manage keys combining and key distributing under secured environment for supporting multiple smart card issuers and acquirers. To prevent exposure of the keys, the injection cards should be able to establish an end-to-end cryptographic link with their target system. The keys should be transported to terminal in encrypted form. Beside that injection cards usage may be limited by number of cards/terminals that can be personalized. 2.2.3. Key Loading Process The key loading process may unique to each of target system. The card issuer and card acquirer shall conduct a proper operation procedure to make sure that all keys are loaded under a secured environment and well protected from security breech. The keys inside injection cards should be erased or destroyed after completed loading process or else the cards must be kept in a strong secured place for the next keys loading process. 2.3. Asymmetric Key Management For smart cards that will use for credit/debit card transaction should also be required to comply with international credit/debit card key management and cryptographic requirements referring in EMV ICC specification for Payment Systems. The smart card issuer shall use key management procedures and cryptographic services supporting by the appropriate Certification Authority. 2.3.1. Public Key Pairs Generation The credit/debit application is required public key cryptographic services. The use of static and dynamic data authentication had defined in the EMV ICC specification for Payment System that Thailand Smart Card Standard Application Version 1.0 Page 19
  20. the Issuer Public Key Certificates, smart card Public Key Certificates, card issuer public key pairs, smart card key pairs, and brand issuer public key pairs be generated and managed. 2.3.2. Certification Authority The use of public key pair requires the implementation of a Certification Authority. The Certification Authority provides public key cryptographic services for the initialization and support of smart card data authentication. The Certification Authority should function in a secure environment to ensure the security and integrity of all processes, keys, and related data. The cryptographic services provided by the Certification Authority are: • Generation of all public key pairs • Distribution of the public key to acquirers • Generation of Issuer Public Key Certificates • Perform all key management processes required to support the generation of Issuer Public Key Certificates • Administration of a Certificate Revocation List function for revoked Issuer Public Key Certificates 2.4. Card Personalization The card personalization may support batch card process that can handle for a small production volume or a mass production volume. The card production input data contains records of cardholder specific information, issuer specific information, application specific information and other card specific information. Graphical personalization, embossing, overlay, etc. can be included as part of the card personalization process depending on the requirements of the respective personalization modules. Card personalization system may include the following modules: • Chip personalization • Magnetic strip encoding • Card embossing and Topping • Indent printing • Card laminating The following briefly describes card personalization requirements for chip personalization, magnetic stripe encoding and embossing. 2.4.1. Chip Personalization The chip personalization is a process to write data into the chip volatile memory. Beside the data the Master Keys in keys injection cards is diversified and loaded into the smart card. The personalization may comprise a combination series of software and hardware process steps. The hardware can be any card production equipment completed with the required personalization modules, e.g. Electrical personalization module for chip personalization, printer module for graphical/text printing on card surface and/or embossing module for card embossing, etc. The certain system details are unique to each supplier. Thailand Smart Card Standard Application Version 1.0 Page 20
Đồng bộ tài khoản