errata and precision list - card specification v2 -...

GlobalPlatform Card Errata and precision list - Card specification v2.2 Version 0.3

Card Specification Working Group 22 January 2009 Document Reference: GPC_EPR_009

Copyright © 2007 -2009 GlobalPlatform Inc. All Rights Reserved. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights or other intellectual property rights of which they may be aware which might be infringed by the implementation of the specification set forth in this document, and to provide supporting documentation. 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.

Errata and precision list - Card specification v2.2 2/26

Table of contents A. TABLE OF ERRATA AND PRECISIONS............................................................................................................ 3

E. ERRATA ................................................................................................................................................................... 5 E.1. INCLUSION OF IP CLAIM ...................................................................................................................................... 5 E.2. REFERENCE TO ETSI SPECIFICATION ................................................................................................................... 6 E.3. SECURITY DOMAIN HIERARCHY.......................................................................................................................... 6 E.4. SECURITY DOMAIN LIFE CYCLE TRANSITIONS .................................................................................................. 10 E.5. DELEGATED MANAGEMENT WITHIN A HIERARCHY ........................................................................................... 11 E.6. CARD CONTENT COMBINED LOADING, INSTALLATION AND MAKE SELECTABLE PROCESS............................... 17 E.7. OPEN BEHAVIOR FOR EXTRADITION................................................................................................................. 17 E.8. STORE DATA.................................................................................................................................................. 17 E.9. NUMBER OF EXECUTABLE MODULES ................................................................................................................ 18 E.10. TAG ‘D6’ CODE RESERVED MEMORY ............................................................................................................... 18 E.11. MPLICIT SELECTION PARAMETERS ..................................................................................................................... 18 E.12. API GPSYSTEM.APPLICATION_LOCKED.................................................................................................... 19 E.13. API GPSYSTEM.SETATRHISTBYTES() ............................................................................................................. 20 E.14. API APPLICATION.PROCESSDATA()................................................................................................................... 20 E.15. API SECURECHANNEL.UNWRAP() ..................................................................................................................... 20 E.16. API GPSYSTEM CONSTANT FAMILY_SERVICE_IDENTIFIER .................................................................... 21 E.17. DELETE TOKEN.................................................................................................................................................. 21 E.18. AID OF APPLICATION FOR CARD CHALLENGE ................................................................................................... 21 E.19. PUT KEY.......................................................................................................................................................... 21 E.20. NORMATIVE REFERENCES ................................................................................................................................. 22

P. PRECISIONS.......................................................................................................................................................... 24 P.1. PKCS#1 ............................................................................................................................................................ 24 P.2. SECURITY DOMAIN LIFECYCLE STATE LOCKED ............................................................................................. 24 P.3. SET STATUS TO LOCK/UNLOCK A SD HIERARCHY .......................................................................................... 25 P.4. STORE DATA COMMAND IN CASE OF EXCEPTION THROWN BY APPLICATION UNDER PERSONALIZATION....... 25 P.5. DATA GROUPING IDENTIFIER (DGI) CODING RULES .......................................................................................... 26

Copyright © 2007 -2009 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/26 Errata and precision list - Card specification v2.2

A.Table of Errata and Precisions The following table classifies all the Errata and Precisions of the different Errata and Precisions Lists released for the Card Specification v2.2 into a sequential order that reflects the Card Specification index. The latest Errata and Precisions are in blue characters.

Errata / Precision

Card Specification reference

Description

Introduction and Annex F Inclusion of IP claim E.1

E.2 section 1.5.4.4 Reference to ETSI specification

E.3 Sections 7.2, 9.3, 9.4 and 9.5

Security Domain Hierarchy

E.4 Section 5.3.2.6, Figure 5-3

Security Domain Life Cycle Transitions

E.5 Sections 9.1,9.3, 9.4, 9.5, Annex C.4,

Delegated Management within a hierarchy

E.6 Section 9.3.8 Card Content combined Loading, Installation and Make Selectable Process

E.7 Section 9.4.1 OPEN behavior for Extradition

E.8 Section 11.1.3.2, Table 11-82

STORE DATA response message

E.9 Section 11.4.3.2, Table 11-37

Number of Executable Modules

E.10 Section 11.5.2.3.7, Table 11-48

Tag 'D6' Code Reserved Memory

E.11 Section 11.5.3.2.7, Tables 11-49 and 11-50

Implicit Selection parameters

E.12 Annex A.1 API GPSystem.APPLICATION_LOCKED

E.13. Annex A.1 API GPSystem.setATRHistBytes()

E.14 Annex A.1 API Application.processData()

E.15 Annex A.1 API SecureChannel.unwrap()

E.16 Annex A.2.4.8 API GPSystem Constant FAMILY_SERVICE_IDENTIFIER

E.17 Annex C.4.1 Delete Token

E.18 Annex E.4.2.3 AID of Application for Card Challenge

E.19 Table 11-75 PUT KEY

Copyright © 2007-2009 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.



Errata / Card Specification Description Precision reference

E.20 Table 1-1 Normative References

P.1 Normative References, sections B.1, C.4, C.6.1

PKCS#1

P.2 Section 5.3.2.4 Security Domain Life Cycle State LOCKED

P.3 Section 11.10.2.1 SET STATUS to lock/unlock a SD hierarchy

P.4 Section 11.11.1 STORE DATA command in case of Exception thrown by Application under Personalization

P.5 General Data Grouping Identifier (DGI) coding rules


