kona2 d2320 user manual - armbusinessbank · this document contains a simple overview about the...

KONA2 D2320

User Manual

V1.00 (August, 2015)

All copyrights are reserved by KONA I Co., Ltd. This manual can be revised without any notification. Unauthorized copying is strictly prohibited by KONA I Co., Ltd without a written consent. © Copyright KONA I Co., Ltd. 2015

Revision History

KONA Java Card Product

No. Ver. Date Description of Change Chapter Writer

1 1.00 2015/08/20 Draft ALL Jin-seok, Heo

Seung-jin, Shin

KONA I Co.,Ltd 150-872, 8F EXCON Venture Tower, 3, Eunhaeng-Ro, Yeongdeungpo-Gu, Seoul, Korea. Tel: 82-2-2168-7500 Fax: 82-2-769-1670 Homepage: www.konai.com

http://www.konai.com/

Contents

1. Introduction ____________________________________________________________________________ 1

References _____________________________________________________________________________________ 1 1.1

Trademarks ____________________________________________________________________________________ 1 1.2

2. Product Brief ___________________________________________________________________________ 2

Block Diagram _________________________________________________________________________________ 2 2.1

3. Java Card Features _____________________________________________________________________ 3

Lifetime of the Java Card Virtual Machine ___________________________________________________ 3 3.1

Java Card Applet Lifetime _____________________________________________________________________ 3 3.2

3.2.1 Install Method __________________________________________________________________________________________ 3

3.2.2 Select Method _________________________________________________________________________________________ 3

3.2.3 Process Method ________________________________________________________________________________________ 4

3.2.4 Deselect Method _______________________________________________________________________________________ 4

Logical Channels and Applet Selection _______________________________________________________ 4 3.3

Transient Objects ______________________________________________________________________________ 5 3.4

Applet Isolation and Object Sharing _________________________________________________________ 5 3.5

3.5.1 Applet Firewall _________________________________________________________________________________________ 5

3.5.2 Object Access Across Contexts ________________________________________________________________________ 6

Transactions and Atomicity ___________________________________________________________________ 6 3.6

Security Features ______________________________________________________________________________ 7 3.7

Additional Features ____________________________________________________________________________ 9 3.8

3.8.1 CLA Format Parsing Methods _________________________________________________________________________ 9

3.8.2 Additional Status Words _______________________________________________________________________________ 9

3.8.3 isValidCLA ______________________________________________________________________________________________ 9

3.8.4 reSelectingApplet ______________________________________________________________________________________ 9

3.8.5 makeGlobalArray _______________________________________________________________________________________ 9

3.8.6 getAvailableMemory ___________________________________________________________________________________ 9

4. GlobalPlatform Features ______________________________________________________________ 10

Supported Features __________________________________________________________________________ 10 4.1

Issuer Security Domain _______________________________________________________________________ 10 4.2

4.2.1 Supported Commands _______________________________________________________________________________ 10

Supplementary Security Domain ____________________________________________________________ 13 4.3

Delegated Management (Optional)__________________________________________________________ 13 4.4

4.4.1 Tokens ________________________________________________________________________________________________ 13

4.4.2 Receipts _______________________________________________________________________________________________ 14

Authorized Management _____________________________________________________________________ 14 4.5

5. GlobalPlatform Card Mapping Guidelines ___________________________________________ 15

Security Domains _____________________________________________________________________________ 15 5.1

Recommended Privileges_____________________________________________________________________ 15 5.2

Recommended Application Programming Interfaces ______________________________________ 15 5.3

5.3.1 GlobalPlatform 2.2.1 __________________________________________________________________________________ 15

5.3.2 Java Card™ ___________________________________________________________________________________________ 16

Clarifications for Java Card™ and EMV _____________________________________________________ 18 5.4

6. COS Management Features ___________________________________________________________ 21

Changing the AID of ISD _____________________________________________________________________ 21 6.1

Read / Update Commands for KONA Proprietary Configuration __________________________ 21 6.2

6.2.1 Command for reading/changing protocol type _____________________________________________________ 21

6.2.2 Command for reading/updating ATR ________________________________________________________________ 22

6.2.3 Command for reading/changing the type of protocol T=CL _______________________________________ 23

6.2.4 Command for the option of 'Delegated Management' _____________________________________________ 24

6.2.5 Command for switching secure channel protocol mode ____________________________________________ 25

6.2.6 Disable Pre-Personalization functions (FUSE command) ____________________________________________ 25

7. Interface and Protocols _______________________________________________________________ 26

Supported Contact Protocols ________________________________________________________________ 26 7.1

7.1.1 Communication speeds ______________________________________________________________________________ 26

7.1.2 Answer to Reset (ATR), T=0 (Default) ______________________________________________________________ 26

7.1.1 Answer to Reset (ATR), T=1 __________________________________________________________________________ 26

Supported Contactless Protocol _____________________________________________________________ 27 7.2

7.2.1 Communication speeds ______________________________________________________________________________ 27

7.2.2 Answer to Select (ATS) _______________________________________________________________________________ 28

7.2.3 Restriction of FWI (Frame Waiting time Integer) ____________________________________________________ 28

8. Hardware Specification _______________________________________________________________ 29

9. Applets _________________________________________________________________________________ 30

VSDC 2.8.1 F1 _________________________________________________________________________________ 30 9.1

M/Chip 4 select _______________________________________________________________________________ 30 9.2

10. Caution in Implementation _________________________________________________________ 31

Security Guidelines _________________________________________________________________________ 31 10.1

10.1.1 Off-Card Verifier ___________________________________________________________________________________ 31

10.1.2 Security Counter ___________________________________________________________________________________ 31

10.1.3 API restrictions _____________________________________________________________________________________ 31

10.1.4 Security Countermeasures _________________________________________________________________________ 31

Information of Masked Java Card API Packages _________________________________________ 34 10.2

Protocol Parameters defined on ISO/EIC 14443 __________________________________________ 34 10.3

10.3.1 Restriction of FWI (Frame Waiting time Integer) __________________________________________________ 34

Secure Messaging defined on ISO/EIC 7816 ______________________________________________ 34 10.4

10.4.1 Channel ____________________________________________________________________________________________ 34

10.4.2 MANAGE CHANNEL Command ___________________________________________________________________ 34

Warning about the uninstalling of Applet ________________________________________________ 35 10.5

Confidential Ch.1 Introduction

© KONA I Co.,Ltd. All Rights Reserved. 1

1. Introduction This document contains a simple overview about the technical capabilities of KONA2 D2320, a member of the Kona card OS family.

References 1.1

[1] GlobalPlatform Card Specification Version 2.2.1 January 2011 [2] GlobalPlatform Card Mapping Guidelines of Existing GP v2.1.1 Implementation on v2.2.1 Version 1.0.1 January 2011 [2] Java Card 3.0.4 specification including JCRE, JCVM and JCAPI - Runtime Environment Specification, Java Card Platform, Classic Edition, Version 3.0.4 - Application Programming Interface, Java Card Platform, Classic Edition, Version 3.0.4 - Virtual Machine Specification, Java Card Platform, Classic Edition, Version 3.0.4

http://www.oracle.com/technetwork/java/javacard [3] ISO/IEC 7816, Information technology - Identification cards – Integrated circuits cards

– Part 3:cards with contacts – Electrical interface and transmission protocols, Nov 2006 [4] ISO/IEC 7816, Information technology - Identification cards – Integrated circuits(s) cards

– Part 4: Interindustry commands for interchange, September 1995 [5] ISO/IEC 14443, Identification cards – Contactless integrated circuits(s) cards – Proximity cards

– Part 2: Initialization and anticollision [6] ISO/IEC 14443, Identification cards – Contactless integrated circuits(s) cards – Proximity cards

– Part 4: Transmission protocol [7] JR/T 0025.4-2013, China Financial Integrated Circuit Card Specifications – Part 4: Debit/Credit

application overview [8] JR/T 0025.5-2013, China Financial Integrated Circuit Card Specifications – Part 5: Debit/Credit

application card specification [9] JR/T 0025.7-2013, China Financial Integrated Circuit Card Specifications – Part 7: Debit/Credit

