You are on page 1of 30

____________________________________

Card Specifications 2.1.1 & 2.1


Frequently Asked Questions
December 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.

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

Table of Contents
1.

GENERAL ...........................................................................................................................................................1
Is GlobalPlatform Card Specification version 2.1.1 compatible with Java Card Specification version 2.2.1?......1
1.1
GlobalPlatform Data Elements...................................................................................................................1
1.2
Card Lifecycle and Application Lifecycle..................................................................................................1
How to mute a card? ..............................................................................................................................................1
What entities can initiate the transition from CARD_LOCKED back to SECURED? .........................................1
How can an application, via its Security Domain, use a Set Status command to lock itself? ................................1
1.3
Security Domain...........................................................................................................................................2
Can an Application share its Security Domain services with another Application which is not associated to that
Security Domain? ..................................................................................................................................................2
Can an extradited Application still access its previous Security Domain services? ..............................................2
May a Security Domain contain proprietary data? ................................................................................................2
1.4
Command/response (APDU).......................................................................................................................2
Can response data structures be split over get first / get next occurrence of the GET STATUS command?......2
What is the value for the Application Privileges of an Executable Load File in response to the GET STATUS
command?..............................................................................................................................................................3
What is the content of the Application production life cycle data in response to the SELECT command?.......3
Is it possible to add search criteria to the GET STATUS command?....................................................................3
Can the search criteria of the GET STATUS command be less than 5 bytes? ......................................................3
Can the key information for all the Secure Channel Keys be retrieved with a single GET DATA command?.....3
Are Logical Channels supported?..........................................................................................................................4
Is the support of the combined INSTALL[for install & make selectable] command optional? ............................4
1.5
Card Identification and Management........................................................................................................4
Can one define proprietary Issuer Identification Numbers? ..................................................................................4
Can Card Recognition Data indicate compliance to multiple specifications and standards?.................................4
What is the purpose of Card Recognition Data?....................................................................................................4
How is Card Recognition Data accessed? .............................................................................................................5
What is the minimum content of Card Recognition Data? ....................................................................................5
How is Card Recognition Data encoded for a GlobalPlatform compliant card? ...................................................6
How can Card Recognition Data be used by non GlobalPlatform cards?..............................................................6
How are Object Identifiers (OID) encoded? ..........................................................................................................7
1.6
Certification and licensing ..........................................................................................................................8
What is the evaluation process of GlobalPlatform 2.1 cards? ...............................................................................8
If an issuer wishes to issue GlobalPlatform smart cards, what registration or licensing is required by
GlobalPlatform Consortium?.................................................................................................................................8

2.

CARD CONTENT MANAGEMENT ................................................................................................................9


2.1
Loading and Installing ................................................................................................................................9
In the INSTALL [for Load] command, what does tag C6 represent? .................................................................9
Does tag C6 indicate the maximum size the load process is allowed to use? .....................................................9
In the INSTALL [for Load] command, what do tags C7 and C8 represent?....................................................9
What do tags C7 and C8 indicate during the load process?..............................................................................9
In the INSTALL [for Install] command, what do tags C7 and C8 represent? ................................................10
What do tags C7 and C8 indicate during the installation process?.................................................................10
What is the condition for the System Specific Parameters of the Load and Install Parameters? ......................10
Is it possible to create several Application Instances and related data from an Executable Module? .................10
2.2
Deletion .......................................................................................................................................................11
How to require a pre-authorization on the Delegated Deletion?..........................................................................11
How is the memory being managed in a GlobalPlatform card after an Application has been deleted? ..............11

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.

ii

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

12/2004

What is the difference between Application Deletion and Executable Load File Deletion? ...............................11
Are related Application instances also removed on deletion of the Executable Load File? ................................11
How upgrading from an older version of an application software?.....................................................................11
Is it possible to delete multiple objects in a single DELETE command? ............................................................11
Is deletion allowed when the card is in the Life Cycle State CARD_LOCKED? ...............................................12
2.3
Personalization...........................................................................................................................................12
Where to find Personalization related items? ......................................................................................................12
Why should the Card Recognition Data not exceed 127 bytes? ..........................................................................12
2.4
CVM............................................................................................................................................................12
Is the CVM Handler optional?.............................................................................................................................12
How to retrieve the status of the CVM? ..............................................................................................................12
How to reset the CVM Retry Counter?................................................................................................................12
How is the CVM length expressed for the BCD format? ....................................................................................13
3.

SECURITY.........................................................................................................................................................14
3.1
Secure Channel Protocol ...........................................................................................................................14
Does deleting a key from a set of Secure Channel keys reset the Secure Channel Sequence Counter? ..............14
What status words are included in R-MAC computation?...................................................................................14
What is the appropriate APDU command to terminate a Secure Channel Session?............................................14
What happens during a Secure Channel Session requiring secure messaging if an unsecured Get Data command
is sent to the card? ...............................................................................................................................................14
How many Secure Channel Protocols can be implemented on a card? ...............................................................15
What is the difference between the EXTERNAL AUTHENTICATE and BEGIN R-MAC SESSION
commands? ..........................................................................................................................................................15
What is the difference between the Secure Channel Protocol S_ENC and DEK keys? ......................................15
How is the Sequence Counter managed for Secure Channel Protocol 02 in the Explicit Initiation mode? ......15
How to include the APDU command message in the R-MAC computation of Secure Channel Protocol 02? .16
How to include the status words in the R-MAC computation of Secure Channel Protocol 02? .......................16
What is the algorithm for computing the R-MAC? .............................................................................................16
3.2
Key Management .......................................................................................................................................16
Can a PUT KEY command contain key data fields with and without key check values? ...................................16
How is a new key added to a Security Domain with no initial key?....................................................................16
What is key diversification data?.........................................................................................................................17
What are the attributes of the Initial Key(s)?.......................................................................................................17
What are the values acceptable for Key Identifiers and Key Version Numbers? ................................................17
Are application keys deleted when the application instance is deleted?..............................................................17
3.3
Cryptographic Algorithms........................................................................................................................18
Is 'Sensitive Data Encryption' applied before or after securing the command and response messages, e.g. with a
C-MAC? ..............................................................................................................................................................18
Is data padding performed by the sensitive data encryption and decryption services of a Security Domain?.....18
3.4
Tokens and Receipts ..................................................................................................................................18
Does the data length byte indicator include the Token length when computing a Token?..................................18
3.5
Other Security............................................................................................................................................18
How to trace and log events on a GlobalPlatform card?......................................................................................18

4.

API ......................................................................................................................................................................19
4.1
Java Card ...................................................................................................................................................19
What Life Cycle State transitions does the setCardContentState() method accept? ............................................19
How to set the CVM Retry Limit with the Deprecated Java Card API?..............................................................19
What is the CVM format in the Deprecated API? ...............................................................................................19
How to set the sOffset and sLength parameters of the unwrap() method? ..........................................................19
What is the behavior of the unwrap() method if the Security Level is AUTHENTICATED and the Class byte of
the command indicates secure messaging?..........................................................................................................19

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.

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

iii

Does a failure in decryptData() processing lead to the closure of the current open Secure Channel Session?....20
What are the parameters of the Application.processData() method when a Security Domain forwards an APDU
to the Application?...............................................................................................................................................20
Can an Application use the getSecurityLevel() method during its processing of the processData() method?.....20
Can an Application use the decryptData() or encryptData() methods when a Secure Channel Session is not
opened?................................................................................................................................................................20
What is the full name of the Deprecated GlobalPlatform Java Card API package? ............................................20
How long will the deprecated API for Java Card be supported? .........................................................................20
How are the exceptions of the CVM interface handled? .....................................................................................21
4.2
Other API ...................................................................................................................................................21
Is there an API between Security Domains and OPEN e.g. for DAP verification? .............................................21
5.

CONFIGURATION AND SECURITY POLICIES .......................................................................................22


Policy for Error Codes .........................................................................................................................................22
Policy for Key Identification ...............................................................................................................................22
Policy for Load File Data Block Hash Verification.............................................................................................22
Policy for Security Domain Deletion...................................................................................................................22
Policy for Extradition ..........................................................................................................................................23
Policy for Velocity Checking ..............................................................................................................................23
Policy for Receipts generation.............................................................................................................................23
Policy for DAP Verification ................................................................................................................................23
Policy for APDU Minimum Security Requirements ...........................................................................................23
Policy for loading Public Key values ..................................................................................................................24
Policy for Key Check Values...............................................................................................................................24
Policy for Secure Channel Key(s) identification .................................................................................................24
Policy for Secure Content Management Key(s) identification ............................................................................24

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.

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