E. Errata

E.1. Inclusion of IP Claim

In the Introduction, the following paragraph is included:

“GlobalPlatform draws attention to the fact that it is claimed that compliance with this specification may involve the use of a patent or other intellectual property right (collectively, “IPR”) concerning asynchronous loading with asymmetric protocol SCP10 as described in annexe F.1.1.2. GlobalPlatform takes no position concerning the evidence, validity and scope of this IPR.

The holder of this IPR has assured GlobalPlatform that they are willing to agree to grant a license available under reasonable and non-discremonary terms (RAND) for the purpose of implementing this specification. In this respect, the statement of the holder of this IPR is registered with GlobalPlatform.

Information may be obtained from: StepNexus Inc, One Market Street, Spear Tower, Suite 3567, San Francisco, CA 94105, USA.

Attention is drawn to the possibility that some of the elements of Stepnexus Specification may be the subject of IPR other than those identified above. GlobalPlatform shall not be held responsible for identifying any or all such IPR, and has made no inquiry into the possible existence of any such IPR.”

Annex F is modified accordingly:

“F.1.1 SCP'10' Secure Channel

SCP'10' is a Secure Channel Protocol based on asymmetric cryptography and Public Key infrastructure (PKI).The Secure Channel Protocol operates between a Security Domain on the card (or the Issuer Security Domain) and an Off-Card Entity (OCE) which may be the Application Provider (or Card Issuer) or another party.

F.1.1.1 Synchronous Mode

The synchronous implementation of Secure Channel implementation of SCP'10' provides the following levels of security:

Authentication - in which the Security Domain authenticates the Off-Card Entity and the Off-Card Entity may authenticate the Security Domain. There are two aspects to this: Key Authentication which involves establishing mutual trust in each other's public key (PK); and Entity Authentication which involves establishing that the other party in the Secure Channel Session is authentic owner of that public key.

Integrity and data origin authentication - in which the Security Domain and the Off-Card Entity ensure that the data being received from the other entity actually came from its claimed source in the correct sequence and has not been altered.

Confidentiality - in which confidential data is not viewable by an unauthorized entity.

A further level of security applies to specific sensitive data (e.g. cryptographic keys) which may be encrypted using a mechanism that is not part of the Secure Channel Session security.

F.1.1.2 Asynchronous Mode

The asynchronous mode allows off-line pre-packaging of encrypted and signed content and provides the following levels of security:



Integrity and data origin authentication - in which the Security Domain confirms the public-key-signed signature of the supplied content. This ensures that the content being received from the other entity actually came from its claimed source in the correct sequence and has not been altered.

Confidentiality - in which confidential data is not viewable by an unauthorized entity. Confidential content is encrypted with the public key of the desired Security Domain.

F.1.2 initiating a Secure Channel”

…./...

E.2. Reference to ETSI specification

The reference to the ETSI specification is incorrect for Secure Channel Protocol ‘80’.

In section 1.5.4.4, the reference to the Secure Channel Protocol defined by ETSI Project Smart Card Platform shall be TS 102 225.

E.3. Security Domain Hierarchy

Version 2.2 of the Card Specification provides new functionality for creating and managing Security Domain hierarchies but the card content management operations described in sections 9.3, 9.4 and 9.5 are not fully backward compatible with versions 2.1 and 2.1.1 of the Card Specification. The Runtime Behavior requirements during loading, installation, make selectable, the combined load-install-make selectable, extradition, registry update and removal shall be updated.

In section 7.2 – Security Domain Association, the following sentence of the 5th paragraph is deleted: “It also makes it more isolated from other Security Domains, subject to the privileges assigned to those other Security Domains”.

Section 9.3.5 - Card Content Loading Process shall be modified as follows:

The 5th bullet point in the Load Request Runtime Behavior for the OPEN:

• “If an associated Security Domain AID is present, check that this AID exists within the GlobalPlatform Registry and is registered with the Security Domain privilege. As this equates to the extradition of the Load File, if the Security Domain performing the load is not directly or indirectly associated with the associated Security Domain, check that the associated Security Domain accepts this extradition. If no associated Security Domain AID is indicated, the Security Domain performing the load is by default the associated Security Domain;”

Shall be replaced by:

• “If an associated Security Domain AID is present and is not the Security Domain performing the load, check that this AID exists within the GlobalPlatform Registry and is registered with the Security Domain privilege. As this equates to the extradition of the Load File, check that the associated Security Domain accepts this extradition. If no associated Security Domain AID is indicated, the Security Domain performing the load is by default the associated Security Domain;”

And the following paragraph is added:

“At the request of OPEN, the associated Security Domain shall:

• Apply the Security Domain Provider's policy to accept or reject this load;

• Apply its own security policy, e.g. check that its Life Cycle State is PERSONALIZED (only applicable to a Security Domain other than the Issuer Security Domain);”



Section 9.3.6 - Card Content Installation Process shall be modified as follows:

The 6th bullet in the Runtime Behavior for the OPEN:

• “Check that the Security Domain performing the installation is the Security Domain associated with the Executable Module from which the Application is being installed; or if the Security Domain performing the installation is not the Security Domain directly or indirectly associated with the Executable Module from which the Application is being installed, check that the Security Domain associated with the Executable Load File accepts this installation;”

shall be replaced by:

• “If the Security Domain performing the installation is not the Security Domain associated with the Executable Module from which the Application is being installed, check that the Security Domain associated with the Executable Load File accepts this installation;