application security specification [10] JR/T 0025.10-2013, China Financial Integrated Circuit Card Specifications – Part 10: Debit/Credit

card personalization guide [11] JR/T 0025.12-2013, China Financial Integrated Circuit Card Specifications – Part 12: Contactless

integrated circuit card payment specification [12] JR/T 0025.13-2013, China Financial Integrated Circuit Card Specifications – Part 13: Low-value

payment specification based on debit/credit application [13] JR/T 0025.14-2013, China Financial Integrated Circuit Card Specifications – Part 14:

Comprehensive application specification based on contactless low-value payment application [14] JR/T 0025.15-2013, China Financial Integrated Circuit Card Specifications – Part 15: Electronic cash dual-currency payment specification [15] Visa Smart Debit Credit(VSDC) 2.8.1 Applet Release Notes May 2011 [16] Visa Smart Debit Credit(VSDC) Technical Guide to Visa’s Applet for GlobalPlatform Cards March 2011 [17] PayPass – M/Chip Technical Specifications version 1.3 September 2005, MasterCard International. [18] EMV Integrated Circuit Card Specifications for Payment System 4.1, May 2004 [19] FIPS 186-2, Digital Signature Standard, Federal Information Processing Standards Publication 186-2, 2000. [20] SEC 2. Recommended Elliptic Curve domain Parameters. Standards for Efficient Cryptography Group, 2000 Working draft

Trademarks 1.2

ORACLE, Java, Java Card and Java Card S are trademarks of ORACLE, Inc.

中华人民共和国金融行业标准, China Financial Integrated Circuit Card Specifications. VSDC and PSE are trademarks of Visa International.

Ch.2 Product Brief Confidential

2 © KONA I Co.,Ltd. All Rights Reserved

2. Product Brief KONA2 is a "Java Card" implementation conforming to "Java Card 3.0.4 Specification" and "GlobalPlatform Card Specification 2.2.1". KONA2 D2320 is a KONA2 card implemented on "SAMSUNG" S3FT9MG smart card controller which has 320 Kbytes of FLASH.

Block Diagram 2.1

< Block Diagram of KONA2 D2320 Platform >

Confidential Ch.3 Java Card Features


3. Java Card Features

KONA2 D2320 supports all features of "Java Card 3.0.4" including Multiple Logical Channels and Garbage Collection.

Lifetime of the Java Card Virtual Machine 3.1

In Java Card technology the execution lifetime of the virtual machine (VM) is the lifetime of the card. When power is removed, the KONA2 D2320 VM only stops temporarily. When the card is next reset, the KONA2 D2320 VM starts up again and recovers its previous object heap from persistent storage.

Java Card Applet Lifetime 3.2

A Java Card RE implementation shall call an applet's install, select, deselect, and process methods. Applet of KONA2 D2320 is according to this life time.

The Method install The Method select The Method process The Method deselect

3.2.1 Install Method

The install method is the last step of applet installation to create an applet instance – a runnable applet – and typically is called by the JCRE. The registration of applet indicates the beginning of the applet's lifetime. For an applet to be selected and set to run by the JCRE, it must register with the JCRE. Otherwise, an applet can define a constructor that takes the installation parameters. The installation parameters provide additional data for initializing and personalizing the applet. If the return from the install method is successful, the applet is able to process the upcoming APDU. If a failure returns during the install method and before the register method is successfully invoked, the necessary cleanup for reclaiming the card resources when it gets back control is performed by JCRE.

3.2.2 Select Method

Until the applet is explicitly selected, it remains suspended. When the JCRE receives a SELECT APDU with the matching AID data of the applet, applet selection occurs. The JCRE informs the applet of its selection by invoking its select method. In the select method, the applet is able to confirm whether its selection conditions have been satisfied. If the condition has been met, it is able to set internal variables and states needed to handle subsequent APDUs. The applet returns trues from the call to the select method if it is set to receive incoming APDU by its process method. However, the applet returns false or throws exception to decline to be selected.

Ch.3 Java Card Features Confidential


3.2.3 Process Method

The process method of the current applet is called by the JCRE when APDU command is received. During the process method, an applet is expected to conduct the functions requested by APDU. When the APDU command is received, the requested function is executed by the decoded APDU header and service method called by the method. The JCRE encapsulates the APDU in the argument to the process method, apdu (an instance of the class APDU). The method on apdu object is invoked by the applet to receive and to return the APDU data.

3.2.4 Deselect Method

Prior to the new applet selection, deselect method is called by the JCRE to deactivate the current applet. During the deselect method, the applet is able to conduct cleanup operations needed for itself to go "off stage" and to prepare the execution of another applet. The default implementation in the class Applet is an empty method. The deselect method might fail. However, despite the result of executing the deselect method, the current applet is deselected and a new applet is selected. In addition, the applet is automatically deselected by the JCRE without its deselect method being evoked, when there is a reset or a power loss. Therefore, an applet cannot always rely on the cleanup operations in the deselect method.

Logical Channels and Applet Selection 3.3

Java Card platform provides support for logical channels: the ability to allow a terminal to open up to twenty sessions into the smart card, one session per logical channel. The Java Card platform allows the card implementer to designate a default applet instance for each of the logical channels supported by the card. Applets having the capability of being selected on multiple logical channels at the same time, or accepting other applets belonging to the same package being selected simultaneously, are referred to as multi-selectable applets. KONA2 D2320 supports two logical channels.



Transient Objects 3.4

Applets sometimes require objects that contain temporary (transient) data that need not be persistent across CAD(Card Acceptance Device) sessions. Java Card technology provides methods to create transient arrays with primitive components or references to Object. The contents of the fields of the object (except for the length field) have a transient nature. As with any other object in the Java programming language, transient objects within the Java Card platform exist as long as they are referenced from:

The stack Local variables A class static field A field in another existing

When a transient object is created, one of two events is specified that causes its fields to be cleared. Details of the two clear events are as follows:

CLEAR_ON_RESET : The object's fields (except for the length field) are cleared when the card is reset. When a card is powered on, this also causes a card reset.

CLEAR_ON_DESELECT : The object's fields (except for the length field) are cleared whenever the applet is deselected and no other applets from the same package are active on the card. Because a card reset implicitly deselects the currently selected applet, the fields of CLEAR_ON_DESELECT objects are also cleared by the same events specified for CLEAR_ON_RESET.

Transient Object can be created with JCSystem's method.

JCSystem.makeTransientBooleanArray() JCSystem.makeTransientByteArray() JCSystem.makeTransientShortArray() JCSystem.makeTransientObjectArray() JCSystem.makeGlobalArray()

KONA2 D2320 supports transient objects fully according to Java Card Platform Specification Version 3.0.4

Applet Isolation and Object Sharing 3.5

Any implementation of the Java Card RE shall support isolation of contexts and applets. Isolation means that one applet cannot access the fields or objects of an applet in another context unless the other applet explicitly provides an interface for access.

3.5.1 Applet Firewall

The applet firewall within Java Card technology is runtime-enforced protection and is separate from the Java technology protections. The Java language protections still apply to Java Card applets. The Java language ensures that strong typing and protection attributes are enforced. Applet firewalls are always enforced in the Java Card VM. They allow the VM to automatically perform additional security checks at runtime. KONA2 D2320 supports Applet Firewall fully according to Java Card Platform Specification Version 3.0.4



3.5.2 Object Access Across Contexts

The applet firewall confines applets actions to its designated context. To enable applets to interact with each other and with the Java Card RE, some well-defined yet secure mechanisms are provided so one context can access an object belonging to another context. These mechanisms are provided in the Java Card API and are discussed in the following sections:

Java Card RE Entry Point Objects Global Arrays Java Card RE Privileges Shareable Interfaces

KONA2 D2320 supports Object Access Across Contexts fully according to Java Card Platform Specification Version 3.0.4

Transactions and Atomicity 3.6