12/2004

This release of the Frequently Asked Questions List applies to both versions 2.1.1 and 2.1 of
GlobalPlatform Card Specification. In order to keep this List to a reasonable size, few Q&As
from the version 2.1 FAQ List dated October 2002 were removed when exhaustively addressed in
version 2.1.1 of the specification. Also a couple of Q&As of that version 2.1 FAQ List have been
updated in the version 2.1.1 & 2.1 FAQ List dated October 2003 to reflect the new possibilities
introduced in version 2.1.1 of the specification.
Note: the latest Questions and Answers of this December 2004 List are in blue characters.

1.

General

Is GlobalPlatform Card Specification version 2.1.1 compatible with Java Card Specification
version 2.2.1?
Yes, GlobalPlatform Card Specification version 2.1.1 maintains the same level of compatibility
with the Java Card platform specification version 2.2.1 as it does with the Java Card platform
specification version 2.2. Changes made in the Java Card platform specification, version
2.2.1 do not affect compatibility with Global Platform Card Specification version 2.1.1. For
more information regarding the Java Card platform specification version 2.2.1, see
http://java.sun.com/products/javacard.

1.1

GlobalPlatform Data Elements

(None)

1.2

Card Lifecycle and Application Lifecycle

How to mute a card?


The difference between GlobalPlatform Card Specification 2.0.1 and GlobalPlatform Card
Specification 2.1 is that version 2.1 of the specification does not cause a card to become
mute. The card life cycle state Terminated defined in section 6.7.3 Card Termination
disables any communication to and from the card besides the GET DATA command,
processed by the Issuer Security Domain.

What entities can initiate the transition from CARD_LOCKED back to SECURED?
The Issuer Security Domain can initiate the transition from CARD_LOCKED back to
SECURED. This is explained in section 5.1.1 Card Life Cycle States.

How can an application, via its Security Domain, use a Set Status command to lock itself?
This feature is not available in the GlobalPlatform Card Specification 2.1 version. According to
section 5.3.1.3 Application Life Cycle State LOCKED, only the Issuer Security Domain or the
OPEN can lock an Application. Allowing a Security Domain to lock one of its Applications or
the Application to lock itself may be addressed in a future release of the Specification.

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.

1.3

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

Security Domain

Can an Application share its Security Domain services with another Application which is not
associated to that Security Domain?
The current version of GlobalPlatform Card Specification requires that the OPEN controls an
Application request to access Security Domain services to the Applications associated with
that Security Domain. It does not preclude the Application associated to that Security Domain
and authorized to access that Security Domain services to share those with another
Application (even not associated to that Security Domain). In other words, if Application A is
associated with Security Domain SDa and Application B associated with Security Domain
SDb, A can access SDa services and share them with B.
Sharing mechanisms should be used with extra care by applications. For security reasons, it is
recommended that Card Issuers and Application Providers verify thoroughly application code
before authorizing its load onto a card, especially re: usage of sharing mechanisms.

Can an extradited Application still access its previous Security Domain services?
The OPEN controls an Application request to access Security Domain services to the
Applications currently associated with that Security Domain. The control mechanisms depend
on the underlying Run-Time Environment implementation. For instance, on a Java Card based
smart card, that control is performed when processing the getSecureChannel() method of the
org.globalplatform.GPSystem class (see Appendix A2 GlobalPlatform on a Java Card).
Once the reference to the Secure Channel object interface is obtained, no extra controls of the
Application identity are required by the GlobalPlatform Card Specification for executing a
method of the org.globalplatform.SecureChannel interface.
Applications for Java Card based smart cards should not store references to the Secure
Channel object interface. For consistency reasons, it is recommended that Card Issuers and
Application Providers verify thoroughly application code before authorizing its load onto a card
supporting Card Content Extradition, especially re: usage of Security Domain services.

May a Security Domain contain proprietary data?


A Security Domain may contain proprietary data. More information is available in section 9.3 Get Data Command and section 9.10 - Store Data Command.

1.4

Command/response (APDU)

Can response data structures be split over get first / get next occurrence of the GET STATUS
command?
The GET STATUS response data structures defined in tables 9-22 and 9-24 (see section
9.4.3.1 Data field returned in the GET STATUS response message) should not be split
across multiple GET STATUS commands, be it [get first or all occurrence(s)] or [get next
occurrence]. Note the TLV-coded response data structure defined in table 9-23 allows more
flexibility and may be split across multiple GET STATUS commands.

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.

12/2004

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

What is the value for the Application Privileges of an Executable Load File in response to the
GET STATUS command?
The Application Privileges byte in the GET STATUS response for Executable Load Files
(see Section 9.4.3.1 Data Field returned in the GET STATUS Response Message) should
be ignored by off-card systems, since Executable Load Files do not have such privileges. The
byte should be set to 00 in the response message. Please note this message structure
ensures full backward compatibility with the previous version of GlobalPlatform Card
Specification.

What is the content of the Application production life cycle data in response to the SELECT
command?
According to section 9.8.3.1 - Data Field returned in the SELECT Response Message,
Application production life cycle data (tag 9F6E) is an optional data element of the
SELECT response message. Its presence ensures backward compatibility with the previous
version of the Card Specification. Since this data element presence is optional and its
contents are not defined by version 2.1 of the specification, the data element may be not
supported by a GlobalPlatform compliant card.

Is it possible to add search criteria to the GET STATUS command?


Section 9.4.2.3 Data Field in the GET STATUS Command Message defines only one
mandatory search criteria: Application AID (tag 4F). Depending on the card implementation,
additional search criteria may be appended to the Application AID and included in the GET
STATUS command data field. In such case, the additional search criteria shall be TLV coded
and appended after the mandatory search criteria Application AID (tag 4F).
An additional search criteria, that was described in GlobalPlatform Card Specification 2.0.1, is
the Application Life Cycle Status (tag 9F70). An example of use would be to search all
Applications and Security Domains (if any) that are in the Life Cycle State SELECTABLE on
the card. In such example, the data field of the GET STATUS command would be coded as
follows: 4F 00 9F70 01 07.

Can the search criteria of the GET STATUS command be less than 5 bytes?
Yes. The data field of the GET STATUS command contains the search qualifier that is TLV
coded (tag 4F-length-value) and can be of any length, see section 9.4.2.3 Data Field Sent
in the GET STATUS Command Message. Note that a tag of 4F and a length of zero indicate
a search for all the occurrences matching the selection criteria defined in the GET STATUS
command parameter P1 (e.g. Applications, Executable Load Files).

Can the key information for all the Secure Channel Keys be retrieved with a single GET DATA
command?
Yes. A GET DATA command with the Key Information Template (tag E0) retrieves all the key
information available for the currently selected Security Domain (including the Issuer Security
Domain). When a Security Domain contains multiple Secure Channel Keys, template E0
contains as many key information data objects (tag C0) as there are Secure Channel Keys,
see section 9.3.3.1 Data Field Returned in the GET DATA Response Message.

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.

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

Are Logical Channels supported?


Yes, as an option. As stated in section 3.2.1 GlobalPlatform environment (OPEN), Logical
Channels are supported in version 2.1.1 of GlobalPlatform Card Specification as an optional
feature. This was not the case in version 2.1 of the specification. See section 3 of
GlobalPlatform Card Specification 2.1.1 Release Notes for an exhaustive list of the impacts of
Logical Channels on the specification.

Is the support of the combined INSTALL[for install & make selectable] command optional?
No. The support of the combined INSTALL[for install & for make selectable] command is the
minimum requirement for a card to be compliant with GlobalPlatform Card Specification. The
support of the individual INSTALL[for install] and INSTALL[for make selectable] commands is
an option of the GlobalPlatform Card Specification 2.1. See section 9.5 INSTALL command
for further details.

1.5

Card Identification and Management

Can one define proprietary Issuer Identification Numbers?


