Card Specification Amendment A March 2004

Transcription

1 Card Specification March 2004 Use of this information is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

2 2 GlobalPlatform Card Specification /2004

3 03/2004 GlobalPlatform Card Specification Table of Contents DEFINITION OF AMENDMENT...4 TABLE OF EXTENSIONS...4 A.1 STORE DATA Command...5 A.1.1 Reference Control Parameter P1...5 A.1.2 Command Message Data Field...6 A.1.3 Response Message Processing State...6 Command Pre-Processing...7 A.2 Pseudo-Random Card Challenge...7 A.2.1 Secure Channel Protocol 02 Pseudo-Random Card Challenge...7 A.2.2 Secure Channel Protocol 02 Options Identifier...7 A.3 Data Element Tags and Values Allocation...8 A.3.1 Data Element Tags...8 A.3.2 Key Type Values...9 A.4 Card and Application Management...9 A.4.1 Executable Load File Version Number...9 A.4.2 Runtime Environment Version Number...10 A.4.3 GET STATUS Parameter P1 Extensions...10 Use of this information is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

4 4 GlobalPlatform Card Specification /2004 Definition of Amendment A GlobalPlatform Amendment includes a set of optional extensions to the latest version of a GlobalPlatform specification, that address few limited technical change requests. An Amendment is intended to be incorporated as is in a subsequent release of the GlobalPlatform specification it amends. When implemented, an optional extension shall comply to the description provided in the corresponding Amendment. Table of Extensions This Card Specification is a set of optional extensions to the current Card Specification version These extensions provide support for the latest GlobalPlatform Scripting Specification, EMV Card Personalization Specification (see and Smart Card Platform TS and TS specifications (see Each part of this Amendment: A.1, A.2, A.3 or A.4, describes a self-contained extension that may be implemented independently of each other. The following table classifies the different parts of this Amendment into a sequential order that reflects the Card Specification index. The additions to the current specification are in blue characters. Amendment Card Specification number section number Description A.1 sections & 9.11 STORE DATA Command A.3 sections 9.1.6, , Data Element Tags and Values Allocation & A.4 sections , Card and Application Management & appendix F.2 A.2 appendices E.1.1 & E.4.2 Pseudo-Random Card Challenge

5 03/2004 GlobalPlatform Card Specification A.1 STORE DATA Command The STORE DATA command functionality is extended to support Application data format and data encryption management. Implementing this extension A.1 requires supporting BER-TLV format for non-encrypted (Issuer) Security Domain data transfer, that is: reference control parameter P1 bits b7-b6-b5-b4 set to 0010 with the corresponding data field coding. Section 9.11 STORE DATA Command of version is extended as described hereafter. A.1.1 Reference Control Parameter P1 Reference control parameter P1 of the STORE DATA command coding is extendedwith Application data format and data encryption information. Zero values for bits b4, b5, b6 and b7 ensure backward compatibility with the existing GlobalPlatform Card Specification. Section STORE DATA Reference Control Parameter P1 is extended as follows: b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 More blocks 1 Last block 0 0 No general encryption information or nonencrypted data 0 1 Application dependent encryption of the data 1 0 RFU (encryption indicator) 1 1 Encrypted data 0 0 No general data structure information 0 1 DGI format of the command data field 1 0 BER-TLV format of the command data field 1 1 RFU (data structure information) X X X RFU Table 9-62: STORE DATA Reference Control Parameter P1 Bits b5 and b4 provide information on the data structure of the command message data field. b5 - b4 = 00 indicate that no general information on the data structure is provided, i.e. the data structure is Application dependent, b5 - b4 = 01 indicate that the command message data field is coded as one or more DGI structures, according to GlobalPlatform Scripting Specification version 1.1, b5 - b4 = 10 indicate that the command message data field is coded as one or more BER- TLV structures, according to ISO Bits b7 and b6 provide information on the encryption of the value fields of the data structure present in the command message data field. b7 b6 = 00 indicate that no general information on the data encryption is provided, i.e. the encryption (or non-encryption) of the data is Application dependent, or that the data value fields of all the data structures present in the current command message are not encrypted, b7 b6 = 01 indicate that the encryption (or non-encryption) of the data structure value fields is Application dependent, e.g. when multiple data structures are present in the current command message, some may have encrypted data value fields and other data value fields may be non-encrypted b7 b6 = 11 indicate that the data value fields of all the data structures present in the current command message are encrypted.

6 6 GlobalPlatform Card Specification /2004 A.1.2 Command Message Data Field The data field coding of the STORE DATA command reflects the different data formats indicated in the command Reference Control Parameter P1. Section STORE DATA Command Data Field is extended as follows: The STORE DATA command data field may be formatted according to an Application's or Security Domain s requirements. Application dependent format applies when no information is available on the format of the incoming command data: bits b5-b4 of reference control parameter P1 are set to 00. In this case, information on the encryption (or non-encryption) of the incoming command data is usually not available (parameter P1 bits b7-b6 set to 00 ): the format and eventual encryption of the incoming command data are implicitly known by the Application. DGI formatting applies when all data structures that are present in the command data field are formatted as DGI structures (as defined in the Scripting Specification): bits b5-b4 of reference control parameter P1 are set to 01. In this case, some information may be available on the encryption (or non-encryption) of the value fields of the DGI data structures: reference control parameter P1 bits b7-b6 are set accordingly. BER-TLV formatting applies when all data structures that are present in the command data field are formatted as BER-TLV structures (as defined in ISO 8825): bits b5-b4 of reference control parameter P1 are set to 10. In this case, some information may be available on the encryption (or non-encryption) of the value fields of the TLV data structures: reference control parameter P1 bits b7-b6 are set accordingly. If the overall length of the intended command message exceeds 255 bytes, the individual (or group of) data shall be sent in multiple consecutive STORE DATA commands. Whether the data format is a DGI or BER-TLV data structure, the following rules shall apply: The data structure length indicators shall always reflect the actual full length of the data structure value field, The data structure value field shall be truncated in the STORE DATA command message containing the data structure length indicator (e.g. at the maximum length of the command message), The subsequent STORE DATA command shall contain the remainder of the data structure value field (that may be followed by one or more data structure(s) in this same command message) note: for very large data, more than one subsequent STORE DATA command message may be required for the remainder of the data structure value field, The receiving Application or Security Domain shall use the last data structure length indicator of a STORE DATA command message to determine whether a subsequent STORE DATA command is expected to contain the remainder of the data structure value field. A.1.3 Response Message Processing State The list of error conditions applicable to the STORE DATA command is completed with an additional data processing error. Table 9-63 of section STORE DATA Response Processing State is extended as follows: SW1 SW2 Meaning '6A' '80' Incorrect values in command data 6A 88 Referenced data not found Table 9-63: STORE DATA Error Condition

7 03/2004 GlobalPlatform Card Specification A.1.4 Command Pre-Processing The following applies only when STORE DATA command pre-processing is implemented. When the Security Domain receives a STORE DATA command destined to an Application, the preprocessing of the STORE DATA command by that Security Domain is not impacted by the new optional STORE DATA command functionality. Section Security Domain access to Applications is extended with the following precision: The Security Domain unwraps this command according to the current Security Level of the current Secure Channel Session and prior to the command being forwarded to the Application. This pre-processing leaves as is the data structures of the command message as well as the eventual encryption of the data value fields of these data structures. A.2 Pseudo-Random Card Challenge In Explicit Secure Channel Initiation mode of Secure Channel Protocol 02, a pseudo-random generation algorithm provides the option to pre-compute the card challenge as opposed to it always being random. This would allow an off-card entity, with knowledge of the relevant Secure Channel secret keys and the ability to track the Secure Channel Sequence Counter, to precompute an authentication sequence without first communicating with the card. A.2.1 Secure Channel Protocol 02 Pseudo-Random Card Challenge Appendix E.4.2 Authentication Cryptograms in SCP 02 Explicit Secure Channel Initiation is extended as follows: Card Challenge The card challenge is either a random or pseudo-random number that shall be unique to a Secure Channel Session. A pseudo-random card challenge may be generated as follows: The AID of the currently selected Application is padded according to the padding rules defined in Appendix B.4 DES Padding; A MAC is calculated across the padded data as defined in Appendix B Single DES plus final triple DES, using the C-MAC session key and an ICV of binary zeroes; The six leftmost bytes of the resultant MAC constitute the card challenge. A.2.2 Secure Channel Protocol 02 Options Identifier To indicate support of a GlobalPlatform specified card challenge generation algorithm to an offcard entity, the SCP 02 options identifier is extended with new values. Appendix E.1.1 SCP 02 Secure Channel is extended as follows: "i" = '44': Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, no ICV encryption, 1 Secure Channel base key, well-known pseudo-random algorithm (card challenge), "i" = '45': Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, no ICV encryption, 3 Secure Channel Keys, well-known pseudo-random algorithm (card challenge), "i" = '54': Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, ICV encryption for C-MAC session, 1 Secure Channel base key, well-known pseudo-random algorithm (card challenge), "i" = '55': Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, ICV encryption for C-MAC session, 3 Secure Channel Keys, well-known pseudo-random algorithm (card challenge).

8 8 GlobalPlatform Card Specification /2004 For backward compatibility with the existing SCP 02 options identifier values, appendix E.1.1 SCP 02 Secure Channel is extended with the following precision: "i" = '04': Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, no ICV encryption, 1 Secure Channel base key, unspecified card challenge generation method, "i" = '05': Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, no ICV encryption, 3 Secure Channel Keys, unspecified card challenge generation method, "i" = '14': Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, ICV encryption for C-MAC session, 1 Secure Channel base key, unspecified card challenge generation method, "i" = '15': Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, ICV encryption for C-MAC session, 3 Secure Channel Keys, unspecified card challenge generation method A.3 Data Element Tags and Values Allocation The following data element tags and values are allocated by GlobalPlatform. Please note that some data elements tags and values are reserved for use by Smart Card Platform technical specifications. A.3.1 Data Element Tags In coordination with the Smart Card Platform project, a range of data element tags is reserved by GlobalPlatform for Smart Card Platform specifications. Note that Smart Card Platform TS and GSM specifications already define tags FF 1F and FF 20 with GlobalPlatform GET DATA command implementation and tag CA with GlobalPlatform INSTALL command. The usage and rules associated to those data elements are outside the scope of GlobalPlatform and defined by the Smart Card Platform specifications. Section GET DATA command Parameter P1 and P2 is extended as follows: Tags in the range FF 00 to FF 1E are reserved for data elements defined by GlobalPlatform specifications, Tags in the range 'FF 1F' to 'FF 3F' are reserved for data elements defined by Smart Card Platform TS specification, Tags in the range FF 40 to FF 7F are reserved for future use (RFU) and may be allocated in the future by GlobalPlatform to specific card schemes/specifications. Table 9-35 of section INSTALL [for load] and INSTALL [for install] Parameters is extended as follows: Tag Length Value (Name) Presence 'C9' Variable Application Specific Mandatory Parameters 'EF' Variable System Specific Parameters Conditional 'C7' 2 Volatile data space limit Optional 'C8' 2 Non volatile data space limit Optional 'CA' Variable TS specific parameter Optional 'EA' Variable TS specific template Optional Table 9-35: Install Parameter Tags

9 03/2004 GlobalPlatform Card Specification A.3.2 Key Type Values Key Type coding is extended to include new values: 82 to 84, that support the KIc and KID key and algorithm identifier coding defined in Smart Card Platform TS specification. Table 9-10 of section Key Type Coding is extended as follows: Value '00'-'7F' '80' '81' '82' '83' '84' '85'-'9F 'A0' 'A1' 'A2' 'A3' 'A4' 'A5' 'A6' 'A7' 'A8' 'A9'-'FE' 'FF' Meaning Reserved for private use DES mode (EBC/CBC) implicitly known Reserved (triple DES) Triple DES in CBC mode DES in ECB mode DES in CBC mode RFU (symmetric algorithms) RSA Public Key - public exponent e component (clear text) RSA Public Key - modulus N component (clear text) RSA Private Key - modulus N component RSA Private Key - private exponent d component RSA Private Key - Chinese Remainder P component RSA Private Key - Chinese Remainder Q component RSA Private Key - Chinese Remainder PQ component RSA Private Key - Chinese Remainder DP1 component RSA Private Key - Chinese Remainder DQ1 component RFU (asymmetric algorithms) Not Available Table 9-10: Key Type Coding A.4 Card and Application Management More management information is made available to off-card systems tracking multiple versions of application code and multiple versions of card platforms. A.4.1 Executable Load File Version Number Information available to an off-card system with the GET STATUS command is extended to include the Executable Load File Version Number when retrieving Executable Load File or Executable Load File and its Executable Modules information. Section GET STATUS Response Message Data Field is extended as follows: Tag Length Value Presence 'E3' Variable GlobalPlatform Registry related data '4F' 1-n AID '9F70' '01' Life Cycle State 'C5' '01' Application Privileges Conditional 'CE' 1-n Executable Load File Version Number Optional '84' 1-n First or only Executable Module AID Conditional... '84' 1-n Last Executable Module AID Conditional Table 9-23: GlobalPlatform Registry Data (TLV)

10 10 GlobalPlatform Card Specification /2004 Note: the Executable Load File Version Number format and contents are beyond the scope of this specification. It shall consist of the version information contained in the original Load File: on a Java Card based card, this version number represent the major and minor version attributes of the original Load File Data Block. A.4.2 Runtime Environment Version Number The Card/Chip Details data object (sub-tag 66 ) of Card Recognition Data provides information on the card and chip. The description of this data object is extended to include information pertaining to the operating system or runtime environment identification and its version number. Appendix F.2 Structure of Card Recognition Data is extended with the following precision: Note 6: Tag '66': this data object may contain information about the card and chip implementation, such as the operating system/runtime environment or a security kernel. Such information shall be TLV encoded and may consist of one (or more) OID(s), each OID being introduced by tag 06 and indicating the organization responsible for specifying the operating system, runtime environment or security kernel, the identification of the corresponding specification and its version number. A.4.3 GET STATUS Parameter P1 Extensions The possibility to execute a combined interrogation of the card contents is added to the GET STATUS command. The GET STATUS command reference control parameter P1 is extended with new values representing combination of existing values. Some of these combinations were already listed in version of GlobalPlatform Card Specification, i.e. values: E0, C0, A0, and 60. Please note that any combination including both values 20 and 10 is equivalent to a combination with value 10 only. Section GET STATUS Reference Control Parameter P1 is extended as follows: The following combination values of the reference control parameter may apply: 'E0' Issuer Security Domain, Applications, Security Domains and Executable Load Files. 'D0' Issuer Security Domain, Applications and Security Domains, Executable Load Files and their Executable Modules. 'C0' Issuer Security Domain, Applications and Security Domains. 'A0' Issuer Security Domain and Executable Load Files. '90' Issuer Security Domain, Executable Load Files and their Executable Modules. '60' Applications, Security Domains and Executable Load Files. '50' Applications, Security Domains, Executable Load Files and their Executable Modules.