A transaction is a logical set of updates of persistent data. The Java Card RE provides robust support for atomic transactions, so that card data is restored to its original pre-transaction state if the transaction does not complete normally. This mechanism protects against events such as power loss in the middle of a transaction, and against program errors that might cause data corruption should all steps of a transaction not complete normally. KONA2 D2320 supports Transactions and Atomicity fully according to Java Card Platform Specification Version 3.0.4 and the size of Transaction Buffer is 1788 Bytes.



Security Features 3.7

KONA2 D2230 supports a subset of javacard.security package in Java Card Platform Specification Version 3.0.4

< Ciphers via JAVA CARD API >

Algorithm KONA2 D2320 Note ALG_DES_CBC_NOPAD

ALG_DES_CBC_ISO9797_M1

ALG_DES_CBC_ISO9797_M2

ALG_DES_CBC_PKCS5

ALG_DES_ECB_NOPAD

ALG_DES_ECB_ISO9797_M1

ALG_DES_ECB_ISO9797_M2

ALG_DES_ECB_PKCS5

Supported

ALG_AES_BLOCK_128_CBC_NOPAD

ALG_AES_BLOCK_128_ECB_NOPAD Supported

ALG_RSA_NOPAD

ALG_RSA_PKCS1 Supported

< Signatures via JAVA CARD API >

Algorithm KONA2 D2320 Note ALG_DES_MAC4_NOPAD

ALG_DES_MAC4_ISO9797_1_M1_ALG3


ALG_DES_MAC4_ISO9797_M1


ALG_DES_MAC4_PKCS5

ALG_DES_MAC8_NOPAD




ALG_DES_MAC8_PKCS5

Supported

ALG_RSA_MD5_RFC2409

ALG_RSA_SHA_RFC2409

ALG_RSA_MD5_PKCS1

ALG_RSA_SHA_PKCS1

ALG_RSA_SHA_224_PKCS1

ALG_RSA_SHA_256_PKCS1

ALG_RSA_SHA_ISO9796

Supported

ALG_AES_MAC_128_NOPAD Supported

< Message Digest via JAVA CARD API >

Algorithm KONA2 D2320 Note ALG_MD5

ALG_SHA1

ALG_SHA_224

ALG_SHA_256

Supported



< Key Builder via JAVA CARD API >

Key type KONA2 D2320 Note TYPE_DES

TYPE_DES_TRANSIENT_DESELECT

TYPE_DES_TRANSIENT_RESET

< Supported DES Key Length >

-. LENGTH_DES

-. LENGTH_DES3_2KEY

-. LENGTH_DES3_3KEY

Supported

TYPE_AES

TYPE_AES_TRANSIENT_DESELECT

TYPE_AES_TRANSIENT_RESET

<Supported AES Key Length>

-. LENGTH_AES_128

-. LENGTH_AES_192

-. LEGNTH_AES_256

Supported

TYPE_RSA_PUBLIC

TYPE_RSA_PRIVATE

TYPE_RSA_CRT_PRIVATE

< Supported RSA Key Length >

-. RSA key length that is a multiple of 32 bits

between 512 bits and 2048 bits

Supported

< RSA Key Generation via JAVA CARD API >

Key type KONA2 D2320 Note ALG_RSA (up to 2048 bits)

ALG_RSA_CRT (up to 2048 bits)

< Supported RSA Key Length >

-. RSA key length that is a multiple of 32 bits

between 512 bits and 2048 bits

Supported

< Random Number Generation via JAVA CARD API >

Key type KONA2 D2320 Note ALG_PSEUDO_RANDOM

ALG_SECURE_RANDOM Supported



Additional Features 3.8

3.8.1 CLA Format Parsing Methods

3.8.1.1 isISOinterindustryCLA

This method returns whether the current APDU command CLA byte corresponds to an interindustry command as defined in ISO 7816-4:2005 specification. It returns true if this APDU CLA byte corresponds to an interindustry command, and false otherwise.

3.8.1.2 isCommandChainingCLA

This method returns whether the current APDU command is the first or part of a command chain. Bit b5 of the CLA byte if set, indicates that the APDU is the first or part of a chain of commands. See Runtime Environment Specification for the Java Card Platform, section 4.3 for encoding details. It returns true if this APDU is not the last APDU of a command chain, and false otherwise.

3.8.1.3 isSecureMessagingCLA

This method returns true if the encoding of the current APDU command based on the CLA byte indicates secure messaging. The secure messaging information is in bits (b4,b3) for commands with origin channel numbers 0-3, and in bit b6 for origin channel numbers 4-19. See Runtime Environment Specification for the Java Card Platform, section 4.3 for encoding details. It returns true if the secure messaging bit(s) is(are) nonzero, false otherwise.

3.8.2 Additional Status Words

(To support ISO7816-4:2005 defined command chaining) SW_LAST_COMMAND_EXPECTED SW_COMMAND_CHAINING_NOT_SUPPORTED

3.8.3 isValidCLA

This method returns whether the current APDU command CLA byte is valid. The CLA byte is invalid if the CLA bits (b8,b7,b6) is %b001, which is a CLA encoding reserved for future use(RFU), or if CLA is 0xFF which is an invalid value as defined in the ISO 7816-4:2005 specification. (See Runtime Environment Specification, Java Card Platform, Classic Edition, section 4.3 for encoding details.)

3.8.4 reSelectingApplet

This method is used by the applet's process() method or the select() method or applet's deselect() method to determine if it itself is being re-selected on this logical channel.

3.8.5 makeGlobalArray

This method creates a global CLEAR_ON_RESET transient array of the type specified, with the specified array length. A global array can be accessed from any applet context. References to global arrays cannot be stored in class variables or instance variables or array components. (See Runtime Environment Specification, Java Card Platform, Classic Edition, section 6.2.2 for details)

3.8.6 getAvailableMemory

This method obtains the amount of memory of the specified type that is available to the applet. Note that implementation-dependent memory overhead structures may also use the same memory pool. The requested memory information is returned as a 32 bit number stored in the specified short array - buffer. The 32 bit number is the concatenation of buffer[offset] and buffer[offset+1].

Ch.4 GlobalPlatform Features Confidential


4. GlobalPlatform Features

KONA2 D2320 supports these features implementation specified in "GlobalPlatform Card Specification 2.2.1".

Supported Features 4.1

KONA2 D2320 supports the following features. Public key DAP Verification (RSA and DES) Mandated DAP Verification (RSA and DES) SCP02 with implementation option '55' (Default SCP)

- Initiation mode explicit - C-MAC on modified APDU - ICV set to zero - ICV encryption for C-MAC session - 3 Secure Channel Keys

SCP01 with implementation option '05' (Optional feature by being deprecated) - This feature was deprecated at GlobalPlatform Card Specification v2.2, - GlobalPlatform Card Specification v2.2 recommends another SCP, like as SCP02. - Initiation mode explicit - C-MAC on modified APDU - ICV set to zero - no ICV encryption - 3 Secure Channel Key

Global PIN via CVM interface Deprecated API of Open Platform 2.0.1 Delegated Management

- Optional feature. The availability of this optional feature is at the discretion of the issuer.

Authorized Management Trusted Path privilege not support Card life cycle

- OP_READY - INITIALIZED - SECURED - CARD_LOCKED - TERMINATED

Delete Key functionality

Issuer Security Domain 4.2

KONA2 D2320 has Issuer Security Domain applet. Capabilities of the Issuer Security Domain are described in this section.

Issuer Security Domain Issuer Security Domain (hereinafter referred to as "ISD") is an applet that is used to manage a card. The ISD is implemented based on the GlobalPlatform Card Specification 2.2.1 The AID of the ISD is "0xA0 0x00 0x00 0x00 0x03 0x00 0x00 0x00" based on the ISO assign-ed RID which is defined by ISO/IEC 7816-5.

4.2.1 Supported Commands

Commands supported by the ISD of KONA2 D2320 are as follows. DELETE INSTALL LOAD INITIALIZE UPDATE

Confidential Ch.4 GlobalPlatform Features


EXTERNAL AUTHENTICATE PUT KEY STORE DATA GET DATA GET STATUS SET STATUS DELETE KEY

The detailed information for the commands is described in this section.

4.2.1.1 DELETE