Section 6.8.1 Issuer Identification Number of GlobalPlatform Card Specification version
2.1.1 (or 2.1) recommends using ISO/IEC 7812 numbering scheme and ISO registered
identification numbers. If your numbering scheme is not constrained to numeric characters
only, a solution is to follow ISO/IEC 7816-6 and set the first nibble to F indicating proprietary
identification numbers. Such solution avoids collisions with any ISO/IEC 7812 registered
identification numbers. Furthermore, it is recommended to indicate in the Card Identification
Scheme data element (sub-tag 63) of Card Recognition Data (tag 66) the OID of your
proprietary registration authority. This would avoid collisions with other proprietary numbering
schemes: see appendix F.2 Structure of Card Recognition Data note 3 for further
information.
In the case where your numbering scheme is constrained to numeric digits exclusively and the
F nibble could not be used, avoiding collisions between identification numbers requires to
indicate the OID of your proprietary registration authority in the Card Identification Scheme
data element of Card Recognition Data. In this case, the uniqueness of the Issuer
Identification Number is ensured by the concatenation of the registration authority OID (subtag 63) and the proprietary Issuer Identification Number (tag 42).

Can Card Recognition Data indicate compliance to multiple specifications and standards?
Yes, a card complying to multiple specifications and/or standards may indicate this in tag 60
of Card Recognition Data with supplementary Object Identifiers (OID) that may be constructed
as follows: {standard_organization specification_id version_number}.
In such a case, tag 60 includes multiple Object Identifiers (tag 06), each indicating the
specification (or standard) the card conforms to.

What is the purpose of Card Recognition Data?


GlobalPlatform, in conjunction with MAOSCO and the Java Card Forum, has devised a
scheme that allows an off-card system to discover how to work with a smart card of unknown
characteristics without having to resort to trial and error (which can be slow and unreliable).
The idea is that the card may divulge Card Recognition Data at any time (see appendix F.2Structure of Card Recognition Data for further details), and through it an off-card system can
learn how to work with the card.
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.

12/2004

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

How is Card Recognition Data accessed?


The method for accessing Card Recognition Data is as follows:
1. Use the SELECT FILE command (select by name) with no command data and with the
first or only occurrence option set. This selects the card management function on the
card, and where appropriate returns the identifier of the card management function for
subsequent use. Ignore any response status other than 61xx or 6Cxx.
2. Issue a GET DATA command as defined in ISO/IEC standard 7816-4 (i.e. with class byte
set to 00, see also section 9.3.2- GET DATA Command Message) for a data object with
tag 66, Card Data. (Note that this command only returns the value field of Card Data, not
its tag or length). Card Data, which is a constructed data object, TLV encoded as
described in ISO/IEC standard 7816-6, contains another constructed data object, Card
Recognition Data, tag 73, which provides details of the card and how to access it,
primarily for card management purposes.
3. Check that the Card Recognition Data data object contains the GlobalPlatform Card
Recognition Data Object Identifier introduced by tag 06. The Object Identifier (OID) value
for Card Recognition Data is: {globalPlatform 1}, that is: {1 2 840 114283 1}, or in
hexadecimal: 2A864886FC6B01.
4. If this fails, then trial-and-error is necessary, as the card does not support Card
Recognition Data.
Note that, in a future release of the specification, there may be a further option following step
1, but this relies upon obtaining a neutral AID for this purpose. The option would be that if
step 1 gave an error status other than 6Cxx, the SELECT FILE command should be issued
with the neutral AID, and any status other than 61xx or 6Cxx should be ignored.

What is the minimum content of Card Recognition Data?


Card Recognition Data should contain for any card, GlobalPlatform compliant or not, the
following minimum set of data objects:
Tag 73 identifying unambiguously Card Recognition Data by containing the Object
Identifier {globalPlatform 1}. This Object Identifier also identifies GlobalPlatform as the Tag
Allocation Authority for application tags within Card Recognition Data.
Application tag 0 (tag 60) identifying the Card Management Type and Version provided
by the card. The value field of this data object is an Object Identifier (OID), which is
typically based on the OID of the organization that operates the card management
scheme; for example, GlobalPlatform version 2.1, MULTOS version 5, or Scheme X
Proprietary Card Management version N.
Application tag 3 (tag 63) identifying the Card Identification Scheme. The value field of
this data object is an Object Identifier (OID), which is typically based on the OID of the
organization that operates the card identification scheme. This OID, when added as a
prefix to the local (scheme) card identifier, forms a globally unique card identifier. For
instance, if the card uses a data object Card Number which is unique within the card
identification scheme, then the concatenation OID | cardNumber can be used as a
globally unique identifier for the card.
Usage of tags defined in appendix F.2- Structure of Card Recognition Data shall comply to
the GlobalPlatform Card Specification. Application tags are allocated and defined by
GlobalPlatform who acts as the Tag Allocation Authority for Card Recognition Data.
Proprietary tags may be used to carry additional information.

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.

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

How is Card Recognition Data encoded for a GlobalPlatform compliant card?


Card Recognition Data shall be encoded according to appendix F.2- Structure of Card
Recognition Data. Taking an example of a GlobalPlatform 2.1 compliant card whose Issuer
Security Domain supports Secure Channel Protocol 01, this example shows the coding of
Card Recognition Data:
a) Universal tag 06: GlobalPlatform Tag Allocation Authority OID: {GlobalPlatform 1}
b) Application tag 0: GlobalPlatform Card Specification Version 2.1: {GlobalPlatform 2 2 1}
c) Application tag 3: GlobalPlatform Card Identification Scheme: {GlobalPlatform 3}
d) Application tag 4: GlobalPlatform Secure Channel Protocol (SCP) 01 with
Implementation Option i of 05: {GlobalPlatform 4 1 5} (1 being the decimal value of
SCP Identifier 01; 5 being the decimal value of SCP Option i = 05)
Coding (hexadecimal)
73
2E
06
07
2A864886FC6B01
60
0B
06
09
2A864886FC6B020201
63
09
06
07
2A864886FC6B03
64
0B
06
09
2A864886FC6B040105

Meaning
Tag for Card Recognition Data
Length of Card Recognition Data (46 bytes)
Tag for Object Identifier
Length of Object Identifier (7 bytes)
Object Identifier for {GlobalPlatform 1} or {1 2 840 114283 1} which
implicitly defines this as Card Recognition Data and GlobalPlatform as
the Tag Allocation Authority
Application tag 0: Card Management Type and Version
Length of Card Management Type and Version identifier (11 bytes)
Tag for Object Identifier
Length of Object Identifier (9 bytes)
Object Identifier for {GlobalPlatform 2 2 1} or {1 2 840 114283 2 2 1}
Application tag 3: Card Identification Scheme
Length of Card Identification Scheme identifier (9 bytes)
Tag for Object Identifier
Length of Object Identifier (7 bytes)
Object Identifier for {GlobalPlatform 3} or {1 2 840 114283 3}
Application tag 4: Secure Channel Protocol and Implementation Option
Length of Secure Channel Protocol and Option identifier (11 bytes)
Tag for Object Identifier
Length of Object Identifier (9 bytes)
Object Identifier for {GlobalPlatform 4 1 5} or {1 2 840 114283 4 1 5}

How can Card Recognition Data be used by non GlobalPlatform cards?


Taking an example of a fictitious card management Scheme X in Romania, the fictitious
Object Identifiers of this Scheme X example are:
Object identifier value
{1}
{12}
{ 1 2 642 }
{ 1 2 642 327 }
{ 1 2 642 327 1 }
{ 1 2 642 327 1 6 }
{ 1 2 642 327 2 }

Meaning
ISO
ISO member body
Romania
Scheme X
Scheme X Card Management
Scheme X Card Management Version 6
Scheme X Card Numbering Scheme

Example Card Recognition Data coding of this fictitious Scheme X is:


a) Universal tag 06: GlobalPlatform Tag Allocation Authority OID: {GlobalPlatform 1}
b) Application tag 0: Scheme X Card Management Version 6: {SchemeX 1 6}
c) Application tag 3: Scheme X Card Identification Scheme: {SchemeX 2}

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.

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

12/2004

Coding (hexadecimal)
73
1E
06
07
2A864886FC6B01
60
09
06
07
2A850282470106
63
08
06
06
2A8502824702

