1-Card Specification 2.1.1 Amendment A (SCP02-storedata)

______________________________
Card Specification 2.1.1

Amendment A
March 2004
Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of
this information is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is
strictly prohibited.
2 GlobalPlatform Card Specification 2.1.1 03/2004
Amendment A

The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform.
Use of this information is governed by the GlobalPlatform license agreement and any use inconsistent with that
agreement is strictly prohibited.
03/2004 GlobalPlatform Card Specification 2.1.1 3
Amendment A
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

The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this
information is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly
prohibited.
Amendment A
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 Amendment A is a set of optional extensions to the current Card
Specification version 2.1.1. These extensions provide support for the latest GlobalPlatform
Scripting Specification, EMV Card Personalization Specification (see http://www.emvco.com) and
Smart Card Platform TS 102.225 and TS 102.226 specifications (see http://www.etsi.org). 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
Description
number section number
A.1 sections 7.2.2 & 9.11 STORE DATA Command
A.3 sections 9.1.6, 9.3.2.2, Data Element Tags and Values Allocation
& 9.5.2.3.6
A.4 sections 9.4.2.1, Card and Application Management
9.4.3.1 & appendix F.2
A.2 appendices E.1.1 & Pseudo-Random Card Challenge
E.4.2

Amendment A
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 2.1.1 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 9.11.2.1 – 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 non-
encrypted 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 8825.
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.”

Amendment A
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 9.11.2.3 – 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 9.11.3.2 – 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

Amendment A
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 pre-
processing of the STORE DATA command by that Security Domain is not impacted by the new
optional STORE DATA command functionality.
Section 7.2.2 – 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 pre-
compute 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.1.2.2 - 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 off-
card 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),
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),
for C-MAC session, 3 Secure Channel Keys, well-known pseudo-random algorithm (card
challenge).”

Amendment A
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:
encryption, 1 Secure Channel base key, unspecified card challenge generation method,
encryption, 3 Secure Channel Keys, unspecified card challenge generation method,
for C-MAC session, 1 Secure Channel base key, unspecified card challenge generation
method,
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 102.226
and GSM 03.48 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 9.3.2.2 – 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 102.226 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 9.5.2.3.6 – 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 102.226 specific parameter Optional
'EA' Variable TS 102.226 specific template Optional
Table 9-35: Install Parameter Tags

Amendment A
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 102.225 specification.
Table 9-10 of section 9.1.6 – Key Type Coding is extended as follows:
Value Meaning
'00'-'7F' Reserved for private use
'80' DES – mode (EBC/CBC) implicitly known
'81' Reserved (triple DES)
'82' Triple DES in CBC mode
'83' DES in ECB mode
'84' DES in CBC mode
'85'-'9F’ RFU (symmetric algorithms)
'A0' RSA Public Key - public exponent e component (clear text)
'A1' RSA Public Key - modulus N component (clear text)
'A2' RSA Private Key - modulus N component
'A3' RSA Private Key - private exponent d component
'A4' RSA Private Key - Chinese Remainder P component
'A5' RSA Private Key - Chinese Remainder Q component
'A6' RSA Private Key - Chinese Remainder PQ component
'A7' RSA Private Key - Chinese Remainder DP1 component
'A8' RSA Private Key - Chinese Remainder DQ1 component
'A9'-'FE' RFU (asymmetric algorithms)
'FF' 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 9.4.3.1 – 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)
Amendment A
“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 2.0.1 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 9.4.2.1 – 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.”


1-Card Specification 2.1.1 Amendment A (SCP02-storedata)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1-Card Specification 2.1.1 Amendment A (SCP02-storedata)

Uploaded by

Copyright:

Available Formats

______________________________

Card Specification 2.1.1

Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

A.1 STORE DATA Command

A.1.1 Reference Control Parameter P1

Table 9-62: STORE DATA Reference Control Parameter P1

Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

A.1.3 Response Message Processing State

SW1 SW2 Meaning

Table 9-63: STORE DATA Error Condition

Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

A.1.4 Command Pre-Processing

A.2 Pseudo-Random Card Challenge

A.2.1 Secure Channel Protocol ‘02’ Pseudo-Random Card Challenge

A.2.2 Secure Channel Protocol ‘02’ Options Identifier

Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

A.3 Data Element Tags and Values Allocation

A.3.1 Data Element Tags

Tag Length Value (Name) Presence

Table 9-35: Install Parameter Tags

Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

A.4 Card and Application Management

A.4.1 Executable Load File Version Number

Tag Length Value Presence

A.4.2 Runtime Environment Version Number

A.4.3 GET STATUS Parameter P1 Extensions

Copyright  2004 GlobalPlatform Inc. All Rights Reserved.

You might also like