A DELETE command is used by the ISD only to delete an Application or an Executable Load File. It cannot be used to delete packages required for the operation of an GlobalPlatform Java Card i.e. it shall not be possible to delete the GlobalPlatform API or Java Card API packages immaterial of whether these are present in the GlobalPlatform Registry. The DELETE command may only be issued within a Secure Channel Session and the level of security for the command is dependent on the security level defined in the EXTERNAL AUTHENTICATE command. KONA2 D2320 does not support deletion of key. If TLV tag in command message is not '0x4F', indicating AID, card returns 0x6A80. Please see the document of 'GlobalPlatform Card Specification 2.2.1' for more details.

4.2.1.2 INSTALL

The INSTALL command is used to inform the ISD of the various steps required to load application code and to install and make an Application selectable. The INSTALL command may only be issued within a Secure Channel Session and the level of security for the command is dependent on the security level defined in the EXTERNAL AUTHENTICATE command. Please see the document of 'GlobalPlatform Card Specification 2.2.1' for more details.

4.2.1.3 INITIALIZE UPDATE

The INITIALIZE UPDATE command is used to exchange Secure Channel Session data between thez card and the host. This data facilitates the generation of the session keys used for the duration of the Secure Channel Session. The INITIALIZE UPDATE command shall only be successfully processed if no Secure Channel Session is currently active or if the Secure Channel Session is active on the same logical channel that this command is being issued on. All the requirements specified in GlobalPlatform Card Specification 2.2.1 are implemented.

4.2.1.4 EXTERNAL AUTHENTICATE

The EXTERNAL AUTHENTICATE command is used by a Security Domain to authenticate the host and to determine the level of security required for all subsequent commands. A previous and successful execution of the INITIALIZE UPDATE command is necessary prior to processing this command. All the requirements specified in GlobalPlatform Card Specification 2.2.1 are implemented.



4.2.1.5 PUT KEY

The PUT KEY command is used to either: Replace an existing key with a new key: The new key has the same or a different Key Version

Number but the same Key Identifier as the key being replaced; Replace multiple existing keys with new keys: The new keys have the same or a different Key

Version Add a single new key: The new key has a different combination Key Identifier / Key Version

Number than that of the existing keys; Add multiple new keys: The new keys have different combinations of Key Identifiers / Key Version

When the key management operation requires multiple PUT KEY commands, chaining of the multiple PUT KEY commands is recommended to ensure integrity of the operation. In this version of the Specification the public values of asymmetric keys are presented in clear text. Please see the document of 'GlobalPlatform Card Specification Version 2.2.1' for more details.

4.2.1.6 STORE DATA

The STORE DATA command is used to transfer data to an Application or the Security Domain processing the command. The Security Domain determines if the command is intended for itself or an Application depending on a previously received command. If a preceding command was an INSTALL [for personalize] command, the STORE DATA command is destined for an Application. Multiple STORE DATA commands transfer data to the Application or Security Domain by breaking the data into smaller components for transmission. Each STORE DATA command is numbered starting at '00'. The STORE DATA command numbering shall be strictly sequential and increments by one. The Security Domain shall be informed of the last block. Please see the document of 'GlobalPlatform Card Specification Version 2.2.1' for more details.

4.2.1.7 GET DATA

The GET DATA command is used to retrieve either a single data object, which may be constructed, or a set of data objects. Reference control parameters P1 and P2 coding is used to define the specific data object tag. The data object may contain information pertaining to a key. Please see the document of 'GlobalPlatform Card Specification Version 2.2.1' for more details.

4.2.1.8 GET STATUS

The GET STATUS command is used to retrieve Issuer Security Domain, Executable Load File, Executable Module, Application or Security Domain Life Cycle status information according to a given match/search criteria. Please see the document of 'GlobalPlatform Card Specification Version 2.2.1' for more details.

4.2.1.9 SET STATUS

The SET STATUS command shall be used to modify the card Life Cycle State or the Application Life Cycle State. Please see the document of 'GlobalPlatform Card Specification Version 2.2.1' for more details.

Confidential Ch.4 GlobalPlatform Features


4.2.1.10 DELETE KEY

KONA2 D2320 does not support DELETE KEY command.

Supplementary Security Domain 4.3

Supplementary Security Domain (hereinafter referred to as "SSD") is an applet that is used to manage a card but has limited capability comparing to ISD. The SSD is implemented based on the GlobalPlatform Card specification 2.2.1 The package ID of the SSD is "0xA0 0x00 0x00 0x01 0x51 0x53 0x50" and needs to be installed in order to use SSD. SSD supports following commands.

INITIALIZED UPDATE EXTERNAL AUTHENTICATION PUT KEY STORE DATA GET DATA

For any options of commands, KONA2 D2320 implementation conforms to the GlobalPlatform Card specification 2.2.1.

Delegated Management (Optional) 4.4

GlobalPlatform is designed for providing maximum flexibility to the Card Issuer and its business partners regarding Card Content management while ensuring that the Card Issuer keeps control over the Card Content present on the card. Delegated Management provides this capability so that a Card Issuer can provide an Application Provider the capability to perform specific Card Content management. Cryptographic security is required for Delegated Management and the Issuer Security Domain requires the knowledge of keys and algorithms used for Tokens and optionally for Receipts. Delegated Management is a privilege that a Security Domain(DMSD) shall be granted during installation. Delegated Management requires an Application Provider's Security Domain with this privilege to perform:

Delegated loading, Delegated installation, Delegated extradition, Delegated deletion.

The Application Provider, instead of the Card Issuer, manages each of the above processes. However, it is important to note that the OPEN performs the physical loading and installation. Please see the document of 'GlobalPlatform Card Specification Version 2.2.1' for more details.

4.4.1 Tokens

Delegated Management Tokens are signatures of one or more Delegated Management functions (loading application code, installing Applications and extraditing Applications) generated by the Card Issuer and used to provide the Card Issuer the control over these Card Content changes. The Issuer Security Domain shall verify Tokens(need Token verification key). Tokens are RSA signature of specific data. Please see the document of 'GlobalPlatform Card Specification Version 2.2.1' for more details.



4.4.2 Receipts

The Issuer Security Domain may generate Receipts during Delegated Management. A Receipt is proof to the Card Issuer that an Application Provider has modified the Card Content. Receipts are triple DES signature of specific data. Please see the document of 'GlobalPlatform Card Specification Version 2.2.1' for more details.

Authorized Management 4.5

Having a Security Domain with Authorized Management privilege allows a Security Domain provider to perform Card Content management without authorization (i.e. a token) in the case where the off-card entity is authenticated as the owner (Security Domain Provider) of the Security Domain. In that case the Security Domain that has Token Verification privilege is not involved. However, a Token is still required if the off-card entity is authenticated but is not the Security Domain Provider. A Security Domain with the Authorized Management privilege may delegate the Card Content Management operation on its descendant load files and applications.

Security Domains with Authorized Management Privilege are capable of managing their associated Card Contents including both Application and Security Domains

A Security Domain with Authorized Management Privilege is not allowed to manage Card Contents associated with another Security Domain with Authorized Management Privilege.

Issuer Security Domain is capable of managing Card Contents associated with other Security Domains with Authorized Management Privilege.

Issuer Security Domain is not allowed to delete(remove) Card Contents associated with other Security Domains with Authorized Management Privilege If SUPPORT_UNDELETABLE_SD flag is set to true.

Please see the document of 'GlobalPlatform Card Specification Version 2.2.1' for more details.

Confidential Ch.5 GlobalPlatform Card Mapping Guidelines


5. GlobalPlatform Card Mapping Guidelines

KONA2 D2320 supports the features specified in "Mapping Guidelines of Existing GP v2.1.1 Implementation on v2.2.1, Version 1.0.1", please see the document of 'Mapping Guidelines' if you need more details. This chapter provides implementation guidelines for mapping a GlobalPlatform card based on the Card Specification version 2.1.1 (GP CS 2.1.1 [0]) onto the Card Specification version 2.2.1 (GP CS 2.2.1 [1]). This guideline defines a subset of features defined in GP CS 2.1.1 [0] thus it defines sample of implementations. These implementations are based on the Java Card™ 2.1.1 or Java Card™ 2.2 specifications and implement the Java Card™ 2.1.1 API (JC 2.1.1 API [2]) or the Java Card™ 2.2 API (JC 2.2 API [5]). Throughout this document, special clarification will be provided if a particular guideline does not apply to all implementations or only applies to a particular implementation.