Meaning
Tag for Card Recognition Data
Length of Card Recognition Data (30 bytes)
Tag for Object Identifier
Length of Object Identifier (7 bytes)
Object Identifier for {GlobalPlatform 1} or {1 2 840 114283 1} which
implicitly defines this as Card Recognition Data and GlobalPlatform as
the Tag Allocation Authority
Application tag 0: Card Management Type and Version
Length of Card Management Type and Version identifier (9 bytes)
Tag for Object Identifier
Length of Object Identifier (7 bytes)
Object Identifier for {SchemeX 1 6} or {1 2 642 327 1 6}
Application tag 3: Card Identification Scheme
Length of Card Identification Scheme identifier (8 bytes)
Tag for Object Identifier
Length of Object Identifier (6 bytes)
Object Identifier for {SchemeX 2} or {1 2 642 327 2}

How are Object Identifiers (OID) encoded?


An Object Identifier (OID) is expressed as a series of integers, inside curly brackets and
separated by spaces, for example the GlobalPlatform OID: {1 2 840 114283}. Object
Identifiers are used widely to identify organizations, roles, pieces of equipment and other
objects. When used in messages, they are coded in binary as follows:
The first byte is calculated by multiplying the first integer of the OID by 40, and adding the
second digit.
Each subsequent integer in the OID is encoded in binary across a series of bytes. Only
the low-order 7 bits of each byte are used. The high order bit of each byte is then set to 1
for all except the last byte, where it is set to zero.
This is repeated for each integer, and then all the values are concatenated contiguously.
For example, these encoding rules applied to the GlobalPlatform OID give 2A864886FC6B,
that is:
Original
Value

hexadecimal
equivalent

12
(40x1)+2=42
840

2A
348

114283

1BE6B

binary value

binary base 128


(7 bits per byte)

11
01001000
1
10111110
01101011

0000110
1001000
0000110
1111100
1101011

binary base 128


with high order
bit set

hexadecimal
coding
2A

10000110
01001000
10000110
11111100
01101011

8648
86FC6B

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.

1.6

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

Certification and licensing

What is the evaluation process of GlobalPlatform 2.1 cards?


The GlobalPlatform Card Compliance Program for smart cards is now available, see
GlobalPlatform website at http://www.globalplatform.org/compliance.asp. The GlobalPlatform
Card Compliance Program contains: Card Compliance Packages defining the minimum
mandatory and optional functionality, a Card Test Plan specifying the functional tests to
perform, a Card Test Suite comprised of test scripts implementing the Card Test Plan, and a
Test Tool to execute the Card Test Suite. The GlobalPlatform Card Compliance Packages
cover all mandatory functionality and optional features as defined in GlobalPlatform Card
Specification version 2.1.

If an issuer wishes to issue GlobalPlatform smart cards, what registration or licensing is required
by GlobalPlatform Consortium?
None. There is no restriction and no license to sign for issuing and using GlobalPlatform
compliant smart cards.

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.

12/2004

12/2004

2.

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

Card Content Management

2.1

Loading and Installing

In the INSTALL [for Load] command, what does tag C6 represent?


Tag C6 refers to the non-volatile memory size for the application code see section 9.5.2.3.6
INSTALL [for load] and INSTALL [for install] Parameters of GlobalPlatform Card Specification
version 2.1.1 (or 2.1). The correct value for tag C6 depends on the underlying RTE and the
actual on-card implementation and hence may vary across different card vendors and different
card implementations. The exact procedure for estimating that correct value is outside the
scope of GlobalPlatform and unknown to the card.

Does tag C6 indicate the maximum size the load process is allowed to use?
According to section 9.5.2.3.6 INSTALL [for load] and INSTALL [for install] Parameters of
GlobalPlatform Card Specification version 2.1.1 (or 2.1), the code size indicated by tag C6 is
the minimum memory size requested to be available on the card for ensuring a successful
load process (assuming no other errors). In other words, the card may have more non-volatile
memory space available at the time of the load request, but not less if it accepts the load
request. Note that this memory space management is an optional function of GlobalPlatform
Card Specification. The intent is that, assuming an accurate estimation of the memory size
requirement, a load process requiring a smaller memory size would be ensured to be
successful (assuming no other errors), while a load process requiring a larger memory size
could not be ensured success.

In the INSTALL [for Load] command, what do tags C7 and C8 represent?


In the INSTALL [for Load] command, tags C7 and C8 refer to the non-volatile and volatile
memory sizes for the application data that will be required by subsequent application
installation(s), see section 9.5.2.3.6 INSTALL [for load] and INSTALL [for install] Parameters
of GlobalPlatform Card Specification version 2.1.1 (or 2.1). When present in the Load
Parameters, the data sizes indicated by tags C7 and C8 are the minimum memory sizes
requested to be available on the card for ensuring a successful load and installation process
as described in Figure 6-3 Load and Installation Flow Diagram (assuming no other errors).
The correct value for tags C7 and C8 depend on the underlying RTE, the actual on-card
implementation and the number of subsequent installations, and hence may vary across
different card vendors, different card implementations and different load and installation
processes. The exact procedure for estimating these correct values is outside the scope of
GlobalPlatform and unknown to the card.

What do tags C7 and C8 indicate during the load process?


According to section 9.5.2.3.6 INSTALL [for load] and INSTALL [for install] Parameters of
GlobalPlatform Card Specification version 2.1.1 (or 2.1), when present in the Load Parameters
of the INSTALL [for Load] command, tags C7 and C8 are intended to describe the minimum
non-volatile and volatile data memory sizes required by the subsequent installation of one (or
more) Application instance(s). In other words, the card may have more non-volatile and
volatile memory space available at the time of the load request, but not less if it accepts the
load request.
The check is performed by the OPEN only once: at the time of the load request, and not
performed again at the time of installation(s) note that this check is an optional function of
GlobalPlatform Card Specification. The intent is to avoid loading some application code for
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.

10

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

which Application(s) could not be installed due to a lack of available memory, hence providing
efficient card and application management procedures to off-card systems.

In the INSTALL [for Install] command, what do tags C7 and C8 represent?


In the INSTALL [for Install] command, tags C7 and C8 refer to the non-volatile and volatile
memory sizes for the application data that are allocated to the Application, see section
9.5.2.3.6 INSTALL [for load] and INSTALL [for install] Parameters of GlobalPlatform Card
Specification version 2.1.1 (or 2.1). When present in the Install Parameters, the data sizes
indicated by tags C7 and C8 are the maximum memory sizes allocated to the Application
during its entire life cycle on the card, including both its installation and runtime execution. The
correct value for tags C7 and C8 depend on the underlying RTE and the actual on-card
implementation, and hence may vary across different card vendors, different card
implementations and different installation and runtime execution processes. The exact
procedure for estimating these correct values is outside the scope of GlobalPlatform and
unknown to the card.

What do tags C7 and C8 indicate during the installation process?


According to section 9.5.2.3.6 INSTALL [for load] and INSTALL [for install] Parameters of
GlobalPlatform Card Specification version 2.1.1 (or 2.1), when present in the Install
Parameters of the INSTALL [for Install] command, tags C7 and C8 are intended to describe
the maximum non-volatile and volatile data memory sizes allocated to the Application being
installed for its entire life cycle on the card. In other words, the card may have more nonvolatile and volatile memory space available at the time of the installation request, but not less
if it accepts the installation request. Note this memory space may not be available in its
entirety at a later time since unused memory is not reserved for the Application.
This control of memory space usage is performed by the OPEN during the installation and
every execution of the Application note that this control is an optional function of
GlobalPlatform Card Specification. The intent is to avoid Applications using larger portions of
available memory, hence providing memory management and control procedures to off-card
systems.

What is the condition for the System Specific Parameters of the Load and Install Parameters?
In tables 9-32 Load Parameter Tags and 9-33 Install Parameter Tags, the System Specific
Parameters template shall be present: i.e. tag EF followed by a non-zero length indicator,
when one (or more) of the embedded data elements: Non-Volatile Code Space Limit, Volatile
Data Space Limit, Non-Volatile Data Space Limit (tags C6, C7, or C8) is present. For
further information on these system parameters, see section 9.5.2.3.6 INSTALL [for load]
and INSTALL [for install] Parameters.