• Apply the Security Domain Provider's policy to accept or reject this installation;


Section 9.3.7 - Card Content Make Selectable Process shall be modified as follows:


• “Check that the Security Domain making the Application selectable is directly or indirectly associated with the Application;”


• “If the Security Domain making the Application selectable is not the associated Security Domain of the Application, check that the Security Domain associated with the Application accepts to make it selectable;”



• Apply the Security Domain Provider's policy to accept or reject making this Application selectable;


Section 9.3.8 - Card Content Combined Loading, Installation and Make Selectable Process shall be modified as follows:

The last bullet in the Runtime Behavior for the OPEN:

• “If an associated Security Domain AID is present, check that this AID exists within the GlobalPlatform Registry and is registered with the Security Domain privilege. As this equates to the extradition of the Load File, if the Security Domain performing the combined load, install and make selectable is not directly or indirectly associated with the associated Security Domain, check that the associated Security Domain accepts this extradition. If no associated Security Domain AID is indicated, the Security Domain performing the load is by default the associated Security Domain.”




• “If an associated Security Domain AID is present and is not the Security Domain performing the combined load, install and make selectable, check that this AID exists within the GlobalPlatform Registry and is registered with the Security Domain privilege. As this equates to the extradition of the Load File, check that the associated Security Domain accepts this extradition and combined load, install and make selectable operation. If no associated Security Domain AID is indicated, the Security Domain performing the load is by default the associated Security Domain.”



• Apply the Security Domain Provider's policy to accept or reject this combined load, install and make selectable operation;


Section 9.4.1 - Content Extradition shall be modified as follows:


• “If the Security Domain performing the extradition is not directly or indirectly associated with the Security Domain to which the Application or Executable Load File is being extradited, check that this Security Domain accepts this Card Content extradition;”


• “If the Security Domain performing the extradition is not the Security Domain to which the Application or Executable Load File is being extradited, check that this Security Domain accepts this Card Content extradition;”



• Apply the Security Domain Provider's policy to accept or reject this extradition;


Section 9.4.2 – Registry Update is modified as follows:


• “Check that the Security Domain requesting the registry update is directly or indirectly associated with the Application;”

is replaced by:

• “If the Security Domain requesting the registry update is not the associated Security Domain of the Application, check that the Security Domain associated with the Application accepts this registry update;”



• Apply the Security Domain Provider's policy to accept or reject this extradition;


Section 9.5.1 - Application Removal shall be modified as follows:




• “Check that the Security Domain performing the delete is the Security Domain directly or indirectly associated with the Application being deleted, or that it has Global Delete privilege. Otherwise (i.e. if the Security Domain performing the deletion is not directly or indirectly associated with the Application being deleted and does not have the Global Delete privilege), check that the Security Domain associated with the Application accepts this deletion;”


• “Check that the Security Domain performing the deletion is the associated Security Domain of the Application being deleted, or that it has Global Delete privilege. Otherwise (i.e. if the Security Domain performing the deletion is not associated with the Application being deleted and does not have the Global Delete privilege), check that the Security Domain associated with the Application accepts this deletion;”



• Apply the Security Domain Provider's policy to accept or reject this Application removal;


Section 9.5.2 - Executable Load File Removal shall be modified as follows:


• “Check that the Security Domain performing the delete is the Security Domain directly or indirectly associated with the Executable Load File being deleted, or that it has Global Delete privilege. Otherwise (i.e. if the Security Domain performing the deletion is not directly or indirectly associated with the Executable Load File being deleted and does not have the Global Delete privilege) check that the Security Domain associated with the Executable Load File accepts this deletion;”


• “Check that the Security Domain performing the deletion is the associated Security Domain of the Executable Load File being deleted, or that it has Global Delete privilege. Otherwise (i.e. if the Security Domain performing the deletion is not associated with the Executable Load File being deleted and does not have the Global Delete privilege) check that the Security Domain associated with the Executable Load File accepts this deletion;”



• Apply the Security Domain Provider's policy to accept or reject this Executable Load File removal;


Section 9.5.3 - Executable Load File and related Application Removal shall be modified as follows:

The 4th and 5th bullets in the Runtime Behavior for OPEN

• “Check that the Security Domain performing the delete is the Security Domain directly or indirectly associated with each of the related Applications being deleted, or that it has Global Delete privilege. Otherwise (i.e. if the Security Domain performing the deletion is not directly or indirectly associated with one or more of the Applications being deleted and does not have the Global Delete privilege) check in each case that the Security Domain associated with the related Application accepts this deletion;

• Check that the Security Domain performing the delete is the Security Domain directly or indirectly associated with the Executable Load File being deleted, or that it has Global Delete privilege.



Otherwise (i.e. if the Security Domain performing the deletion is not directly or indirectly associated with the Executable Load File being deleted and does not have the Global Delete privilege) check that the Security Domain associated with the Executable Load File accepts this deletion;”


• “Check that the Security Domain performing the deletion is the associated Security Domain of each of the related Applications being deleted, or that it has Global Delete privilege. Otherwise (i.e. if the Security Domain performing the deletion is not associated with one or more of the Applications being deleted and does not have the Global Delete privilege) check in each case that the Security Domain associated with the related Application accepts this deletion;