Security Domains 5.1

Two types of Security Domains exist for this guideline; the Issuer Security Domain that is present and active for all implementations and a Security Domain application code (an Executable Load File) from which additional Security Domains can be installed for implementations supporting additional Security Domains (i.e. a Supplementary Security Domain). From this point on in this document the term Security Domain usually refers to the behavior of both the Issuer Security Domain and any installed Security Domain. Wherever the behavior differs, this will be clarified with the terms Issuer Security Domain to identify the issuer's Security Domain and Supplementary Security Domain to identify an Application Provider's or Controlling Authorities' Security Domain.

Recommended Privileges 5.2

This guideline supports the following privileges only: - Security Domain - DAP Verification - Card Lock - Card Terminate - Card reset - CVM Management - Mandated DAP Verification - Authorized Management - Global Lock - Global Registry - Final Application

Recommended Application Programming Interfaces 5.3

5.3.1 GlobalPlatform 2.2.1

The following are the Application Programming Interfaces (API) that are accessible to applications developed according to the GlobalPlatform 2.1.1 API [0]. (See description in Appendix A of GP CS 2.2.1 [1] and the recommendations in section 7 of this document). The GPSystem methods to be present on all implementations.

- setATRHistBytes - setCardContentState - getCardContentState - getCardState

Ch. 6 COS Management Features Confidential


- getRegistryEntry - getSecureChannel - getService - getCVM - lockCard - terminateCard

The SecureChannel interface methods to be present for the Issuer Security Domain and for each instance of a Supplementary Security Domain if the implementation supports Supplementary Security Domains.

- decryptData - encryptData - getSecurityLevel - processSecurity - resetSecurity - unwrap - wrap

The GPRegistryEntry object interface to be present for the Issuer Security Domain, for each instance of a Supplementary Security Domain if the implementation supports Supplementary Security Domains and for each instance of Application. For each GPRegistryEntry object the interface methods to be present.

- deregisterService - getAID - getPrivileges - getState - isAssociated - isPrivileged - registerService - setState

The CVM interface methods to be present on all implementations.

- blockState - getTriesRemaining - isActive - isBlocked - isSubmitted - isVerified - resetState - resetAndUnblockState - setTryLimit - update - verify

The SecureChannelx interface method to be present for the Issuer Security Domain and for each instance of a Supplementary Security Domain if the implementation supports Supplementary Security Domains.

- setLevel

5.3.2 Java Card™

All implementations support the Java Card™ API and pass the corresponding compliance tests.



More specifically the following recommendations apply: The package javacard.security defines a set of classes and interfaces for the Java Card™ security framework. The full set of classes is present and the presence of the interfaces depends on the implementation. All implementations support symmetric cryptography (DES). Asymmetric cryptography is also supported on implementations supporting PKI functions. The following interfaces are supported on all implementations:

- DESKey - Key - SecretKey

In addition to the above 3 interfaces, the following interfaces are also supported implementations supporting PKI functions:

- PrivateKey - PublicKey - RSAPrivateCrtKey - RSAPrivateKey - RSAPublicKey

The CryptoException class is supported on all implementations. The following fields within the KeyBuilder class are present on all implementations:

- LENGTH_DES - LENGTH_DES3_2KEY - TYPE_DES - TYPE_DES_TRANSIENT_DESELECT - TYPE_DES_TRANSIENT_RESET

In addition to the above 5 fields, the following fields within the KeyBuilder class are also present for implementations supporting PKI functions:

- LENGTH_RSA_1024 - LENGTH_RSA_512 - LENGTH_RSA_768 - TYPE_RSA_CRT_PRIVATE - TYPE_RSA_PRIVATE - TYPE_RSA_PUBLIC

For implementations supporting PKI functions, the buildKey() method supports any other keyLength parameter for a keyType; TYPE_RSA_CRT_PRIVATE, TYPE_RSA_PRIVATE or TYPE_RSA_PUBLIC, as long as the length is between 512 and the maximum length supported by the card and is a multiple of 32 bits. The following field within the MessageDigest class is supported for implementations supporting PKI functions:

- ALG_SHA The complete RandomData class is supported for all implementations. The following fields within the Signature class is present for all implementations:

- ALG_DES_MAC8_ISO9797_M1 - ALG_DES_MAC8_ISO9797_M2 - ALG_DES_MAC8_ISO9797_1_M2_ALG3 - ALG_DES_MAC8_NOPAD



- MODE_SIGN - MODE_VERIFY

In addition to the above 5 fields, the following fields within the Signature class are also present for implementations supporting PKI functions:

- ALG_RSA_SHA_ISO9796 - ALG_RSA_SHA_PKCS1

The following fields within the Cipher class are present for all implementations:

- ALG_DES_CBC_ISO9797_M1 - ALG_DES_CBC_ISO9797_M2 - ALG_DES_CBC_NOPAD - ALG_DES_ECB_ISO9797_M1 - ALG_DES_ECB_ISO9797_M2 - ALG_DES_ECB_NOPAD - MODE_DECRYPT - MODE_ENCRYPT

In addition to the above 8 fields, the following fields within the Cipher class are also present for implementations supporting PKI functions:

- ALG_RSA_PKCS1 - ALG_RSA_NOPAD

The following field within the Checksum class is present for all implementations:

- ALG_ISO3309_CRC16

Clarifications for Java Card™ and EMV 5.4

While this implementation is based upon the Java Card™ specifications, the following areas exist where the information contained in GP CS 2.2.1 [1]overrides the Java Card™ 2.1.1 documentation (the Java Card™ 2.2 specifications have in some cases been updated to reflect these recommendations):

The RID of an Application instance AID does not have to be the same as the RID of the Package or the same as the RID of the application class from which the Application was instantiated.

The parameters defined for the install() method contain more than just the Application Specific Parameters i.e. the instance AID and Application Privileges are present in addition to the Application Specific Parameters (see section 6.6.2.3).

The GP CS 2.2.1 [1] mandates the suitable order as noted in the Java Card™ Virtual Machine [6] specification for the components of the CAP file.

If the GlobalPlatform implementation is for use on EMV compliant terminals, EMV level 1 requirements, except for item 2 and 3 below, take precedence over ISO/IEC 7816-4 [8] and the protocol rules described in the Java Card™ Runtime Environment (JCRE) Specification [7] and Java Card™ Application Programming Interface [6].

There are 3 known protocol discrepancies between ISO, EMV and Java Card™:

1. Responding to a case 2 command issued with a length (Le) of binary zero ('00') for a T=0 card.

All implementations respond to such a command with a '6Cxx' response instead of the '61xx' response suggested by the Java Card™ specification and this, along with the subsequent re-issued command, are managed by the JCRE. Refer to section 8.4.1.1 of JC RE 2.1.1 [4], section 9.4.1.1 of JCRE 2.2 [7], and section 5.3.1.2.1 of EMV Book 1 [9]. A simple example of the expected behavior is as such:



When an applet invokes the setOutGoingAndSend(bOff, len) method, the JCRE responds with a '6Cxx' (xx = len) response if Le on the incoming command was '00'. If the subsequent command is not the same as the previous incoming command, the card behavior can be unpredictable. If the subsequent command is the same as the previous incoming command with a Le not equal to '00': The JCRE does not invoke the process() method of the currently selected application. The JCRE does output Le bytes of data from the APDU buffer followed by a '9000' or '61xx'

returned code.

2. Responding to a case 4 command with a warning return code for a T=0 card.