Is it possible to create several Application Instances and related data from an Executable Module?
Yes. As described in section 3.5 Card Content and figure 3.2 Card Content Relationships,
more than one Application instance may be created from the same Executable Module. This
feature was already present in the GlobalPlatform Card Specification v2.0.1'. The
implementation is possible on a current Java Card based smart card. However note that, due
to Java Card restrictions no firewall is active between two Application instances of the same
Executable Module.

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.

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

12/2004

2.2

Deletion

How to require a pre-authorization on the Delegated Deletion?


This version of the GlobalPlatform Card Specification does not provide Tokens for Delegated
Deletion. See section 7.6.4 Delegated Deletion for further details. Deletion Tokens may be
addressed in a future release of the GlobalPlatform Card Specification.

How is the memory being managed in a GlobalPlatform card after an Application has been
deleted?
Physical memory management is beyond the scope of the GlobalPlatform Card Specification.
GlobalPlatform smart cards rely on an underlying runtime environment. Memory
defragmentation is a runtime environment feature, therefore GlobalPlatform Card Specification
section 6.4.2 Content Removal is silent on the subject. For instance, Java Card 2.1.2 doesn't
support defragmentation, therefore a scenario where total available space is large enough but
fragmented enough that a new load file cannot be loaded is quite possible.

What is the difference between Application Deletion and Executable Load File Deletion?
GlobalPlatform Card Specification section 6.4.2 Content Removal distinguishes 'Application
deletion' (which refers to Application instance and Application data, therefore EEPROM) from
'Executable Load File deletion' (which refers to application code that may reside in ROM or
EEPROM). Physical deletion only applies to 'Executable Load Files' and 'Application instances
and data' residing in EEPROM.

Are related Application instances also removed on deletion of the Executable Load File?
When simultaneous deletion is not supported, each Application instance has to be deleted
before the corresponding Executable Load File can be deleted: see section 6.4.2.2
Executable Load File Removal for further details. When simultaneous deletion is supported,
an Executable Load file and all its associated Application instances may be deleted with a
single DELETE command: see section 6.4.2.3 Executable Load File and related Application
Removal and section 9.2. DELETE command for further details. Simultaneous deletion is a
new optional feature of version 2.1.1.

How upgrading from an older version of an application software?


The GlobalPlatform Card Specification 2.1 does not include on-card application software
upgrades without loss of application data. The current version of the Specification only allows
deleting an Application and its corresponding Executable Load File followed by loading the
latest version of the Executable Load File and re-instantiating the Application. According to
section 6.4.2 Content Removal, deleting an Application instance, along with all its data, is
required before deleting its corresponding Executable Load File. On-card application software
upgrades may be addressed in a future release of the Specification.

Is it possible to delete multiple objects in a single DELETE command?


No. Only one object is deleted per DELETE command, except in case of keys where multiple
keys with the same Key Identifier (tag D0 in the command data field) or the same Key
Version Number (tag D2 in the command data field) may be deleted as described in section
9.2 DELETE command. The following known limitation is acknowledged: deletion of
Applications cross-referencing each other is not defined in GlobalPlatform Card Specification
2.1: such mechanism is beyond the scope of the current version of the Specification.

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.

11

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

12

Is deletion allowed when the card is in the Life Cycle State CARD_LOCKED?
No. According to section 5.1.1.4 - Card Life Cycle State CARD_LOCKED, all card content
functionality is prohibited when the card is in the Life Cycle State CARD_LOCKED, including
Application and Executable Load File removal.

2.3

Personalization

Where to find Personalization related items?


The GlobalPlatform Card Specification 2.1 defines a set of mandatory Data Elements in
section 9.10.2.3 Data field in the STORE DATA command message. Keys for Secure
Channel Protocols are detailed in Appendix C.1 Keys, Appendix D.2 Cryptographic Keys
for Secure Channel Protocol 01, and Appendix E.2 - Cryptographic Keys for Secure Channel
Protocol 02. Personalization of other data elements is Issuer and/or Application Provider
specific and is not covered by the GlobalPlatform Card Specification.

Why should the Card Recognition Data not exceed 127 bytes?
The Card Recognition Data is defined in section 6.8.3 Card Recognition Data and further
refined in Appendix F.2 Structure of Card Recognition Data. The recommendation of coding
the length field on one byte is intended to express the need to keep this data as small as
possible

2.4

CVM

Is the CVM Handler optional?


Yes. According to section 6.1.3 CVM Handler, all CVM services described in the
specification are optional. For instance, when the CVM services are not available on a Java
Card based smart card, the getCVM()method of the class org.globalplatform.GPSystem shall
return a null reference, see Appendix A2 GlobalPlatform on a Java Card.

How to retrieve the status of the CVM?


The CVM status of the CVM service provided by Card Manager can be retrieve by any oncard Application using the GlobalPlatform API. For instance on a Java Card based smart card,
the following methods: isActive(), isSubmitted(), isVerified(), and isBlocked() of the interface
org.globalplatform.CVM are provided, see Appendix A2 GlobalPlatform on a Java Card.

How to reset the CVM Retry Counter?


The GlobalPlatform Card Specification 2.1 defines the CVM services in section 6.1.3 CVM
Handler and section 6.9 CVM Management. The CVM Handler is responsible for cardholder
verification velocity checking. The Applications use the GlobalPlatform API to request services
from the CVM Handler and reset the CVM Retry Counter. For instance on a Java Card based
smart card, the resetAndUnblockState() method of the interface org.globalplatform.CVM
defined in Appendix A2 GlobalPlatform on a Java Card resets the Retry Counter to the Retry
Limit value.

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.

12/2004

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

How is the CVM length expressed for the BCD format?


The CVM length is always defined in bytes regardless of the CVM format. For instance on a
Java Card based smart card, in the update() and verify() methods of the interface
org.globalplatform.CVM the bLength parameter reflects the length in bytes of the value given
in the parameter baBuffer (not the number of digits of the BCD format), see Appendix A2
GlobalPlatform on a Java Card.

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.

13

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

14

3.

Security

3.1

Secure Channel Protocol

Does deleting a key from a set of Secure Channel keys reset the Secure Channel Sequence
Counter?
In Secure Channel Protocol 02, deleting a key from a set of Secure Channel keys does not
impact the Secure Channel Sequence Counter associated to the key set. According to
appendix E.1.2 Secure Channel Protocol 02 Entity Authentication, only creating or updating
a key within a key set resets the associated Secure Channel Sequence Counter to zero.

What status words are included in R-MAC computation?


According to appendix E.4.5 - APDU Response R-MAC Generation and Verification, the
Status Words included in R-MAC calculation shall be appended by the application at the end
of the response data to be MACed (for a Java Card based smart card, at the end of the
baBuffer of the wrap() method, see Appendix A.2 GlobalPlatform on a Java Card).Are only
concerned the application-level Status Words, not the transport-level Status Words such as:
61 xx (number of bytes still available) of the T=0 protocol.

What is the appropriate APDU command to terminate a Secure Channel Session?


The appropriate APDU command terminating a Secure Channel Session may be a SELECT
command that is selecting another Application (see 3rd bullet of section 8.2.3 Secure
Channel Termination) or any other proprietary command of the currently selected Application
triggering the termination of the current Secure Channel Session through the use of the
appropriate GlobalPlatform API (e.g. resetSecurity() method of the
org.globalplatform.SecureChannel interface, see Appendix A.2 GlobalPlatform on a Java
Card).

What happens during a Secure Channel Session requiring secure messaging if an unsecured Get
Data command is sent to the card?
In Secure Channel Protocol 01 and Secure Channel Protocol 02 with Explicit Initiation
mode, one can initiate a Secure Channel Session with the following required Security Level:
AUTHENTICATION & C_MAC (and optionally C_DECRYPTION and/or R_MAC). According to
section 8.2.3 Secure Channel Termination, on reception of a command message without the
required secure messaging, the Secure Channel Session is terminated and the Security Level
reset to NO_SECURITY_LEVEL. Note that, on reception of a command message with an
incorrect secure messaging, the Secure Channel Session is terminated and the Security Level
reset to NO_SECURITY_LEVEL.
In Secure Channel Protocol 02 with Implicit Initiation mode, the required Security Level of a
Secure Channel Session is: AUTHENTICATION. Since the Secure Channel Session was
opened on reception of a command with a correct C-MAC, the current Security Level of the
Secure Channel Session is set to: AUTHENTICATION & C_MAC. On reception of a command
message without C-MAC, the Secure Channel Session Security Level is reset to
AUTHENTICATION and the Secure Channel Session remains open. Note that, according to
section 8.2.3 Secure Channel Termination, on reception of a command message with an
incorrect C-MAC, the Secure Channel Session is terminated and the Security Level reset to
NO_SECURITY_LEVEL.

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.