• Check that the Security Domain performing the deletion is the associated Security Domain of the Executable Load File being deleted, or that it has Global Delete privilege. Otherwise (i.e. if the Security Domain performing the deletion is not associated with the Executable Load File being deleted and does not have the Global Delete privilege) check that the Security Domain associated with the Executable Load File accepts this deletion;”



• Apply the Security Domain Provider's policy to accept or reject this Executable Load File and related Application removal;


E.4. Security Domain Life Cycle transitions

The transition from Selectable to Personalized is irreversible. In Section 5.3.2.6, the Figure 5-3, "Security Domain Life Cycle State Transitions", shall be replaced by the following diagram



INSTALLED

SELECTABLE

PERSONALIZEDLOCKED from

PERSONALIZED

Legend1. A Security Domain with Authorized Management privilege

2. A Security Domain with Delegated Management privilege

5. The Security Domain itself

LOCKED from INSTALLED

LOCKED fromSELECTABLE

1

2

2

1

3

4

5

3

4

5

3

4

5

5

3. The associated Security Domain

4. A Security Domain or Application with Global Lock privilege

E.5. Delegated Management within a hierarchy

It shall be possible for a Security Domain with the Authorized Management privilege to delegate the Card Content Management privilege to all of its descendant load files and applications. Within a sub-hierarchy starting from a Security Domain with the Authorized Management privilege, no more than one Security Domain may have the Token Verification privilege and no more than one Security Domain may have the Receipt Generation privilege.

Section 9.1.3.1 "Security Domain with Token Verification Privilege"

The first sentence,

“This privilege allows a Security Domain Provider, typically the Card Issuer, to authorize any Card Content management operation.”

shall be replaced by,



“The privilege allows a Security Domain Provider to authorize Card Content management operations. Starting from the Security Domain with the Authorized Management privilege, the Security Domain having the Token Verification privilege controls such authorization.

Note: Typically, the Token Verification privilege is assigned to a Security Domain with the Authorized Management privilege.”

The last sentence,

“In this version of the specification, one Security Domain with Token Verification privilege per card is assumed.”

shall be replaced by

“In this version of the specification, it is assumed that within a sub hierarchy starting from a Security Domain with the Authorized Management privilege, no more than one Security Domain may have the Token Verification privilege."

Section 9.1.3.2 "Security Domain with Authorized Management Privilege"

add the following as a new sentence at the end of the first paragraph,

“A Security Domain with the Authorized Management privilege may delegate the Card Content Management operation on its descendant load files and applications.”

Section 9.1.3.3 "Security Domain with Delegated Management Privilege"

The paragraph after the last bullet,

“The privilege allows an Application Provider to manage Card Content with authorization. The Security Domain that has Token Verification privilege controls such authorization.”


“The privilege allows an Application Provider to manage Card Content with authorization. Starting from the Security Domain with the Authorized Management privilege, the descendant Security Domain having the Token Verification privilege controls such authorization. In this version of the specification, it is assumed that the Security Domain with the Delegated Management privilege performs card content operations only within the sub-hierarchy starting from a Security Domain with the Authorized Management privilege.”

Section 9.1.3.6 "Security Domain with Receipt Generation Privilege",

The entire section,

“This privilege allows a Security Domain Provider, typically the Card Issuer, to provide a confirmation for the performed card content management. A Security Domain with Receipt Generation privilege requires the knowledge of keys and algorithms used for Receipts generation. It shall also keep track of a Confirmation Counter that is incremented when generating each Receipt. When reaching its maximum value, the Confirmation Counter shall not be reset to zero. Cards are not required to support counter values beyond 32767.

Note that this privilege does not provide Card Content management capability.

In this version of the specification, one Security Domain with Receipt Generation privilege per card is assumed.”


“This privilege allows a Security Domain Provider to provide a confirmation for a delegated card content management operation. Starting from the Security Domain with the Authorized Management privilege, the descendant Security Domain with the Receipt Generation privilege shall generate the receipt. It requires the knowledge of keys and algorithms used for Receipt generation. It shall also keep track of a Confirmation Counter that is incremented when generating each Receipt. When reaching its maximum value, the Confirmation Counter shall not be reset to zero. Security Domains are not required to support counter values beyond 32767.

Note that this privilege does not provide Card Content management capability.



In this version of the specification, it is assumed that within a sub-hierarchy starting from a Security Domain with the Authorized Management privilege, no more than one Security Domain may have Receipt Generation privilege."

Sections 9.3.2, 9.3.3 and 9.3.4,

The sentences,

“Receipt is to assist the Card Issuer in keeping its Card Management System synchronized with its card base.”


“Receipt is to assist the Application Provider in keeping its Card Management System synchronized with its on-card application base.”

Section 9.3.2 "Card Content Loading",

The fourth paragraph

“The Load Token allows the OPEN, via the Security Domain with Token Verification privilege, to ensure that the Token Issuer authorized the load process and the loading of the content of the Load File Data Block. (In this version of the specification, the Token Issuer is assumed to be the same as the Card Issuer.)”


“The Load Token allows the OPEN, via the Security Domain with the Token Verification privilege within the same sub hierarchy as the Security Domain performing the load, to ensure that the Token authorized the load process and the loading of the content of the Load File Data.”

Section 9.3.3 "Card Content Installation",

The third paragraph

“The Install Token allows the OPEN, via the Security Domain with Token Verification privilege, to ensure that the Card Issuer authorized the installation process.”