While not defined as an option in EMV, a Java Card™ can only respond with the warning return code following the last GET RESPONSE command. Refer to section 5.3.1.1 of EMV Book 1 [9] and the JC 2.1.1 API [2]or JC 2.2 API [5] (specifically the APDU class). A simple explanation of the issue relates to the SELECT command when the card is in the Life Cycle State CARD_LOCKED and is as such: When the Issuer Security Domain invokes the setOutGoingAndSend(bOff, len) method, the JCRE does not at this point have any knowledge of the warning return code. The only option available to the JCRE is to use the '61xx' return code and the GET RESPONSE command sequence. Only when control is passed back to the Issuer Security Domain, it can set the value of the return code to '6283'.

3. The class byte of the GET RESPONSE command.

While EMV states that the class (CLA) byte of a GET RESPONSE command will always be zero ('00'), ISO/IEC 7816-4 and other specifications do not mandate this. From a GlobalPlatform point of view, in order to ensure that GlobalPlatform cards are accepted in the widest range of terminals possible and in order to support logical channels, these implementations do not limit the value of the CLA byte for a GET RESPONSE command.



< Normative References >

Standard / Specification Description

GlobalPlatform Card Specification v2.1.1 GlobalPlatform Card Specification v2.1.1

GlobalPlatform Card Specification v2.2.1 GlobalPlatform Card Specification v2.2.1

Java Card™ 2.1.1 API Sun Microsystems Java Card™ 2.1.1 Application Programming Interface, Revision 1.0, May 18, 2000

Java Card™ 2.1.1 VM Specification Sun Microsystems Java Card™ 2.1.1 Virtual Machine Specification, Revision 1.0, May 18, 2000

Java Card™ 2.1.1 JCRE Specification Sun Microsystems Java Card™ 2.1.1 Runtime Environment (JCRE) Specification, Revision 1.0, May 18, 2000

Java Card™ 2.2 API Sun Microsystems Java Card™ 2.2 Application Programming Interface Specification, September 2002

Java Card™ 2.2 VM Specification Sun Microsystems Java Card™ 2.2 Virtual Machine Specification, June 2002

Java Card™ 2.2 JCRE Specification Sun Microsystems Java Card™ Runtime Environment (JCRE), June 2002

ISO/IEC 7816-4 ISO/IEC 7816-4

EMV Book 1 Application Independent ICC to Terminal Interface Requirements v4.2

EMVCo - EMV Integrated Circuit Card Specifications for Payment Systems – Book 1 – Application Independent ICC to Terminal Interface requirements, Version 4.2, June 2008

Confidential Ch.6 COS Management Features


6. COS Management Features

Changing the AID of ISD 6.1

Following command is a sample of changing the AID of ISD : 80E200000D00700A4F08A000000003000000

Code Value Meaning

CLA '80'

INS 'E2' STORE DATA

P1 '00' Reference control parameter P1

P2 '00' Block number

Lc '0D' Length of data field

Data

'0070 0A 4F 08 A0…'

Application data and MAC (if present)

Le '01' Not present

Data SW1 SW2 Meaning

- '90' '00' Command is successfully completed

- '6E' '00' CLA value not supported or a fused card

- '6D' '00' INS value not supported

Read / Update Commands for KONA Proprietary Configuration 6.2

This command reads or updates the contents of KONA proprietary configurations, such as protocol, ATR, etc. Common Conditions:

- The card life cycle state is OP_READY. - The card has not been fused.

(not in situation that all functions of pre-personalization are disabled by FUSE command)

- Secure session has been established.

6.2.1 Command for reading/changing protocol type

This command reads or changes current protocol type (T=0 to T=1 or vice versa). Examples:

- Read : B0 04 01 00 02 000100 - Update : B0 04 02 00 03 000100

< Read current protocol type>

Code Value Meaning

CLA 'B0' KONA I proprietary

INS '04'

P1 '01' READ PROPRIETARY CONFIGURATION

P2 '00' Protocol

Lc '02' Length of data to be sent

Data '00 01' First byte: offset (must be always 0) Second byte: length of data to read

Le '00'




'XX...' '90' '00' Command is successfully completed, Data: '00' means T=0 , '01' means T=1



< Change current protocol type >

Code Value Meaning


INS '04'

P1 '02' WRITE PROPRIETARY CONFIGURATION

P2 '00' Protocol


Data '00 01 XX' First byte: offset (must be always 0) Second byte: length of data to be sent Third byte: value to be set ('00' for T=0, '01' for T=1)

Le '00'





6.2.2 Command for reading/updating ATR

This command reads or updates the content of ATR Examples:

- Read Cold ATR T=0 : B0 04 01 01 02 00 FF - Update Cold ATR T=0 : B0 04 02 01 0E 00 0C 3B6800000073C84012009000

< Read the content of ATR >

Code Value Meaning


INS '04' READ PROPRIETARY CONFIGURATION

P1 '01'

P2 '01' 01 Cold ATR for T=0, 02 Cold ATR for T=1 03 Warm ATR for T=0, 04 Warm ATR for T=1 05 ATS for T=CL

Lc '02' Length of data field

Lc 'XX' Length of data field

Data 'XX XX.' The first byte : Offset of data being read The second bytes : Length of data being read


'XX...' '90' '00' Command is successfully completed, Data: the content of ATR or ATS





< Write the content of ATR >

Code Value Meaning


INS '04' WRITE PROPRIETARY CONFIGURATION

P1 '02'

P2 '01' 01 Cold ATR for T=0, 02 Cold ATR for T=1 03 Warm ATR for T=0, 04 Warm ATR for T=1

Lc '0E' Length of data field

Data '00 0C 3B…'

First byte: Offset of data being written Second byte: Length of data being written The other bytes: Data being written for new ATR

Le '01'


'XX' '90' '00' Command is successfully completed, And the length of written data is 'XX'.



6.2.3 Command for reading/changing the type of protocol T=CL

This command reads or writes the flag value which decides the type of Protocol T=CL. Examples:

- Read current flag value : B0 04 01 0E 02 00 01 - Write the flag value to be used : B0 04 02 0E 03 00 01 XX

< Read current protocol type>

Code Value Meaning


INS '04'

P1 '01' READ PROPRIETARY CONFIGURATION

P2 '0E' The flag value which decides the type of Protocol T=CL


Data '00 01' First byte: offset (must be always 0) Second byte: length of data to read

Le '00'







< Change current protocol type >

Code Value Meaning


INS '04'

P1 '02' WRITE PROPRIETARY CONFIGURATION

P2 '0E' The flag value which decides the type of Protocol T=CL


Data '00 01 XX' First byte: offset (must be always 0) Second byte: length of data to be sent Third byte: value to be set ('00' for T=0, '01' for T=1)

Le '00'





6.2.4 Command for the option of 'Delegated Management'

This command reads or writes the option of Delegated Management(DM) to set enable or disable. Examples:

- Read the option value of Delegated Management : B0 04 01 07 02 00 FF - Write to be enable Delegated Management Option : B0 04 02 07 03 00 01 01 - Write to be disable Delegated Management Option : B0 04 02 07 03 00 01 00

Table 6-1 Command for Read the option value of DM

Code Value Meaning

CLA ‘B0’ KONA I proprietary

INS ‘04’

P1 ‘01’ or ‘02’ ‘01’: READ PROPRIETARY CONFIGURATION ‘02’: WRITE PROPRIETARY CONFIGURATION

P2 ‘07’ Supporting Option for Delegated Management

Lc ‘XX’ Length of data field

Data

‘XX XX XX…’

First byte: Offset of data being written Second byte: Length of data being written The other bytes: Data being written

‘00’: Disable Delegated Management Option ‘01’: Enable Delegated Management Option

Le ‘00’

Table 6-2 Response for Read the option value of DM


‘XX’ ‘90’ ‘00’

Command is successfully completed, Data: -.Read: the value of Delegated Management Option - Write: the length of written data is ‘XX’.

- ‘6E’ ‘00’ CLA value not supported or a fused card

- ‘6D’ ‘00’ INS value not supported



6.2.5 Command for switching secure channel protocol mode

This command sets 'Secure Channel Protocol' mode to SCP01 or SCP02. Examples: B0 04 07 01 04 4B 45 42 54

< Change Secure Channel Protocol mode >

Code Value Meaning


INS '04' SWITCH SCP MODE

P1 '07'