12/2004

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

How many Secure Channel Protocols can be implemented on a card?


According to section 4.3 Cryptographic support, the Issuer Security Domain shall implement
one Secure Channel Protocol. A Security Domain other than the Issuer Security Domain shall
also implement one Secure Channel Protocol, which may differ from the Secure Channel
Protocol of the Issuer Security Domain. Furthermore, different Security Domains may
implement different Secure Channel Protocols. Then, depending on the card implementation,
more than one Secure Channel Protocol may be available on a given card. Note that
Appendix F2 Structure of Card Recognition Data and Appendix F3 Security Domain
Management Data provide a means with Application Tag 4 (tag 64) for an off-card entity to
be aware of the Secure Channel Protocol supported by a Security Domain of a specific card.

What is the difference between the EXTERNAL AUTHENTICATE and BEGIN R-MAC
SESSION commands?
When P1 indicates R-MAC (P1 = 1x) in the EXTERNAL AUTHENTICATE command, the RMAC shall be computed and returned with all subsequent response messages of the current
Secure Channel Session, see Appendix E.5.2 EXTERNAL AUTHENTICATE CommandResponse APDU.
The BEGIN R-MAC SESSION command allows R-MACs to be computed for a subset of the
commands received in a Secure Channel Session, or even (for Secure Channel Protocol 02
in Implicit Initiation mode) outside any Secure Channel Session. It also gives a choice for
returning the R-MAC:

P1 indicates no secure messaging (P1 = 00), the R-MAC shall be computed with all
subsequent response messages and only returned with the END R-MAC SESSION
response message,

P1 indicates R-MAC (P1 = 10), the R-MAC shall be computed and returned with all
subsequent response messages,
see Appendix E.5.3 BEGIN R-MAC SESSION Command-Response APDU.

What is the difference between the Secure Channel Protocol S_ENC and DEK keys?
The S-ENC key is applicable to APDU command data field encryption/decryption and, in the
Explicit Initiation mode, Authentication Cryptogram. See Appendix D.3.4 APDU Data Field
Encryption and Decryption and Appendix D.3.2 Authentication Cryptograms for Secure
Channel Protocol 01. See Appendix E.4.6 APDU Data Field Encryption and Decryption and
Appendix E.4.2 Authentication Cryptograms in Explicit Secure Channel Initiation for Secure
Channel Protocol 02. Note that command message data field encryption and S_ENC key do
not apply to Secure Channel Protocol 02 in Implicit Initiation mode.
The DEK key is applicable to sensitive data encryption/decryption. See Appendix D.3.5 Key
Sensitive Data Encryption and Decryption for Secure Channel Protocol 01 and Appendix
E.4.7 Key Sensitive Data Encryption and Decryption for Secure Channel Protocol 02.

How is the Sequence Counter managed for Secure Channel Protocol 02 in the Explicit Initiation
mode?
According to Appendix E.4.2.1 Explicit Secure Channel Initiation, the Sequence Counter is
incremented when both the External Authenticate command MAC and the host cryptogram are
valid and successfully verified by the card; otherwise the Sequence Counter is not
incremented.

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.

15

16

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

How to include the APDU command message in the R-MAC computation of Secure Channel
Protocol 02?
The application should always call the unwrapping service of its associated Security Domain
on the incoming APDU command message, regardless of the existence or not of a Secure
Channel Session (C_MAC and/or C_DECRYPTION). The Security Domain shall know the
level of security involved in the current Secure Channel Session, e.g. having previously
processed either External Authenticate (P1 set to '1x') or Begin R-MAC Session commands.
When the security level is set to R_MAC, the Security Domain shall begin computing the RMAC with the command data and Lc received when processing the unwrapping services (for a
Java Card based smart card, see the unwrap() method of the interface org.globalplatform.
SecureChannel in Appendix A2 GlobalPlatform on a Java Card).
Once the response data is ready for transmission, the wrapping service shall then be called by
the application in order for the Security Domain to complete the computation of the R-MAC
(for a Java Card based smart card, see the wrap() method of the interface org.globalplatform.
SecureChannel in Appendix A2 GlobalPlatform on a Java Card).

How to include the status words in the R-MAC computation of Secure Channel Protocol 02?
Once the response data is ready for transmission, the wrapping service is called by the
application (for a Java Card based smart card, see the wrap() method of the interface
org.globalplatform.SecureChannel in Appendix A2 GlobalPlatform on a Java Card).
According to section E.4.5 - APDU Response R-MAC Generation and Verification, the Status
Words are included in R-MAC calculation and shall be appended by the application at the end
of the response data to be MACed in order for the Security Domain to compute properly the RMAC (for a Java Card based smart card, at the end of the baBuffer of the wrap() method).

What is the algorithm for computing the R-MAC?


The algorithm for computing the R-MAC in Secure Channel Protocol 02 is identical to the one
used for the C-MAC generation: the Retail MAC, see Appendix B.1.2.2 - Single DES Plus
Final Triple DES MAC.

3.2

Key Management

Can a PUT KEY command contain key data fields with and without key check values?
No. According to section 9.8.3.1.1 format 1 of the data field returned in the PUT KEY
response message (section 9.7.3.1.1 for version 2.1), the response message for a PUT KEY
command with key check values contains the new Key Version Number followed by the
verified key check values in the order the keys were received, without any key check value
length indicators. Since the response message structure cannot distinguish keys received with
key check values and keys without, such a PUT KEY command should be rejected by the card
with an error code such as Invalid key check value (i.e. 9485).

How is a new key added to a Security Domain with no initial key?


Adding a new key to a Security Domain with no initial key is performed using the PUT KEY
command described in section 9.8 PUT KEY command (section 9.7 for version 2.1). In this
case, the Issuer Security Domain plays the role of Security Domain for other Application
Providers Security Domains. For an Application Provider Security Domain with no initial key,
its initial secret key(s) shall be encrypted using the Issuer Security Domains Secure Channel
DEK key (for Secure Channel Protocol 01) or DEK session key (for Secure Channel Protocol
02).
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.

12/2004

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

What is key diversification data?


Typically, smart card schemes diversify the static keys (e.g. the Secure Channel Keys listed in
Appendix D.2 Cryptographic Keys) that are loaded on any smart card, so that a security
breach in one card does not compromise the entire card base. Hence, the presence of key
diversification data in the INITIALIZE UPDATE response described in appendices D.4.1.6 and
E.5.1.6 INITIALIZE UPDATE Response message. Such information is specific to key
management and card management schemes: for example, it may be a unique card identifier
allowing the off-card system to identify and/or compute which static keys a particular card
carries. In summary, it is an operational technique to avoid storing in an off-card database as
many sets of keys as cards are issued, which may potentially be millions.

What are the attributes of the Initial Key(s)?


The Initial Key(s) is(are) intended to support the Secure Channel Protocol of the Issuer
Security Domain as soon as the card is in the OP_READY state, see section 5.1.1.1 Card
Life Cycle State OP_READY. The number of Initial Key(s) is dependent of the Secure
Channel Protocol and eventually dependent of additional card scheme and/or card issuer
specific requirements, e.g. 1 or 3 for Secure Channel Protocol 01 and 02. The Key Type of
the Initial Key(s) is dependent of the Secure Channel Protocol, e.g. Key Type 80 (DES) for
Secure Channel Protocol 01 and 02. The Initial Key(s) Key Identifier and Key Version
Number are outside the scope of GlobalPlatform Card Specification and ultimately depend on
card scheme and/or card issuer specific requirements.