“The Install Token allows the OPEN, via the Security Domain with Token Verification privilege, within the same sub-hierarchy as the Security Domain performing the installation, to ensure that the Token authorized the installation process.”

Section 9.3.4 "Card Content Combined Loading, Installation and Make Selectable",

The 4th paragraph

“The combined Load, Install and Make Selectable Token allows the OPEN, via the Security Domain with Token Verification privilege, to ensure that the Token Issuer authorized the load process and the loading of the content of the Load File Data Block as well as the installation of an Application from the previously loaded Executable Load File. (In this version of the specification, the Token Issuer is assumed to be the same as the Card Issuer.)”


“The combined Load, Install and Make Selectable Token allows the OPEN, via the Security Domain with Token Verification privilege, within the same sub-hierarchy as the Security Domain performing the combined Load, Install and Make Selectable, to ensure that the Token authorized the load process and the loading of the content of the Load File Data Block as well as the installation of an Application from the previously loaded Executable Load File.”

Section 9.4.1 "Content Extradition",

The fifth paragraph

“The Extradition Token allows the OPEN, via the Security Domain with Token Verification privilege, to ensure that the Card Issuer authorized the extradition process.”




“The Extradition Token allows the OPEN, via the Security Domain with Token Verification privilege, within the same sub-hierarchy as the Security Domain performing the extradition, to ensure that the token authorizes the extradition process.”

The seventh paragraph

“The Application Provider may then forward the Extradition Receipt to the corresponding off-card entity as a proof that the extradition process was successfully performed. The purpose of the optional Extradition Receipt is to assist the Card Issuer in keeping its Card Management System synchronized with its card base.”


“The Application Provider may then forward the Extradition Receipt to the corresponding off-card entity as a proof that the extradition process was successfully performed. The purpose of the optional Extradition Receipt is to assist the Application provider in keeping its Card Management System synchronized with its on-card application base.”

Section 9.4.2.1 "Generic Registry Update"

The fourth paragraph

“The Registry Update Token allows the OPEN, via the Security Domain with Token Verification privilege, to ensure that the Card Issuer authorized the update of the GlobalPlatform Registry.”


“The Registry Update Token allows the OPEN, via the Security Domain with Token Verification privilege within the same sub-hierarchy as the Security Domain performing the Registry Update, to ensure that the token authorizes the update of the GlobalPlatform Registry.”

Section 9.4.2.1 "Generic Registry Update"

The sixth paragraph, the second sentence

“The purpose of the optional Registry Update Receipt is to assist the Card Issuer in keeping its Card Management System synchronized with its card base.”


“The purpose of the optional Registry Update Receipt is to assist the Application Provider in keeping its Card Management System synchronized with its on-card application base.”

Section 9.5 "Content Removal"

The fifth paragraph,

“The Application Provider may instruct the OPEN to delete its associated Applications and Executable Load Files. According to the Card Issuer's policies, the OPEN may require pre-authorization from the Card Issuer, i.e. a Delete Token may be required.”


“The Delete Token allows the OPEN, via the Security Domain with Token Verification privilege, within the same sub hierarchy as the Security Domain performing the Delete, to ensure that the token authorizes the deletion of the associated GlobalPlatform Registries.”

The seventh paragraph

“The Application Provider may then forward the Delete Receipt to the corresponding off-card entity as a proof that the deletion process was successfully performed. The purpose of the optional Delete Receipt is to assist the Card Issuer in keeping its Card Management System synchronized with its card base”


“The Application Provider may then forward the Delete Receipt to the corresponding off-card entity as a proof that the deletion process was successfully performed. The purpose of the optional Delete Receipt is to assist the Application provider in keeping its Card Management System synchronized with its on-card application base”



Section 11.1.6 last sentence

“Card unique data is the concatenation without delimiters of the IIN and CIN”

Shall be replaced by

“Security Domain unique data is the concatenation without delimiters of the Security Domain provider Identification Number and the Security Domain Image Number (SDIN)”

Section 11.2 Table 11-22

The Name of the Tag 45

“Card Image Number”


“Image number of the Security Domain with TOKEN_VERIFICATION privilege”

Section 11.5 Table 11-48, 11-49, 11-50, 11-51 and 11-52

The Name of the Tag 45,

“Card Image Number”


“Image Number of the Security Domain with TOKEN_VERIFICATION privilege”

Annex C.4 "Tokens"

The first paragraph

“Tokens are public key signatures, generated by the Card Issuer. Tokens are the proof that the Card Issuer has authorized the Card Content Management operation being performed and they are generated and verified according to this appendix. Tokens may be generated for use on multiple cards, depending on the Card Issuer's security policy.”


“Tokens are public key signatures, generated by the Application Provider. Tokens are the proof that the Application Provider has authorized the Card Content Management operation being performed and they are generated and verified according to this appendix. Tokens may be generated for use on multiple cards, depending on the Application provider's security policy.”

Annex C.4.1 "Load token"

The third paragraph, fourth bullet

“The issuer of the Load Token may only be the Security Domain Provider of the Security Domain with Token Verification Privilege (e.g. the Card Issuer)”


“The issuer of the Load Token may only be the Security Domain Provider of the Security Domain with Token Verification Privilege.”

Annex C.4.2 "Install token"

The third paragraph, fifth bullet

“The issuer of the Install Token may only be the Security Domain Provider of the Security Domain with Token Verification Privilege (e.g. the Card Issuer).”


“The issuer of the Install Token may only be the Security Domain Provider of the Security Domain with the Token Verification Privilege.”