P2 'XX' 01: Switching to SCP01 02: Switching to SCP02

Lc '04' Length of data field

Data '4B 45 42 54' Data for switch SCP mode

Le -' Not present


- '90' '00' Command is successfully completed,


- '6D; '00' INS value not supported

6.2.6 Disable Pre-Personalization functions (FUSE command)

This command makes the functions of pre-personalization to be disabled permanently. Examples: B0 04 10 00 If a card has already been personalized, in other words, the state of card has been changed to SECURED or if FUSE command was issued successfully, this command is not able to be used any more. Once this FUSE command was issued to a card successfully, the card is fused and the pre-personalization commands are disabled. So if the fused card receives the pre-personalization commands, then it responds with '6E00'. The following pre-personalization commands are affected by the FUSE command.

Code Value Meaning


INS '04' FUSE Command

P1 '10'

P2 'XX' Any value

Lc Not present

Data Not present

Le Not present


- '90' '00' Command is successfully completed,

- '6E' '00' FUSE Command is not processed.

Ch. 7 Interface and Protocols Confidential


7. Interface and Protocols

Supported Contact Protocols 7.1

KONA2 D2320 supports both T=0 and T=1 protocols specified in ISO/IEC 7816 and the former is configured as a default protocol. Providing pre-personalization instructions, the KONA2 D2320 is also able to manipulate ATR values after taking authorization in situation that the card life cycle is in OP_READY state. Auto wait extension is supported in KONA2 D2320 platform level.

7.1.1 Communication speeds

At the default clock rate of 3.57 MHz, the following communication speeds can be attained:

Bit Rate [ bit/s ]

External Clock FCLK / MHz

TA1 (FI, DI) Fi / Di CLKs / etu

9600 3.57 01 or 11 372 / 1 372

19200 3.57 02 or 12 372 / 2 186

38400 3.57 03 or 13 372 / 4 93

115200 3.57 08 or 18 372 /12 31

7.1.2 Answer to Reset (ATR), T=0 (Default)

ATR value is "3B 68 00 00 00 73 C8 40 11 00 90 00".

Character Value Description

TS '3B' Direct convention [ L(HHLHHHLL)H ]

T0 '68' TB1 & TC1 are present, 8 historical bytes

TB1 '00' Imax = 25mA; Vpp = Vcc

TC1 '00' Extra guard time needed; from 0 to 10

HC1 to HC8 '0073C84011009000' Historical bytes

7.1.1 Answer to Reset (ATR), T=1

ATR value is “3B E8 00 00 81 31 20 45 00 73 C8 40 11 00 90 00 47”.

Table 7-3 Answer to Reset (ATR), T=1


TS ‘3B’ Direct convention [ L(HHLHHHLL)H ]

T0 ‘E8’ TB1, TC1 and TD1 are present, 8 historical bytes

TB1 ‘00’ Imax = 25mA; Vpp = Vcc

TC1 ‘00’ Extra guard time needed; from 0 to 10

TD1 ‘81’ TD2 is present, T=1

TD2 ‘31’ First TA and TB are present, T=1

First TA ‘20’ IFSC = 32

First TB ‘45’ CWI = 5, BWI = 4

HC1 to HC8 ’00 73 C8 40 11 00 Historical bytes:

Confidential Ch.7 Interface and Protocols


90 00’ ‘00’: Category indicator byte ‘73’: Tag: 7, Len: 3 (card capabilities)

‘C8’: Selection methods: 200 - Implicit DF selection - DF selection by partial DF name - DF selection by full DF name ‘40’: Data coding byte: 64 - Behavior of write functions: write OR - Value ‘FF’ for the first byte of BER-TLV tag fields: valid - Data unit in quartets: 0 ‘11’: Command chaining, length fields and logical channels: 17 - Maximum number of logical channels: 2 ’00 90 00’: Mandatory status indicator (3 last bytes) - LCS (life card cycle): 0 (No information given) - SW: 90 00

Checksum ‘47’ Checksum

Supported Contactless Protocol 7.2

KONA2 D2320 supports both T=CL Type A and T=CL Type B protocol described in ISO/IEC14443-4. Providing pre-personalization instructions, the KONA2 D2320 is also able to manipulate ATS values after taking authorization in situation that the card life cycle is in OP_READY state. KONA2 D2320 uses ATQA=”04 00”, SAK=”20” respectively and those values can be modified by customers’ requests. KONA2 D2320 uses single UID. KONA2 D2320 supports FSCI=8(FSC=256) to the maximum. KONA2 D2320 provides the protocol and parameter selection feature specified in ISO14443-4. By manipulating the value of TA(1) of ATS, KONA2 D2320 is capable of supporting high speed baud rate. By manipulating the value of FWI of TB(1) of ATS, KONA2 D2320 can control the range of S(WTX) from 7 to 14 and 7 is configured as default to meet EMV standard. The CID is supported but NAD is not.

7.2.1 Communication speeds

Following data transfer rates are supported: - 106 kbit/sec - 212 kbit/sec - 424 kbit/sec - 848 kbit/sec

7.2.2 ISO14443 T=CL Type A

T=CL protocol described in ISO/IEC14443-3 supported. Following data transfer rates supported. - 106 kbit/sec [default] - 212 kbit/sec - 424 kbit/sec - 848 kbit/sec

Ch. 7 Interface and Protocols Confidential


7.2.3 Answer to Select (ATS)

ATS value is “0B 78 80 71 02 4B 4F 4E 41 23 20”.

Table 7-4 Answer to Select (ATS), T=CL


TL ‘0B’ Length byte

T0 ‘78’ TC1, TB1 and TA1 are present, and FSCI

TA1 ‘80’ Interface byte : DS and DR

TB1 ‘71’ Interface byte : FWI and SFGI

TC1 ‘02’ Interface byte : protocol options

T1~ Tk ‘4B 4F 4E 41 23 20’ Historical Bytes: 4B 4F 4E 41 => K O N A 23 20 => 2320 (SAMSUNG 320K)

7.2.4 ISO14443 T=CL Type B

T=CL ptorocol described in ISO/IEC 14443-3 supported. Following data transfer rates supported.

- 106 kbit/sec [default]

- 212 kbit/sec

- 424 kbit/sec

- 848 kbit/sec

7.2.5 Answer to Request type B(ATQB)

ATQB value is “50XXXXXXXX00000000008171”.

- Bit rates supported : PICC supports only 106kbps/s in both directions

- Max frame size : 256 bytes

- Protocol types supported : PICC compliant ISO/IEC 14443-4

- TR2 min : 10etu + 32/fs

- FWI = 7 (39ms)

- Frame options : CID supported

7.2.6 Restriction of FWI (Frame Waiting time Integer)

According to ISO/IEC 14443-4, the value of FWI has the range from 0 to 14. But KONA2 D2320 supports only from 07 to 14 as FWI.

Confidential Ch.8 Hardware Specification


8. Hardware Specification

Product type KONA2 D2320

CHIP SAMSUNG S3FT9MG

CPU 16-bit SecuCalm

ROM 40 Kbytes (Reserved for Samsung bootloader)

FLASH 320 Kbytes

RAM 14 Kbytes (9KB for general purpose RAM and 5KB for Crypto RAM respectively)

FLASH Data retention

25 years(Min.) (Guaranteed on condition that 25 degree C).

FLASH Endurance

500,000 cycles (Min.)

Co-processor

RSA Yes

DES Yes

AES Yes

MMU Supported

Operating Temperature -25℃ ~ 85℃

Operating Voltage 1.62 V ~ 5.5 V

Ch.9 Applets Confidential


9. Applets

KONA2 D2320 has the ISD and other masked applets (VSDC 2.8.1F1, M/Chip advance MA, PSE 2.2). Capabilities of the ISD and these masked applets are described in this section.

VSDC 2.8.1 F1 9.1

"Visa Smart Debit/Credit Applet 2.8.1 F1" developed by Visa International Service Association is masked in ROM of KONA2 D2320. VSDC applet supports both common personalization and the old personalization method, referred to as the proprietary method. VSDC applet conforms to the mandatory requirements of the "Visa Integrated Circuit Card Specification (VIS) Version 1.5 (May, 2009)". VSDC 2.8.1F1 supports following features as listed in the "VSDC Applet Version 281F1 Release Notes February 2014".