What are the values acceptable for Key Identifiers and Key Version Numbers?
According to section 6.8.4 On-card Key Information, there is no restriction for attributing
values to Key Identifiers and Key Version Numbers. Key Identifiers and Key Version Numbers
shall be coded on one byte according to table 9.17 Key Information Data Structure of section
9.3.3 Get Data Response Message. Any value between 00 and FF may be attributed by a
key management scheme for a specific key.
Use of the PUT KEY command brings some restrictions on the acceptable value ranges.
When using the PUT KEY command to add or replace a key on the card, the Key Version
Number shall have a value between 01 and 7F and the Key Identifier a value between 00
and 7F, see section 9.7.2 PUT KEY Command Message. Note that some keys may be
loaded by other means, e.g. the very initial key that is loaded prior to the Card Life Cycle State
OP_READY (see section 5.1.1.1 Card Life cycle State OP_READY).

Are application keys deleted when the application instance is deleted?


According to section 6.4.2.1 Application Removal, Application keys are to be handled like
any other Application data and be deleted when the Application instance is deleted, i.e. the
corresponding memory space is reclaimed.

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.

17

18

3.3

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

Cryptographic Algorithms

Is 'Sensitive Data Encryption' applied before or after securing the command and response
messages, e.g. with a C-MAC?
Appendix D.3.5 Key Sensitive Data Encryption and Decryption states for Secure Channel
Protocol 01 that the encrypted key data becomes part of the clear text data field in the
command message. Similarly, appendix E.4.7 - Sensitive Data Encryption and Decryption
states for Secure Channel Protocol 02 that the encrypted data becomes part of the clear
text data field in the command message. This means that sensitive data encryption is applied
first in both Secure Channel Protocols 01 and 02. The resulting encrypted data becomes
part of the command data field. Any C-MAC calculation according to appendix D.3.3 APDU
command C-MAC generation and verification or appendix E.4.4 APDU command C-MAC
generation and verification, R-MAC calculation according to appendix E.4.5 - APDU response
R-MAC generation and verification, and command data encryption according to appendix
D.3.4 - APDU command data field encryption and decryption or appendix E.4.6 - APDU
command data field encryption and decryption are performed on the result of the sensitive
data encryption.

Is data padding performed by the sensitive data encryption and decryption services of a Security
Domain?
In the current version 2.1 of the GlobalPlatform Card Specification, both Secure Channel
Protocols 01 and 02 do not define any padding scheme for sensitive data encryption and
decryption services. Therefore, a Security Domain, providing the services of Secure Channel
Protocol 01 or 02, does not discard any data of the decrypted text data (unaware if any
padding is present) when processing the sensitive data decryption service (for a Java Card
based smart card, see the decryptData() method of the interface org.globalplatform.Secure
Channel in Appendix A2 GlobalPlatform on a Java Card).
Similarly, a Security Domain, providing the services of Secure Channel Protocol 01 or 02,
does not apply any padding data to the clear text data prior to encryption when processing the
sensitive data encryption service (for a Java Card based smart card, see the encryptData()
method of the interface org.globalplatform.SecureChannel in Appendix A2 GlobalPlatform
on a Java Card).

3.4

Tokens and Receipts

Does the data length byte indicator include the Token length when computing a Token?
According to tables C-3, C-4 and C-5 in appendix C3 Tokens of GlobalPlatform Card
Specification version 2.1.1 (or 2.1), the length byte indicator after the Reference control
Parameter P2 does not include the Token length when computing a Token: it includes all the
other Install command data parameters. This length byte indicator is then replaced with the
final Lc byte of the INSTALL command, which obviously includes the Token.

3.5

Other Security

How to trace and log events on a GlobalPlatform card?


The detailed implementation for tracing and logging events is not covered by this version of
the GlobalPlatform Card Specification. Section 6.7.5 Tracing and Event Logging describes it
as an optional feature. It may be completed in a future release of the Specification.
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.

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

12/2004

4.

API

4.1

Java Card

What Life Cycle State transitions does the setCardContentState() method accept?
The setCardContentState() method accepts any transition of Application Life Cycle States,
including to the same state, other than transitions to and from the INSTALLED or LOCKED
states. Appendix A.2 of GlobalPlatform Card Specification version 2.1.1 (or 2.1) specifies that
the OPEN shall reject any transition request to the Life Cycle States INSTALLED or
LOCKED, while transitions from these two states are controlled by the Issuer Security
Domain or associated privileged Security Domain: see Figure 5-2 in section 5.3.1 of the
specification. Otherwise, as stated in section 5.3.1.5 of the specification, the OPEN does not
enforce any control on Application specific Life Cycle State transitions.

How to set the CVM Retry Limit with the Deprecated Java Card API?
There shall be a default value for the CVM Retry Limit. The setting of this default value is
implementation specific.

What is the CVM format in the Deprecated API?


In the Deprecated API, the CVM format is transparent to the OPEN and considered by the
OPEN to be the HEX format: see section 6.9.2 CVM format. The CVM value is stored as is:
OPSystem.setPIN() method, and compared as is: OPSystem.verifyPIN() method of Appendix
A1 Deprecated GlobalPlatform Java Card API.

How to set the sOffset and sLength parameters of the unwrap() method?
The sOffset parameter gives the offset within the baBuffer of the class byte of the APDU
command message to unwrap. If the APDU starts at the beginning of baBuffer, sOffset will be
zero The sLength parameter is the full length of the APDU command message to unwrap,
including the APDU header and its data field (if any). Note the Le byte (if present) is not
included in sLength.

What is the behavior of the unwrap() method if the Security Level is AUTHENTICATED and the
Class byte of the command indicates secure messaging?
The unwrap() method of the org.globalplatform.SecureChannel interface will do no processing
of the incoming command if the Security Level is set to AUTHENTICATED only and the
Secure Channel is either Secure Channel Protocol 01 or 02 in explicit initiation mode: no
exception will be thrown regardless of the class byte of the command. However, in Secure
Channel Protocol 02 implicit initiation mode, if the Security Level is AUTHENTICATED only
and a command is received with the secure messaging bits in the CLA byte set (e.g.
CLA=0x84), then a new Secure Channel Session will be re-opened provided that a correct CMAC is present in the command message.

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.

19

20

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

Does a failure in decryptData() processing lead to the closure of the current open Secure Channel
Session?
According to section 8.2.3 Secure Channel Termination, the Secure Channel Session is
terminated as soon as the card receives the first APDU command with an erroneous
cryptographic protection: this only includes C-MAC verification and Command Data Field
encryption. Sensitive data encryption is not removed when unwrapping a command message
with the unwrap() method of the org.globalplatfor.SecureChannel interface. The application
still needs to decrypt the (encrypted) sensitive data using the decryptData() method. Sensitive
data encryption therefore is not seen as a cryptographic protection of the APDU command
message. A failure in decrypting (encrypted) sensitive data, i.e. a failure in processing
decryptData() method, shall not terminate the Secure Channel Session.

What are the parameters of the Application.processData() method when a Security Domain
forwards an APDU to the Application?
The APDU command forwarded by the Security Domain shall be unwrapped according to the
Security Level of the current Secure Channel Session. The baBuffer parameter is the APDU
buffer, the sOffset is set to zero, and the sLength is sent to the length of the unwrapped APDU
command message.

Can an Application use the getSecurityLevel() method during its processing of the processData()
method?
Yes. The APDU command forwarded by the Security Domain to the Application has been
unwrapped according to the Security Level of the current Secure Channel Session. The
Application may interrogate the current Security Level with the getSecurityLevel() method of
the interface org.globalplatform.SecureChannel. There is no restriction on the usage of the
SecureChannel interface while the processData() method of the interface
org.globalplatform.Application is executed. For instance, the decryptData() method may also
be called by the Application.

Can an Application use the decryptData() or encryptData() methods when a Secure Channel
Session is not opened?
No. A Secure Channel Session must be active in order for the Security Domain to correctly
process the decryptData() and encryptData() methods of the interface
org.globalplatform.SecureChannel, e.g. for deriving the DEK session key of Secure Channel
Protocol 02. If a Secure Channel Session is not opened prior to the methods being called by
an Application, an ISO exception Security Status Not Satisfied will be thrown.

What is the full name of the Deprecated GlobalPlatform Java Card API package?
The deprecated API for Java Card defined in Appendix A1 Deprecated GlobalPlatform Java
Card API allows backward compatibility with existing applications developed for
GlobalPlatform 2.0.1 cards. Its full package name is visa.openplatform.

