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

Thailand Smart Card Standard Application Version 1.0 Page 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 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 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 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 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.
Figure 1 : Open Smart Card Scheme Participants
(OHFWURQLF
9DOXH
Smart Card Scheme Relationships
Cardholder
Cardholder
Merchant
/ Service
provider
Merchant
/ Service
provider
Acquirer
AcquirerIssuer
Issuer
Fund
Pool
Clearing House
Clearing House
Scheme
Provider
Value Issuer
Value Issuer
Thailand Smart Card Standard Application Version 1.0 Page 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 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 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 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 10
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.
MF
DF DF EF EF EF

EF EF EF EF
Thailand Smart Card Standard Application Version 1.0 Page 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 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 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 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 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 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 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 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 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 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 21
The fact that each smart card manufacturer uses the proprietary smart card operating system, a
different command set and proprietary memory structuring techniques. The individual smart card
personalization system may be required to handle each special personalization command set.
Smart card suppliers shall cooperate with smart card personalization equipment suppliers to
ensure personalization process is well established. After completed the first personalization,
some of the special smart card personalization commands set may be disabled or some of the re-
personalization protection keys may be established to prevent unauthorized and improper usage
that may impact smart card security and functionality. The restrictions of operation procedures
and cryptography techniques may be considered depending on the security requirements of each
smart card issuer.
In multi-application environments, the card issuer may need to develop re-issuance strategies to
ensure satisfaction of smart card security, functionality, and reliability requirements for the multi-
application, multi-function, and application data sharing environments.
2.4.2. Magnetic Stripe Encoding and Embossing
Smart cards for financial transactions may comply with current international card operating
regulations concerning visual personalization requirements. Smart cards for financial transactions
may have a magnetic stripe and embossing.
If the card is a multi-application card, the issuer shall select a default PAN to be encoded on the
magnetic stripe and embossed on the card. The default PAN encoded and embossed is identical to
that associated with the application with the highest priority for that card, as indicated by the
Application Priority Indicator. The cardholder data embossed on the card (PAN, expiration date)
shall be the same as the cardholder data encoded on the magnetic stripe.
2.5. Post Personalization
Post personalization security is very important as the cards are fielded. Smart card shall support
security features to protect the cardholder, card issuer, system operator, etc. from illegitimate
access the smart card.

2.5.1. Files Access Conditions
Each file in the smart card shall have its own set of dedicated file access conditions. This set of
access conditions defines the level of protection granted to a file (such as read, write, etc.).
During card access, the smart card shall determine if access should be allowed to a file by
checking against the access conditions stored for each file.
Possible access conditions may provide as following:
• One or more secret code numbers that should be used to access the file for each access
type (create, read, write or update).
• A cryptographic key may be used for secure messaging with the file. Secure messaging is
a cryptographic process that secures data transmission with smart card.
Thailand Smart Card Standard Application Version 1.0 Page 22
2.5.2. Files And Application Locking
To ensure that further access will be strictly disallowed to sensitive data area like secret keys and
secret codes, smart card should be able to bar all access to such data area once the secret keys and
secret codes and personalized. No even when the personalization key is presented.
Furthermore, in the case of multi-issuer where personalization key are usually shared, smart card
should be able to lock the access of any particular application in the card belonging to one issuer
that will not be able to interfere with the other.
2.5.3. Secret Code Protection
Smart card should be able to protect access to all files stored in the card with secret code. The
access conditions consists of presenting a secret code successfully to the card; it could be:
•
a PIN code entered by the card holder or by any biometrics authentication techniques
•
a secret code diversified by the terminal using a Master Secret Code
The PIN or personal biometrics allows the cardholder to authenticate by himself. Moreover, the
secret code may be presented enciphered to allow the terminal authentication by the card.
2.6. Cryptographic Security Requirements
Smart card may include a series of commands used to implement cryptographic session key,
cryptographic authentication, a certificate/signature generation, secure messaging, etc. The

command sets from different card manufacturers may vary but most cards can support the same
functionality of cryptographic mechanisms. The following addresses general cryptographic
requirements for the smart card security aspects:
2.6.1. Temporary Session Key Generation
To avoid any replay attack on the card/terminal, the card should be able to establish a unique
dialogue session with the terminal on each new transaction. To ensure that the session
establishment is unique, the smart card should support a random generator. Based on the
generation of random number, a unique temporary key can be established for every transaction.
Once a temporary key has been generated, the cryptographic security features can be used as
following:
•
verification of administration command transmission using secure messaging
•
Transaction dedicated security using cryptographic certificates
2.6.2.
Card Authentication
Card authentication is required before card access by terminals to be allowed. The authentication
shall be performed by the terminal to authenticate the card and may based on symmetric key
techniques or asymmetric key techniques depending on each smart card applications. This is to
ensure that the card is a genuine card before any transaction is allowed to carry out. Furthermore,
authentication should be performed in such a way that reflective attack by unauthorized terminals
Thailand Smart Card Standard Application Version 1.0 Page 23
and illegal cardholder will be denied. The card authentication may be a complement of the
following data authentication techniques:
• Secret code data authentication - symmetric key technique
• Static data authentication - asymmetric key technique
• Dynamic data authentication - asymmetric key technique
2.6.3. Cardholder Authentication
Cardholder authentication is performed by the cardholder to ensure that the terminal and
cardholder that is performing the transaction are legitimate entities. In typical, this can be done

through ciphered presentation of secret PIN.
There are some biometrics authentication techniques, which are more efficient and more accurate
than using of PIN such as eyes retina verification techniques, fingerprint verification techniques,
etc. The cardholder authentication using personal biometrics is optional. The PIN verification is a
minimum requirement.
The restriction for secret PIN authentication is as following:
• The terminal should cipher the PIN before presenting to smart card. The cardholder PIN shall
not be captured or leak out of the terminal
• The smart card should be able to decipher and verify the secret PIN internally.
• If a pre-defined number of incorrect presentation of the secret PIN is being done, the smart
card will disallow any further access to the card until the card is unlocked.
2.6.3. Secure Messaging
The principle objective of secure messaging is to ensure data confidentiality, message integrity
and issuer authentication. Secure messaging is process that allows data to be exchanged and to
prevent the transmission from being corrupted of being intercepted by a third party. The secure
messaging format should be conformed to ISO 7816-4.
Smart card may apply secure messaging on two purposes:
1) Secret Key / Secret Code Secure Messaging
The card and the terminal establish an end-to-end communication channel. Keys and data
interchange between card and terminal will be ciphered using the temporary session key.
2) Data Secure Messaging
The card and the terminal establish an end-to-end communication channel. Card or terminal may
use the temporary session key to calculate a cryptographic checksum for the data transmission.
The cryptographic checksum value will be counter checked the integrity of the data transmitted at
the other end.
Thailand Smart Card Standard Application Version 1.0 Page 24
3. ID Card Application
3.1. Functional Requirements
Thai citizens will get an ID card when they are full 15 years old. Thai citizens whose are
qualified and passed the driving test can hold a driving license. And when people work, they need