M/Chip Advance Payment 9.2

MasterCard M/Chip™ Advance Payment, applet of MasterCard is masked in ROM of KONA2 C2200S and guarantees compliance to M/Chip Advance Payment specifications. From debit, credit, prepaid MasterCard M/Chip Advance card applications are the power behind the new generation of integrated payment cards behind the new generation of integrated payment cards. Complete information on M/Chip Advance applet can be found in the ‘KONA i - M/Chip Advance personalization guide’ document or ‘M/Chip Advance Payment & Data storage’ Specifications

Confidential Ch.10 Caution in Implementation


10. Caution in Implementation

Security Guidelines 10.1

10.1.1 Off-Card Verifier

KONA2 D2320 does not contain On-Card Verifier, therefore, all the Java Card applications shall pass Off-Card Verifier before loaded to KONA2 D2320. Also it is prohibited to load ill formed application.

- Applets can only be downloaded by a trusted party. - Applets must pass the latest SUN/Oracle byte code verifier. - Applets must not contain malicious code. - Applets can only be downloaded in a secure environment/method.

10.1.2 Security Counter

In case an attack is detected it is recommended to perform some security action. Often a card is blocked immediately or a security counter is used to block the card after a certain number of detected attacks. Such a blocking mechanism needs to write to persistent memory. Writing to persistent memory is often visible in the power consumption of the chip and can therefore be bypassed (by cold resetting the card immediately when such a write operation is detected). Countermeasures to detect attacks like fault injection already implemented by the OS. When fault attack is detected, the OS increase security counter. Once a certain boundary value on the number of fault attacks has been reached, the OS fills the certain area with a certain value and throws exception, and eventually this mechanism will block the card.

10.1.3 API restrictions

10.1.3.1 Security aspects

- Keys shall be stored in Java Card key objects only. The OS secures these objects. - When generated keys by RSA or ECC key generation are invalid the OS throws excep

tion, so applet does not need to verify keys. But it is recommended that applet verifies the generated keys.

- The applet should define and use short constant value for true (e.g. 0xA5A5) and false (e.g. 0x5A5A).

- Minimum Security Level must be set to use at least MAC protected commands.

10.1.3.2 Cryptographic aspects

- RSA keys need to have a key length of at least 512 bit and up to 2048 bit. (should be multiple by 4 bytes)

- When using RSA CRT, key with different size of P and Q are possible. But P and Q should be multiple by 4 bytes.

- For RSA key generation, key size should be multiple by 4 bytes. - For RSA CRT key generation, key size should be multiple by 8 bytes.

10.1.4 Security Countermeasures

10.1.4.1 Program Flow Control

KONA platform protects the applet code integrity during execution and guarantees that the intended

Ch.10 Caution in implementation Confidential


applet bytecode instructions are executed and that the correct data elements and correct methods are called. For critical code, it is recommended to implement a branch condition such that the error case is executed when the check is manipulated by an attacker. The following code snippet gives an example: (short) flow_check = 0x0A0A; … flow_check |= 0x00A0; // Critical instruction; flow_check |= 0xA000; If ( flow_check == 0xAAAA ) { // do more things... // return } // Should not reach here... SecurityError(); For loops it is recommended to implement some checks at the end of a loop to make sure that all iterations have been performed. The following code snippet gives an example: // loop for( ; loop_count < index ; loop_count++) { // process something... } // check loop_count if(loop_count == index) { // do more things... // return } // Should not reach here... SecurityError(); For some of JavaCard API returns values, it is recommended to implement proper checks for these values, especially those methods which update Non-Volatile Memory (Util.arrayCopy, Util.arrayCopyNonAtomic, arrayFillNonAtomic, Util.setShort etc). The following code snippet gives an example: byte[] src, dest; short length; … // copy the array and check return value if( Util.arrayCopy(src, (short)dest_offset dest, (short)dest_offset, length) == length + dest_offset ) { // do more things... // return } // Should not reach here



SecurityError();

10.1.4.2 Data Integrity Check

Applets maintain application and session data in non-volatile memory and session data in volatile memory, which are stored as members of object instances. Applets shall implement countermeasures on several security sensitive data elements. The following code snippet gives an example: // process data process(secureData, length); ... // check integrity of data if( checkIntegrity(secureData, length) == true ) { write(secureData, length); // return } // Should not reach here... SecurityError();

10.1.4.3 Key Integrity Check

Because the persistent objects that are used during the application code need some integrity mechanism to protect against perturbation attacks, KONA platform stores all secret data such as keys and PIN values encrypted to prevent that the data can be disclosed through a memory dump. The following code snippet gives an example: DESKey keydata; byte[] dest, temp; short dest_offset, temp_offset // encrypt key keydata.setKey(dest, dest_offset); keydata.setKey (temp, temp_offset); // compare dest and temp if( compare(dest, dest_offset, temp, temp_offset, keydata.length) == true ) { // do more things... // return } // Should not reach here... SecurityError();

10.1.4.4 Redundant calculation

For calls to Java Card API methods with a boolean return value, a redundant call to the method can be used to validate the result. In case of different results, the Security Counter has to be updated. The following code snippet gives an example: DESKey keydata; byte[] dest, temp; short dest_offset, temp_offset;

Ch.10 Caution in implementation Confidential


// encrypt input data encrypt(input, offset, dest, dest_offset, input.length); encrypt(input, offset, temp, temp_offset, input.length); // compare results if( compare(dest, dest_offset, temp, temp_offset, dest.length) == true ) { // do more things... // return } // Should not reach here SecurityError();

Information of Masked Java Card API Packages 10.2

Java Card API Package v3.04

Supported Description

java.io Yes

java.lang Yes

java.rmi No

javacard.framework Yes

javacard.framework.service No

javacard.security Supports a partial of package See details at "3.7. Security Features"

org.globalplatform Yes

visa.openplatform Yes

Protocol Parameters defined on ISO/EIC 14443 10.3

10.3.1 Restriction of FWI (Frame Waiting time Integer)

According to ISO/IEC 14443-4, the value of FWI has the range from 0 to 14. But KONA2 D2320 supports only from 7 to 14 as FWI, and the value from 0 to 6 are ignored.

Secure Messaging defined on ISO/EIC 7816 10.4

10.4.1 Channel

KONA2 D2320 has two logical channels. One is used for basic logical channel and the other one is used for supplementary logical channels.

10.4.2 MANAGE CHANNEL Command

The MANAGE CHANNEL command opens and closes logical channels. Further information of MANAGE CHANNEL command is described in ISO/EIC 7816-4

[6].

1) Secure Messaging

According to ISO/EIC 7816-4[5]

, four Secure Messaging (hereinafter referred to as "SM") options exists and are indicated in lower nibble of CLA of APDU command. KONA2 D2320 only supports 'No SM or no SM indication' for MANAGE CHANNEL command. In other words, lower nibble of CLA of MANAGE CHANNEL command should be '0'. If any other value is used for lower nibble of CLA of MANAGE CHANNEL command, KONA2 D2320 will return status word indicating error or warning.



2) Behavior of KONA2 D2320 Upon receiving MANAGE CHANNEL command, KONA2 D2320 first checks if command requests SM by analyzing lower nibble of CLA. If MANAGE CHANNEL command requests SM, KONA2 D2320 returns 0x6882 indicating secure messaging not supported

[5]. For example,

KONA2 D2320 returns 0x6882 for MANAGE CHANNEL command '04 70 P1 P2 00', '08 70 P1 P2 00' and '0C 70 P1 P2 00' with P1, P2 be combination of any value between 0x00 to 0xFF. After checking CLA for SM, since there only exists one logical channel, KONA2 D2320 returns 0x6881 indicating logical channel not supported.

Warning about the uninstalling of Applet 10.5

Applet shall implement the interface of ‘AppletEvent’, otherwise it cannot be uninstalled.

kona2 d2320 user manual - armbusinessbank · this document contains a simple overview about the...

Documents