____________________________________
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
i
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&A’s 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&A’s 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
2
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.
3
4
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.
5
6
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
7
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.
8
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.
9
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 Domain’s 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 Issuer’s privilege includes deleting any Security Domain, regardless of the Security Domain’s own privileges. In order to implement a Controlling Authority or card scheme policy, the Card Issuer’s 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 Domain’s 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