to have Tax ID and welfare ID. All of government's ID cards carry a same identity information
of the cardholder. This section describes preliminary requirements to combine all government
ID information into a single ID card. The card can append the information of other government's
ID card at later stages. For example, when a man get a driving license card, a card also has
medical information, ID card information and it can be used as an ID card. When this man get
Tax ID and Welfare ID, the Tax ID and Welfare ID information are updated into his card. The
fact that only data information can be updated to IC chip card but it does not allow any
information to be reprinted on the card surface. However, the next re-issuance of driving license
card after the present card expired shall present the Tax ID and Welfare ID on the new card
surface.
The details functional requirements of the ID applications are based on certain requirement of the
current government's ID cards such as citizen ID card, civil ID card, Tax ID card, Driving
License, etc.
The objective to integrate all government ID applications with multi-purpose smart card are as
following:
• To improve the security of the current government's ID cards through smart card and
biometrics technology
• To standardize data inter-change between all government ID applications and
government IT infrastructure for sharing of computer resources and network
resources
• To serve as an access key that uses the ID number to provide secured access to other
applications or other systems
The card applications that should support in the ID card application are as following:
• National ID – visual card surface can identify a person as well as stored individual
data information that can be used and shared with other government applications.
The ID card will also serve as access key to government public facilities and private
applications that do not required dedicated cards.
• Taxation – adding basic Tax information on ID card, a card can represent for Tax ID
card with the revenue department application.
• Welfare - adding related welfare information on ID card, a card can get health care

and other services from government and related hospital.
• Driving License – with separate issued by transport department, a card is included
information for ID card, taxation and welfare for referring identical to ID card.
Driving license card includes application to control and enforcement of traffic
violation and penalty payment.
• Medical – application contains basic medical information to improve diagnosis and
treatment in emergency and general care situations.
Thailand Smart Card Standard Application Version 1.0 Page 25
3.2. Application Owner
The government organizations that currently own, issue and utilize type of ID cards are as
following:
1) Registration Processing Center Administration Bureau, Ministry of Interior
2) Civil Service Commission, Ministry of Interior
3) Department of Land Transport, Ministry of Transport and Communications
4) Revenue Department, Ministry of Finance
5) Traffic Police Bureau, Highway Police Bureau, Provincial Police Bureau,
Information Center
3.3. Data Requirements
The mandate smart card reference information is defined in a constructed data object as shown in table 2:
Tag Length Value Format Presence
E1 8 Card Serial Number (CSN) 16 numeric char M
2 Issuer Code 4 numeric char M
2 Manufacturer Code 4 numeric char M
2 Card Type 4 numeric char M
1 Card Version 1 Character M
1 Derivation Key Index 1 Character M
4 Personalization Equipment Identifier 8 numeric char M
4 Personalization Date YYYYMMDD M
4 Application Expiration Date YYYYMMDD M
Table 2 : Common smart card Constructed Data Object

The data elements for ID card application are defined in TLV format as shown in the table 3:
Tag Length Value Format Presence
C1 1 Card Type
(e.g.1=citizen,2=civil,3=Driv)
1 Alpha num. M
C2 var. Name-Surname ‘;’ Name-Prefix/title 80 Characters M
C3 var. Organization Abbreviate 5-20 Characters O
C4 var. Registered Address 60 Characters M
C5 var. Current Address 60 Characters O
C6 var. Telephone no. 10 Alpha num. O
C7 var. Picture Bit map image O
C8 var. Signature Bit map image O
C9 var. Thumbprints Bit map image O
CA 4 Birth date YYYYMMDD M
CB var. Birth place 15 Characters M
CD 1 Marriage status 1 Characters M
CE 1 Gender 1 Characters M
CF 2 Blood Group 2 Characters M
D0 7 National ID number 13 numeric char M
D1 4 Driving License 8 numeric char C1