How long will the deprecated API for Java Card be supported?
The deprecated API for Java Card defined in Appendix A1 Deprecated GlobalPlatform Java
Card API allows backward compatibility with existing applications developed for
GlobalPlatform 2.0.1 cards. It will remain valid at least until the next release of the
GlobalPlatform Card Specification. Note that its presence on-card is optional.

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.

12/2004

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

How are the exceptions of the CVM interface handled?


On a Java Card based smart card, when processing any method of the interface
org.globalplatform.CVM, all exceptions are caught internally by the CVM interface method
which returns a boolean status set to false.

4.2

Other API

Is there an API between Security Domains and OPEN e.g. for DAP verification?
The GlobalPlatform Card Specification 2.1 section 7.5 DAP Verification and section 7.6
Delegated Management do not include a definition of an API between OPEN (or OP Registry)
and Security Domains. Section 7.1 Overview of the Application Providers Security Domains
explicitly states in its last paragraph that the current version of the specification does not
define such an API. However such an API may be considered in a future release of the
GlobalPlatform Card Specification.

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.

21

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

22

5.

Configuration and Security Policies

The GlobalPlatform Card Specification offers many choices to Card Issuers and Application
Providers for selecting options and implementing features left open in the specification. Following
is a list of such options and features available to Card Issuers and Application Providers choices.

Policy for Error Codes


According to the specification, a GlobalPlatform command may either return a general error
code (see section 9.1.3 General Error Conditions) or one of the more precise error codes
specified for each command (see the different sections 9.x.3.2 - Processing State Returned in
the Response Message, where x = 2 to 10). Error codes specified in the Card Specification
are recommended. Individual issuers and card schemes may define specific additional error
codes. These specific error codes shall comply with ISO 7816-4 rules. Off-card entities are
required to accept such specific codes and discriminate between errors and successful card
processing: they are not required to interpret these specific codes.
A configuration policy for defining specific error codes complying to ISO 7816-4 rules may be
defined and implemented on-card for each Security Domain, including the Issuer Security
Domain.

Policy for Key Identification


According to Errata & Precisions List 0.3 July 2002 expanding section 9.7.1 PUT KEY
Command Definition and Scope, a key may be replaced with the same key identification
attributes: Key Identifier and Key Version Number. Note this possibility was present in version
2.0.1 of GlobalPlatform Card Specification.
A configuration policy for accepting (or rejecting) a key replacement with identical key
identification attributes must be defined and enforced on-card for each Security Domain,
including the Issuer Security Domain.

Policy for Load File Data Block Hash Verification


According to Errata & Precisions List 0.3 July 2002 expanding section 9.5.2.3.1 Data Field
for INSTALL [for load], a Load File Data Block Hash present in the INSTALL [for load]
command may be systematically verified by the OPEN, beyond Delegated Management and
DAP Verification cases.
A configuration policy for systematically verifying (or not) a Load File Data Block Hash present
in the INSTALL [for load] command must be defined and implemented on-card for the OPEN.

Policy for Security Domain Deletion


The Card Issuer is allowed, once authenticated by the Issuer Security Domain, to delete any
Application present on the card (see section 6.4.2 Content Removal). This Card Issuers
privilege includes deleting any Security Domain, regardless of the Security Domains own
privileges. In order to implement a Controlling Authority or card scheme policy, the Card
Issuers deletion privilege may be limited to exclude specific categories of Security Domain
such as those with DAP Verification or Mandated DAP Verification privilege.
A security policy for limiting (or not) Security Domains deletion must be defined and enforced
on-card for the OPEN.

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.

12/2004

12/2004

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

Policy for Extradition


According to section 7.1 Security Domains Overview, a Security Domain may accept or
reject Extradition request, see also section 6.4.3 Content Extradition. Extradition acceptance
criteria are not defined in the GlobalPlatform Card Specification.
A configuration policy for accepting (or rejecting) Extradition requests must be defined and
enforced on-card for each Security Domain.

Policy for Velocity Checking


Section 6.7.4 Operational Velocity Checking recommends the use of velocity checks
regarding Card Content load and installation, memory allocation, and exceptions. Other
velocity checks may also be implemented regarding for instance key usage, see section 6.8.4
On-card Key Information. Actions to be taken in case of violation are not defined in the
GlobalPlatform Card Specification: they may encompass locking an Application, locking a key,
locking or terminating the card.
A security policy for Velocity Checking operations must be defined and enforced on-card for
the OPEN as well as each Security Domain, including the Issuer Security Domain..

Policy for Receipts generation


According to section 6.5 Delegated Management, the Card Issuer security policy may
require the generation of Receipts for Delegated Card Content Management (see also
appendix C.4 Receipts).
A configuration policy for generating Receipts (or not) must be defined and implemented oncard for the Issuer Security Domain.

Policy for DAP Verification


According to appendix C.5 DAP Verification, a Security Domain with DAP Verification
privilege may implement either a PKCS scheme or a DES scheme for verifying a Load File
Data Block Signature (see also appendix C.1.2 Secure Content Management Security
Domain Keys).
A configuration policy defining the DAP Verification algorithm must be set up and implemented
on-card for each Security Domain supporting DAP Verification.

Policy for APDU Minimum Security Requirements


The GlobalPlatform Card Specification defines some minimum security requirements for the
APDU commands defined in the specification, see table 9.2 Minimum Security
Requirements for GP Commands, table D.2 Minimum Security Requirements for SCP 01
Commands, and table E.4 Minimum Security Requirements for SCP 02 Commands. A
Card Issuer or an Application Provider may define its own security policy for some (or all) of
the APDU commands defined in the specification. For instance, a Card Issuer (or Application
Provider) security policy may be based on the Card Life Cycle State, e.g. higher security
requirements when the card is in the Life Cycle State SECURED.
A security policy for APDU commands (at least the one defined in tables 9-2, D-2, and E-4)
must be defined and enforced on-card for each Security Domain, including the Issuer Security
Domain.

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.

23

24

GlobalPlatform Card Specifications 2.1.1 & 2.1


FAQ Updated 12/04

Policy for loading Public Key values


According to section 9.7.2.3.3 PUT KEY Command Processing Rules, public key values
may be presented in clear text or encrypted form. The on-card receiving entity (e.g. a Security
Domain) is assumed to implicitly know which encryption policy to apply when processing the
PUT KEY command for public keys.
A configuration policy for encrypting (or not) public key values must be defined and enforced
on-card for each Security Domain, including the Issuer Security Domain.

Policy for Key Check Values


According to section 9.7.2.3.3 PUT KEY Command Processing Rules, before adding or
replacing keys, the on-card receiving entity (e.g. a Security Domain) is assumed to verify the
Key Check Value that is present in the PUT KEY command message. The Key Check Value
algorithm is not defined in the GlobalPlatform Card Specification.
A configuration policy defining both the required presence (or not) and the algorithm of the
Key Check Value verification must be set up and enforced on-card for each Security Domain,
including the Issuer Security Domain.

Policy for Secure Channel Key(s) identification


According to appendices D.3.1 Secure Channel Protocol 01 DES Session Keys and E.4.1
Secure Channel Protocol 02 DES Session Keys, session keys are created using the static
Security Domain Secure Channel Key(s). The (Issuer) Security Domain is assumed to
implicitly know how to identify its Secure Channel Key(s). When the set of Secure Channel
Keys comprises 3 keys, the (Issuer) Security Domain is also assumed to implicitly know how
to identify the S-MAC Key (i.e. appropriate S-MAC Key Identifier and Key Version Number) for
deriving the S-MAC Session Key, and similarly identify the S-ENC Key and eventually the
DEK Key.
A configuration policy for unambiguously identifying the Secure Channel Key(s) with the
appropriate Key Identifier(s) and Key Version Number must be defined and implemented oncard for each Security Domain, including the Issuer Security Domain.

Policy for Secure Content Management Key(s) identification


According to appendix C.1 Secure Content Management Keys, when Delegated
Management is supported, the Issuer Security Domain is assumed to implicitly know how to
identify its Token Verification Key and optional Receipt Generation Key. A Security Domain
supporting DAP Verification is also assumed to implicitly know how to identify its DAP
Verification Key.
A configuration policy for unambiguously identifying the Secure Content Management Keys
with the appropriate Key Identifiers and Key Version Numbers must be defined and
implemented on-card for the Issuer Security Domain supporting Delegated Management and
for each Security Domain supporting DAP Verification.

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.

12/2004