Annex C.4.3 "Make Selectable token"

The third paragraph, fifth bullet

“The issuer of the Make Selectable Token may only be the Security Domain Provider of the Security Domain with Token Verification Privilege (e.g. the Card Issuer).”


“The issuer of the Make Selectable Token may only be the Security Domain Provider of the Security Domain with the Token Verification Privilege.”

Annex C.4.4 "Extradition Token"

The third paragraph, second bullet

“The issuer of the Extradition Token may only be the Security Domain Provider of the Security Domain with Token Verification Privilege (e.g. the Card Issuer).”


“The issuer of the Extradition Token may only be the Security Domain Provider of the Security Domain with the Token Verification Privilege.”

Annex C.4.5 "Registry Update Token",

The third paragraph, third bullet

“The issuer of the Registry Update Token may only be the Security Domain Provider of the Security Domain with Token Verification Privilege (e.g. the Card Issuer).”


"The issuer of the Registry Update Token may only be the Security Domain Provider of the Security Domain with the Token Verification Privilege.”

Annex C.4.6 "Delete Token"

The third paragraph, second bullet

“The issuer of the Delete Token may only be the Security Domain Provider of the Security Domain with Token Verification Privilege (e.g. the Card Issuer).”


“The issuer of the Delete Token may only be the Security Domain Provider of the Security Domain with the Token Verification Privilege.”

Annex C.4.6 table C-8 last row

“Card Image Number (Tag ‘45’)”


“Security Domain Image Number (Tag ‘45’)”

Annex C.4.7 "Load, Install and Make Selectable Token"

The third paragraph, eighth bullet

“The issuer of the combined Load, Install and Make Selectable Token may only be the Security Domain Provider of the Security Domain with Token Verification Privilege (e.g. the Card Issuer).”


“The issuer of the combined Load, Install and Make Selectable Token may only be the Security Domain Provider of the Security Domain with the Token Verification Privilege.”



E.6. Card Content Combined Loading, Installation and Make Selectable Process

Section 9.3.8, "Card Content Combined Loading, Installation, and Make Selectable Process", the 4th paragraph

"A last INSTALL [for load, install and make selectable] command serves as the combined load and install commit for loading and installation. The last INSTALL [for load, install and make selectable] command data field details the requirements regarding a Load File."


"A last INSTALL [for load, install and make selectable] command serves as the combined load and install commit for loading and installation. The last INSTALL [for load, install and make selectable] command data field details the requirements regarding an Application."

E.7. OPEN behavior for Extradition

Section 9.4,1,

The fifth bullet:

“

• Check that the Security Domain requesting the extradition is directly or indirectly associated with the Application or Executable Load File being extradited;”


“

• Check that the Security Domain requesting the extradition is associated with the Application or Executable Load File being extradited;”

E.8. STORE DATA

Section 11.1.3.2, Table 11-82 "STORE DATA Error condition" shall add the following as the second row of this table:

'6A' '84' Not enough memory space Section 11.11.2.1

The second bullet of first list

“

• b5 - b4 = 01 indicate that the command message data field is coded as one or more DGI structures, according to GlobalPlatform Systems Scripting Specification;

”


“

• b5 - b4 = 01 indicate that the command message data field is coded as one or more DGI structures, according to GlobalPlatform Systems Scripting Language Specification;

”



E.9. Number of Executable Modules

In section 11.4.3.2, Table 11-37 "Executable Load File and Executable Module Information Data", the row containing:

Number of Executable Modules 1 '01' - '7F' Conditional Shall be replaced by:

Number of Executable Modules 1 '00' - '7F' Mandatory

E.10. Tag ‘D6’ Code Reserved Memory

A loaded load file can not allocate memory during runtime. Therefore, it is not necessary to reserve code memory space when loading a load file. The Tag ‘D6’ is removed from Table 11-48

Section 11.5.2.3.7 "INSTALL Command Parameters",

Table 11-48 shall be replaced by

Tag Length Name Presence 'EF' 1-n System Specific Parameters Conditional

'C6' 2 or 4 Non volatile code Minimum Memory requirement Optional

'C7' 2 or 4 Volatile data Minimum Memory requirement Optional

'C8' 2 or 4 Non volatile data Minimum Memory requirement Optional

'CD' 1 Load File Data Block format id Optional

'DD' 1-n Load File Data Block Parameters Conditional

'B6' 1-n Control Reference Template for Digital Signature (Token)

Conditional

‘42’ 1-n Token Issuer id Optional

'45' 1-n Card Image Number Optional

‘5F20’ 1-n Application Provider identifier Optional

‘93’ 1-n Token identifier/number (digital signature counter)

Optional

E.11. mplicit Selection parameters

The Tag ‘CF’ implicit selection has length coded on one byte as specified in section 11.1.7. The Tag ‘CF’ may be present to define implicit selection on several logical channels or on several interfaces.

In section 11.5.2.3.7, "INSTALL Command Parameters",

The table 11-49, "Install Parameter Tags", shall be replaced by the following one

Tag Length Name Presence 'C9' 1-n Application Specific Parameters Mandatory

'EF' 1-n System Specific Parameters Conditional



Tag Length Name Presence 'C7' 2 or 4 Volatile Memory Quota Optional

'C8' 2 or 4 Non volatile Memory Quota Optional

'CB' 2-n Global Service Parameters Optional

'D7' 2 Volatile Reserved Memory Optional

