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

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

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

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

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

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

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

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

• 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

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

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

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

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

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

• 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

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