'D8' 2 Non volatile Reserved Memory Optional

'CA' 1-n TS 102 226 specific parameter Optional

‘CF’ 1 Implicit selection parameter See note below

'EA' 1-n TS 102 226 specific template Optional

'B6' 1-n Control Reference Template for Digital Signature (Token)

Conditional

‘42’ 1-n Token Issuer id Optional

'45' 1-n Card Image Number Optional

‘5F20’ 1-n Application Provider identifier Optional

‘93’ 1-n Token identifier/number (digital signature counter)

Optional

The table 11-50, "Make Selectable Tags", shall be replaced by the following table

Tag Length Name Presence 'EF' 1-n System Specific Parameters Conditional ‘CF’ 1 Implicit selection parameter Optional 'B6' 1-n Control Reference Template for Digital

Signature (Token) Conditional

‘42’ 1-n Token Issuer id Optional '45' 1-n Card Image Number Optional ‘5F20’ 1-n Application Provider identifier Optional ‘93’ 1-n Token identifier/number (digital

signature counter) Optional

E.12. API GPSystem.APPLICATION_LOCKED

In Annex A.1, "GlobalPlatform on a Java Card", "Field Summary", for

public static final byte APPLICATION_LOCKED

“The current applet context is in the Life Cycle State of LOCKED (0x7F).”


“The current applet context is in the Life Cycle State of LOCKED (0x80). To know if an application is locked, a logical AND operation shall be performed between this constant and the current application lifecycle state.”



E.13. API GPSystem.setATRHistBytes()

In Annex A.1, "GlobalPlatform on a Java Card", "Method Detail"

The second sentence,

"The sequence of bytes will be visible on a subsequent power-up or reset."

Shall be replaced by,

"The sequence of bytes will be visible on a subsequent power-up or cold reset."

And the following,

“Parameters:

baBuffer - the source byte array containing the historical bytes. Must be a global array.”


“Parameters:

baBuffer - the source byte array containing the historical bytes.”

Rationale: The method is static and is executed in the context of the caller. The applet settings the ATR Historical bytes can use its own buffer to provide the new value and also Global Array.

E.14. API Application.processData()

Annex A.1, "GlobalPlatform on a Java Card", interface Application, method processData(), "Method Detail"

A 5th bullet shall be added to the note on the processData() method description as follows:

• “If the method throws an ISOException the JavaCard runtime environment sends the associated reason code as the response status instead. If the Exception thrown does not extend ISOException the reason code is ISO7816. SW_UNKNOWN. The personalization session remains open.”

E.15. API SecureChannel.unwrap()

Annex A.1, "GlobalPlatform on a Java Card", interface SecureChannel, method unwrap(), "Method Detail"

The Parameters description

“Parameters:

baBuffer - the source of the data to be wrapped. This buffer must be global

sOffset - the offset within baBuffer of the data to unwrap. sLength - the length of the data to unwrap. return - the length of the unwrapped data.”

Shall be updated as follows

“Parameters:

baBuffer - the source of the data to be unwrapped. This buffer must be global

sOffset - the offset within baBuffer of the APDU data to unwrap i.e the offset of the command header



sLength - the length of the APDU data to unwrap, i.e the length of the command header and data field

return - the length of the unwrapped data, i.e the length of the command header and data field”

E.16. API GPSystem Constant FAMILY_SERVICE_IDENTIFIER

The name is inconsistent in the document.

In A.2.4.8, replace:

"#define FAMILY_SERVICE_IDENTIFIER 0x80 Indicates the family of the Secure Channel Global Service Identifier."

with,

"#define GLOBAL_SERVICE_IDENTIFIER 0x80 Indicates the generic Global Service Identifier."

E.17. Delete Token

Annex C.4.1 "Delete Token"

The note following Table C-3,

“Note that 'Length of the following data fields' is the value of Lc of the INSTALL command, prior to a Token being added. It is coded on 1 byte with a value up to 255.”


“Note that 'Length of the following data fields' is the value of Lc of the DELETE command, prior to a Token being added. It is coded on 1 byte with a value up to 255.”

E.18. AID of application for Card Challenge

Annex E.4.2.3, first bullet,

"The AID of the currently selected Application"

Shall be replaced by,

"The AID of the application invoking the SecureChannel interface"

E.19. PUT KEY

This erratum intends to solve a consistency issue between the PUT KEY command definitions in GP CS v2.2, GP CS Amendment B: Remote Application Management over HTTP and GP CS Amendment D: Secure Channel Protocol ‘03’.

Table 11-75 shall be updated as follows:

Name Length Value Presence Key type 1 ‘00’ – ‘FE’ – see section

K.1.8 – Key Type Coding Mandatory

Length of key or key component data 1 - 3 ‘01’ – ‘80’, or ’81 80’ – ‘81 Mandatory



FF’, or ’82 01 00’ – ’82 FF FF’

Key or key component data 1-n ‘xxxx…’ Mandatory Length of check data 1 ‘00’ – ‘7F’ Mandatory Key check value 0-n ‘xxxx…’ Conditional

Table 11-76 shall be updated as follows:

Name Length Value Presence Key type of the first or only key component

2 ‘FF xx’ – see section 11.1.8 – Key Type Coding

Mandatory

Length of the first or only key component

1 - 3 ‘01’ – ‘80’, or ’81 80’ – ‘81 FF’, or ’82 01 00’ – ’82 FF FF’

Mandatory

Key or first key component data 1-n ‘xxxx…’ Mandatory Key type of the last key component, if more than one

2 ‘FF xx’ – see section 11.1.8 – Key Type Coding

Conditional

Length of the last key component 1 – 3 ‘01’ – ‘80’, or ’81 80’ – ‘81 FF’, or ’82 01 00’ – ’82 FF FF’

Conditional

Length of key check value 1 ‘00’ – ‘7F’ Mandatory Key check value (if present) 0-n ‘xxxx…’ Conditional Length of key usage qualifier 1 ‘00’ – ‘7F’ Mandatory Key usage qualifier 0-n ‘xxxx…’ see section 11.1.9

– Key usage qualifier Conditional

Length of key access 1 ‘00’ – ‘7F’ Mandatory Key access 0-n ‘xxx…’ see section 11.1.10

– Key Access Coding Conditional

Section 11.1.9 title shall be replaced as follows:

“11.1.9. Key Usage Qualifier Coding”

First sentence of Section 11.1.9 shall be updated as follows:

“The values for the Key usage qualifier parameter are set according to the following table:”

Table 11 – 17 title shall be replaced by:

“Table 11-17: Key Usage Qualifier”

E.20. Normative References

In Table 1-1

“

GlobalPlatform Systems Scripting Specification

GlobalPlatform Systems Scripting Specification, version 1.1



”


“

GlobalPlatform Systems Scripting Language Specification

GlobalPlatform Systems Scripting Language Specification, version 1.1.0

”



P. Precisions

P.1. PKCS#1

Section 1, "Normative References", Table 1-1, the row

PKCS#1 (RFC 2437) PKCS #1 v2.0: RSA Cryptography Standard, RSA Laboratories, October 1998 (RFC 2437).


PKCS#1 PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002.

Annex B.3, "Public Key Cryptography Scheme 1 (PKCS#1)",

Paragraphs two and three,

"The process of generating an RSA signature involves using the PKCS#1 standard. The signature scheme is RSA SSA-PKCS1-v1_5 as defined in PKCS#1. This is applied to a digest of the data being signed, generated by the SHA-1 algorithm. The resultant signature is the same size as the public key modulus.

The process of verifying a signature uses the public key applied to the signature (providing the hash) and the comparison of this hash with the hash of the data being verified."


"The signature scheme is RSASSA-PKCS1-v1_5 as defined in PKCS#1. The hash function is SHA-1.

Annex C.4, "Tokens",

Second paragraph, sentence two and three,

"Padding of the data is as defined by the SHA-1 and PKCS#1 mechanism. The signature scheme for tokens is as defined in appendix B.2.1 - Secure Hash Algorithm (SHA-1)."


"The signature scheme for tokens is as defined in appendix B.3."

Annex C.6.1, "PKC Scheme",

The third sentence,

"Padding of the data is as defined by SHA-1 and PKCS#1."


"The signature scheme for DAP verification is as defined in appendix B.3."

P.2. Security Domain Lifecycle State LOCKED

Section 5.3.2.4 "Security Domain Lifecycle State LOCKED", paragraph four, shall be amended with the following sentence:



"In summary, if a Security Domain is in the lifecycle state LOCKED, it shall reject all received commands.

P.3. SET STATUS to lock/unlock a SD hierarchy

Section 11.10.2.1 "Reference Control Parameter P1 – Status Type", the following note is added as a new paragraph after Table 11-78:

“When the SET STATUS command applies for Security Domain and Associated Application, if an Associated Application is a Security Domain, then the SET STATUS command applies also for Application associated to this Security Domain. If the SET STATUS is used to lock all applications, all applications already locked remain locked, and no error status is returned. If the SET STATUS is used to unlock all applications, all applications already unlocked remain unlocked, and no error status is returned.”

P.4. STORE DATA command in case of Exception thrown by Application under Personalization

Section 11.11.1 shall be modified as follows:

Replace

"Multiple STORE DATA commands transfer data to the Application or Security Domain by breaking the data into smaller components for transmission. Each STORE DATA command is numbered starting at '00'. The STORE DATA command numbering shall be strictly sequential and increments by one. The Security Domain shall be informed of the last block."

with the following text:

"Multiple STORE DATA commands are used to send data to the Application or Security Domain by breaking the data into smaller components for transmission. The Security Domain shall be informed of the last block.

A personalization session starts when a Security Domain receives a valid INSTALL [for personalize] command designating an application (implementing either the Application or the Personalization interface) to which the Security Domain shall forward subsequently received STORE DATA commands.

A personalization session ends when:

- The card is reset;

- The Security Domain is deselected (i.e. another or the same applet is selected on the same logical channel);

- The Security Domain is selected on the same or another logical channel;

- The Secure Channel session (if any) established by the Security Domain is reset, possibly by the targeted application (see conditions triggering Secure Channel Termination described in 10.2.3 of [GP22]);

- The Security Domain receives an INSTALL [for personalize] command (starting a new personalization session for another application);

- The Security Domain receives a STORE DATA command indicating P1.b8=1 (last block);

Any STORE DATA command received out of such a personalization session shall be processed by the Security Domain itself."



P.5. Data Grouping Identifier (DGI) coding rules

The DGI shall be coded on two bytes in binary format, followed by a length indicator coded as defined in GP Systems Scripting Language Specification v 1.1.0 annex B.


errata and precision list - card specification v2 -...

Documents