Globalplatform Card Uicc Configuration: Member Release

GlobalPlatform Card
UICC Configuration
Version 1.0.1
Member Release
January 2011
Document Reference: GPC_GUI_010
Copyright  2008-2011 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.
UICC Configuration v1.0.1 2/50
This document is provided as a member benefit to GlobalPlatform

members only. Please help us maintain the value of your
membership and encourage recruitment by observing this
restriction.

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/50 UICC Configuration v1.0.1
Table of contents
1 NORMATIVE REFERENCES ................................................................................................................................ 5
2 ABBREVIATIONS AND NOTATIONS ................................................................................................................. 6
3 OVERVIEW ............................................................................................................................................................... 8
3.1 SECURITY DOMAINS ........................................................................................................................................... 8
3.2 REQUIRED APPLICATION PROGRAMMING INTERFACES ..................................................................................... 8
4 UICC SECURITY POLICIES.................................................................................................................................. 9
4.1 PRIVILEGES ......................................................................................................................................................... 9
4.2 ISSUER SECURITY DOMAIN............................................................................................................................... 10
4.3 SUPPLEMENTARY SECURITY DOMAINS ............................................................................................................ 10
4.3.1 Security Domain Hierarchies ................................................................................................................ 10
4.3.2 Security Domain Instantiation ............................................................................................................... 12
4.3.3 Security Domain Personalization ......................................................................................................... 13
4.4 SECURE CHANNEL ............................................................................................................................................ 14
4.4.1 Secure Channel Protocol Usage.......................................................................................................... 14
4.4.2 Secure Channel Interface Usage ......................................................................................................... 15
4.5 APPLICATIONS................................................................................................................................................... 16
5 DATA REQUIREMENTS ...................................................................................................................................... 17
5.1 AID VALUES...................................................................................................................................................... 17
5.2 ISSUER SECURITY DOMAIN............................................................................................................................... 17
5.2.1 Data Store ............................................................................................................................................... 17
5.2.1.1 Card Recognition Data (tag '66') .......................................................................................................... 17
5.2.2 Secure Channel Keys ............................................................................................................................ 18
5.2.3 Default Secure Channel Sequence Counter (tag 'C1') ..................................................................... 18
5.2.4 Key Information Template and Key Information Data (tags 'E0' and 'C0') ..................................... 18
5.3 SUPPLEMENTARY SECURITY DOMAINS PRESENT ON THE UICC..................................................................... 18
5.3.1 Data Store ............................................................................................................................................... 18
5.3.1.1 Security Domain Recognition Data...................................................................................................... 18
5.3.2 Secure Channel Keys ............................................................................................................................ 19
5.3.3 DAP Verification Key ............................................................................................................................. 19
5.3.4 Default Secure Channel Sequence Counter (tag 'C1') ..................................................................... 19
5.3.5 Key Information Template and Key Information Data (tags 'E0' and 'C0') ..................................... 19
5.3.6 Token Verification Key........................................................................................................................... 19
6 KEY USAGE ........................................................................................................................................................... 20
7 DELEGATED MANAGEMENT ............................................................................................................................ 22

7.1 DELEGATED MANAGEMENT KEYS AND TAG ..................................................................................................... 22
7.1.1 Token Key ............................................................................................................................................... 22
7.1.2 Receipt Key ............................................................................................................................................. 22
7.2 TOKEN COMPUTATION AND VERIFICATION....................................................................................................... 22
7.2.1 RSA Scheme .......................................................................................................................................... 22
7.2.2 DES Scheme .......................................................................................................................................... 22
7.3 DELEGATED MANAGEMENT RECEIPT ............................................................................................................... 22
8 APDU COMMANDS .............................................................................................................................................. 23
8.1 DELETE ........................................................................................................................................................... 23
8.2 GET DATA....................................................................................................................................................... 23

prohibited.
8.2.1 Command Message ............................................................................................................................... 24

8.3 GET STATUS ................................................................................................................................................. 24
8.4 INSTALL .......................................................................................................................................................... 25
8.4.1 INSTALL [for load].................................................................................................................................. 25
8.4.2 INSTALL [for install] ............................................................................................................................... 25
8.4.3 INSTALL [for install and make selectable] ......................................................................................... 26
8.4.4 INSTALL [for make selectable] ............................................................................................................ 26
8.4.5 INSTALL [for extradition] ....................................................................................................................... 26
8.4.6 INSTALL [for registry update] ............................................................................................................... 27
8.4.7 INSTALL [for personalization] .............................................................................................................. 27
8.5 LOAD ............................................................................................................................................................... 27
8.6 MANAGE CHANNEL ..................................................................................................................................... 27
8.7 PUT KEY (DES KEYS) .................................................................................................................................... 27
8.8 PUT KEY (RSA PUBLIC KEY) ......................................................................................................................... 28
8.9 SELECT ........................................................................................................................................................... 28
8.10 SET STATUS .................................................................................................................................................. 28
8.11 STORE DATA ................................................................................................................................................. 29
9 CONTROLLING AUTHORITY SECURITY DOMAIN (CASD) ....................................................................... 30
9.1 CASD MANAGEMENT DATA ............................................................................................................................. 30
9.2 CASD KEYS AND CERTIFICATES ..................................................................................................................... 31
9.2.1 Support for Public Key Scheme ........................................................................................................... 32
9.2.2 Support for Non-Public Key Scheme .................................................................................................. 34
9.3 SUPPORT FOR AUTHORITY INTERFACE (GLOBAL SERVICE) ............................................................................. 34
10 CONFIDENTIAL SETUP OF SECURE CHANNEL KEYS.............................................................................. 35
10.1 SCENARIO #1 (PULL MODEL) ........................................................................................................................... 35
10.1.1 Presenting AP Public Key Certificate .................................................................................................. 37
10.1.2 Loading AP Symmetric Key .................................................................................................................. 39
10.1.3 Pulling AP Secure Channel Keys ........................................................................................................ 40
10.2 SCENARIO #2.A (PUSH MODEL WITH APPLICATION PROVIDER CERTIFICATE)............................................... 42
10.2.1 Presenting AP Public Key Certificate .................................................................................................. 43
10.2.2 Pushing AP Secure Channel Keys ...................................................................................................... 43
10.3 SCENARIO #2.B (PUSH MODEL WITHOUT APPLICATION PROVIDER CERTIFICATE) ........................................ 46
10.3.1 Detailed Steps ........................................................................................................................................ 47
11 LIST OF TABLES AND FIGURES ..................................................................................................................... 49

prohibited.
1 Normative References
Standard / Specification Description Ref
ETSI TS 102 225 (Release 7) Smart cards; Secured packet structure for UICC
based applications, European Telecommunications
[1]
Standards Institute Project Smart Card Platform (EP
SCP)
ETSI TS 102 226 (Release 7 + CR Smart cards; Remote APDU structure for UICC based
SCPt080562) applications, European Telecommunications
[2]
Standards Institute Project Smart Card Platform (EP
SCP)
GlobalPlatform Card Specification v 2.2.1 GlobalPlatform Card Specification v2.2.1 [3]
GP 2.1.1 to 2.2 Mapping Guidelines Implementation guidelines for mapping a
v1.0.1 GlobalPlatform card based on the Card Specification
[4]
v2.1.1 to a GlobalPlatform card compliant to Card
Specification v2.2.1.
GlobalPlatform Confidential Card Content Defines a mechanism for an Application Provider to
Management – Card Specification v2.2 – confidentially manage its own application when using [5]
Amendment A v1.0.1 a third party communications network.
ETSI TS 102 223 (Release 7) Smart Cards; Card Application Toolkit (CAT) [6]
ETSI TS 102 221 (Release 7) Smart cards; UICC-Terminal interface; Physical and
[7]
logical characteristics (Release 7)
ETSI TS 102 220 (Release 7 + CR Smart cards; ETSI numbering system for
[8]
SCPt080563 and SCPt080564) telecommunication application providers
GlobalPlatform Systems Scripting ECMA scripting standard for instructions for data
Language Specification v1.1.0 generation, personalization, and post-issuance [9]
purposes.
ISO/IEC 9796-2:2002 Information technology – Security techniques – Digital
signature schemes giving message recovery – Part 2: [10]
1
Integer factorization based mechanisms .
GlobalPlatform Systems Card GlobalPlatform Systems; Description of card
Customization Guide v1.0 customization process, components, and [11]
responsibilities.
PKCS#1 v1.5 RSA Encryption Standard, version 1.5, 1-November
[12]
1993
EMV Book 2 Security and Key EMV Integrated Circuit Card Specifications for
Management v4.2 Payment Systems – Book 2 Security and Key [13]
Management v4.2 June 2008
Table 1-1: Normative References
1
Notice that EMV Book 2 [13] – Appendix A.2 provides a simplified description of Digital Signature Scheme 1, using the
SHA-1 hash function and trailer field option 1, which is the variant actually used in the present document.

prohibited.
2 Abbreviations and Notations

Abbreviation Meaning
AP Application Provider
APDU Application Protocol Data Unit
API Application Programming Interface
APSD Application Provider Security Domain
CA Controlling Authority
CASD Controlling Authority Security Domain
ISD Issuer Security Domain
KS Secret Symmetric Key
LPO Link Platform Operator
LPOSD Security Domain of the Link Platform Operator
MAC Message Authentication Code
MNO Mobile Network Operator
NAA Network Access Application (e.g. SIM, USIM, etc.)
OTA Over-The-Air
OTAPO OTA Platform Operator
OTASD OTAPO Security Domain
PK Public Key of an asymmetric key pair.
PKI Public Key Infrastructure
SK Private key of an asymmetric key pair
TSM Trusted Service Manager
SK.CA.AUT CA Private Key used to sign certificates (off-card)
PK.CA.AUT CA Public Key used to verify certificates (off-card)
PK.AP.AUT Application Provier Public Key (Push Model)
PK.AP.CT Application Provider Public Key (Pull Model)
CERT.AP.AUT Application Provider Certificate
CERT.AP.CT Application Provider Certificate
KS.AP.CT Application Provider Symmetric Key used for Encryption/Decryption
CERT.CASD.AUT CASD Certificate holding a Public Key suitable for Signature Verification
CERT.CASD.CT CASD Certificate holding a Public Key suitable for Encryption
SK.CASD.AUT CASD Private Key used for Signature

prohibited.
Abbreviation Meaning
SK.CASD.CT CASD Private Key used for Decryption
PK.CASD.AUT CASD Public Key used for Signature Verification
PK.CASD.CT CASD Public Key used for Encryption
KS.CASD.CT CASD Symmetric Key used for Encryption/Decryption
KS.CASD.AUT CASD Symmetric Key used for Signature/Verification
Table 2-1: Abbreviations and Notations

prohibited.
3 Overview
This document specifies configuration requirements for implementing GlobalPlatform Specifications on the
UICC platform specified in ETSI specifications TS 102 221 [7], TS 102 223 [6], TS 102 225 [1] and TS 102
226 [2].
The provisions of the GP CS v2.2 Mapping Guidelines [4] and GP CS v2.2 Amd. A [5] shall apply as
specified in this document.
3.1 Security Domains

Three types of Security Domains exist for this configuration:
• The Issuer Security Domain; that is present and active
• Application Provider Security Domain
• A Controlling Authority Security Domain; that is optionally present and offers a confidential
personalization service to authenticated application providers
Application Provider Security Domains are only instantiated from pre-loaded executable load files.
3.2 Required Application Programming Interfaces

A UICC shall implement the GlobalPlatform Java Card™ API according to the following indications:
• The package org.globalplatform shall be implemented (version 1.5 or above), with the
following precisions:
o Instances of the SecureChannel interface returned by the
GPSystem.getSecureChannel() method may also optionally implement the
SecureChannelx interface.
o Instances of the SecureChannel interface returned by the
GPSystem.getSecureChannel() method shall also implement the SecureChannelx2
interface.
o Security Domains shall be able to personalize their associated Applications that implement
either the Personalization interface or the Application interface. An Application
impementing both interfaces shall be personalized using the Personalization interface.
o Supplementary Security Domains shall implement the Personalization interface to
support confidential card content management.
o An implementation of the Authority interface shall be registered as a unique Global
Service by the Controlling Authority Security Domain.
o The implementation of the HTTPAdministration interface is optional.
o The implementation of the HTTPReportListener interface is optional.
• The package org.globalplatform.contactless is optionally implemented.

prohibited.
4 UICC Security Policies

This section defines security principles for the entities that may be present on a GlobalPlatform card
supporting this configuration:
4.1 Privileges
Table 4-1 lists the privileges that shall be assigned to the Issuer Security Domain, to each instance of a
Supplementary Security Domain, and lists privileges that may be assigned to other Applications. To
facilitate product deployment, the platform supports all mandatory and optional privileges listed in this
table.
ISD CASD APSD NAA Application
Security Domain   
DAP Verification
Delegated Management
Card Lock 
Card Terminate 
Card Reset
CVM management 
Mandated DAP Verification
 
Privileges
Trusted Path
Authorized Management 
Token Verification 
Global Delete 
Global Lock 
Global Registry 
Final Application
Global Service 
Receipt Generation 
Ciphered Load File Data
Block
Table 4-1: Supported Privileges

A tick () denotes the presence of the indicated privilege and its assignment to the Security Domain or
Application.
A blank cell denotes that the assignment of the privilege is beyond the scope of this configuration.
A black cell denotes that the privilege cannot be assigned.
Additional Privilege Assignment Rules (beyond those defined in section 6.6 of the GP CS v2.2.1 [3])
1. A Security Domain shall not be able to extend its own privileges.
2. A Security Domain shall not be able to assign to another Security Domain, or any other Application,
any of the privileges listed below that it does not have itself:

prohibited.
• Global Delete
• Global Lock
• Global Registry
• Card Terminate
• Card Lock
3. Only the Issuer Security Domain can assign the Authorized Management and the Mandated DAP
privileges.
4. It shall only be possible to assign the Token Verification and Receipt Generation privileges to a
Security Domain with the Authorized Management privilege.
4.2 Issuer Security Domain

The Issuer Security Domain supports Secure Channel Protocol '80' (SCP80). When the Issuer Security
Domain receives a Remote Application Management command, the security policy as defined in ETSI TS
102 225 [1] shall be applied.
The Issuer Security Domain may support Secure Channel Protocol '02' (SCP02) option i = '55'.
The absence or presence of additional SCPs in Security Domains on the UICC is beyond the scope of this
document.
When the Issuer Security Domain is the selected Application, all commands besides those required to
setup a Secure Channel shall be processed within a Secure Channel session except the GET DATA
command, which may be processed outside of a Secure Channel session.
The level of security of the commands following the setup of the Secure Channel Session in SCP02 mode
is defined in section 2.2 of the GP CS v2.2 Mapping Guidelines [4].
Extradition of an Application or Load File to the Issuer Security Domain shall never succeed.
The Issuer Security Domain shall only accept deletion requests made by Security Domains within its
hierarchy with the Delegated Management privilege or a Security Domain with the Global Delete privilege.
4.3 Supplementary Security Domains

Support for Supplementary Security Domains is mandatory.
Supplementary Security Domains are installed with Secure Channel Protocol '80' option i = '00' and/or
Secure Channel Protocol '02' option i = '55'. As with the Issuer Security Domain, the absence or presence
of additional SCPs in Security Domains on the UICC is beyond the scope of this document.
Any Supplementary Security Domain has the option to reject or accept Applications being extradited to it
as defined by the GP CS v2.2 Mapping Guidelines [4] and in accordance with the configuration given
below in section 4.3.2.
The level of security of the commands following the setup of the Secure Channel Session in SCP02 mode
is defined in section 2.3 of the GP CS v2.2 Mapping Guidelines [4] as was previously stated for the ISD.
4.3.1 Security Domain Hierarchies

Security Domains are organized in hierarchies according to GP CS v2.2.1 [3]:
• The root of a new hierarchy is defined by extraditing a SD to itself (as described in [3])
• Within such a hierarchy, the following rules are enforced by OPEN:

prohibited.
- If a personalized SD has the AM privilege, then none of its ancestor SDs (following the path
to the root of the hierarchy) has the AM privilege. Conversely, if a SD has the AM
privilege, no personalized SD found in its descendants (no SD found below it) has the AM
privilege
- A SD with the AM privilege can perform Card Content Management according to section 9 of
GP CS v2.2.1 [3]
- A SD shall accept installation if requested by an ancestor SD with the AM privilege or by an
SD with the DM privilege under an ancestor SD with the AM privilege
- A SD shall accept extradition according to section 4.3.2
- A SD shall accept deletion according to section 4.3.2
• The ISD is the only Security Domain able to
- Create a Security Domain with Authorized Management privilege
- Extradite a Security Domain with Authorized Management privilege
Applying these rules, the two following examples of hierarchies can be created:
Hierarchy Example 1
The root of this hierarchy is a Security Domain supporting Secure Channel Protocol '80' (SCP80). It does
not support Card Content Management.
The APSD 1 has Authorized Management. It uses its SCP02 over the SCP80 when accessed by the Link
Platform Operator (LPO).
The APSD 2 has Authorized Management. It uses its SCP80 and keys when accessed Over The Air.
APSD : LPO
SCP80
AM AM
APSD 1 APSD 2
SCP02 SCP80
Figure 4-1: Example 1 of Security Domain hierarchy
Hierarchy Example 2
The APSD 1 is the root of this hierarchy. It provides card content management for the entire hierarchy.
The APSD 2 has no card content management privilege. It uses its SCP02 over the SCP80 when
accessed by the LPO.
The application relies on the SCP80 provided by APSD 1.
AM
APSD 1 : LPO
SCP80
APSD 2 Application
SCP02
Figure 4-2: Example 2 of security domain hierarchy

prohibited.
4.3.2 Security Domain Instantiation

When a Security Domain instantiates an Application Provider Security Domain, the newly created Security
Domain is associated with the SD requesting the installation. This rule supersedes the rule specified in the
GP CS v2.2.1 [3]: as the Executable Load File for Application Provider Security Domains is associated to
the ISD, according to [3], the newly installed APSD would otherwise be associated to the ISD, even if
another SD is processing the INSTALL command.
Security Domain customization is achieved through additional parameters provided in the data field of the
INSTALL[for install] or INSTALL[for install and make selectable] commands. The following table describes
the possible parameters within tag 'C9' (Application Specific Install Parameters):
Tag Length Designation Presence
Secure Channel Protocol Identifier and Implementation Option “i” 1 to N

'81' '02' occurrences
Accept extradition of Applications and/or Executable Load Files to
'82' '01' or '02' Optional
this Security Domain according to Table 4-3.
'83' '01' Accept deletion of associated Applications according to Table 4-3. Optional
Life cycle state transition to PERSONALIZED using SET STATUS

'84' '00' or STORE DATA command. If this tag is missing, refer to section Optional
4.3.3.
CASD Capability Information, as defined in Table 9-2 and Table
'86' '02' Conditional
9-3. This parameter is mandatory for the CASD.
Accept extradition of associated Applications and/or Executable
'87' '01' or '02' Optional
Load Files according to Table 4-3.
Table 4-2: Security Domain Install Parameters

The tags in Table 4-2 may occur in any order.
Tag ‘81’ specifies a Secure Channel Protocol supported by the Security Domain and may occur several
times. If this tag occurs once only, then the SD supports one Secure Channel Protocol exclusively. If
multiple occurrences of this tag are present, then the SD can be externally accessed through different
Secure Channel Protocols.
Tag ‘82’ defines the acceptance policy used by the Security Domain when Applications and/or Executable
Load Files are being extradited to it.
Tags ‘83’ and ‘87’ define the acceptance policy used by the Security Domain when deletion and extradition
are respectively performed on its associated Applications and/or Executable Load Files by another
Security Domain. This policy does not apply when a Security Domain (with AM or DM privilege) is
operating directly on its associated Applications and Executable Load Files. The policy defined by tag ‘83’
for deletion also does not apply when the Security Domain performing the deletion has the Global Delete
privilege, in which case the OPEN does not request acceptance from the Security Domain.
The following table describes the encoding rules used for tags '82', '83' and '87':

prohibited.
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
SD does not accept the operation (default policy if the tag is not
0 0 0 0 0
present)
1 0 - 0 - SD accepts the operation from an ancestor SD with AM privilege
SD accepts the operation from any SD in its hierarchy with AM
1 1 - 0 -
privilege
- - 1 0 - SD accepts the operation from Issuer Security Domain
SD accepts the operation from any SD with DM privilege under an
- - - - 1
ancestor SD with AM privilege
SD accepts the operation from every SD with AM privilege on the
1 1 1 1 -
Card
- - - - - X X X RFU, and set to '0'
Table 4-3: Encoding rules for tags '82', '83', and '87' defined in Table 4-2.
Note: The bit field may be encoded such that multiple rules apply. For example, the rule expressed by the
fourth row may be combined with the rules expressed in rows two or three. For tags '82' and '87', the value
may be composed of one or two bytes. If the value is composed of a single byte, then the policy applies to
both Applications and Executable Load Files. If the value is composed of two bytes, then the first
(leftmost) byte applies to Applications and the second (rightmost) byte applies to Executable Load Files.
If tag '82', '83' or '87' is not present, then the default policy shall apply for the corresponding operation
(equivalent to a value of '00' for any of these tags).
4.3.3 Security Domain Personalization

Immediately after installation of a Security Domain, no keys exist in the Security Domain and the Security
Domain uses the services of the associated Security Domain to set up a Secure Channel.
When one complete Secure Channel Key Set has been successfully loaded, the Security Domain uses
this newly loaded Key Set to establish a Secure Channel session independent of the Associated Security
Domain.
Before entering the PERSONALIZED state, the Security Domain will at least have the following:
• One complete Secure Channel Key Set loaded for each supported Secure Channel Protocol, as
indicated by Tag(s) '81' according to section 4.3.2
• All of the Keys required by its privileges
• If the Security Domain has the Authorized Management privilege, it is Extradited to itself or to
another Security Domain according to GP CS v2.2 Mapping Guidelines [4] and in accordance with
the configuration given above in section 4.3.1
If Tag '84' was not provided during installation, then as soon as these minimum requirements are met, the
Security Domain is automatically transitioned to the PERSONALIZED state.
Establishment of the initial Secure Channel Keys can be achieved through the Associated Security
Domain or confidential Security Domain personalization.
If the platform supports confidential card content management, it shall follow GP CS v2.2 Amd. A [5] with
the requirements specified in sections 9 and 10. A set of scenarios is specified by this configuration for
confidential Security Domain personalization using the services of the CASD. Requirements on the CASD
are specified in section 10.
When present on the card, the CASD may be involved in one (or more) of the following scenarios after
card issuance:

prohibited.
1. Pull Model, where APSD Secure Channel Keys are generated on-board, and retrieved by the
Application Provider. This scenario will be refered to as scenario #1 in the remaining sections of the
document.
2. Push Model, where APSD Secure Channel Keys are pushed to the card. This model has two
variants for which the origin and the integrity of the pushed keys are ensured by two distinct
mechanisms:
A. One based on the use of an Application Provider Public Key Certificate, signed by the
Controlling Authority. This scenario will be refered to as scenario #2.A in the remaining
sections of this document.
B. Another one based on the use of a temporary Secure Channel Key Set populated by the
LPO (or the entity that created the Security Domain). This scenario will be refered to as
scenario #2.B in the remaining sections of this document.
A card compliant with the UICC configuration may provide support for one or more of these scenarios that
are detailed in section 10.
In these cases, the CASD is installed and fully personalized prior to submission to an issuer (e.g. MNO).
When the CASD is not present on the card, none of these scenarios are supported.
4.4 Secure Channel

A Security Domain is required to open only one Secure Channel session at a time. The UICC is not
required to open more than two Secure Channel sessions at a time.
4.4.1 Secure Channel Protocol Usage

When a Security Domain is the targeted Application, according to ETSI TS 102 225 [1] and ETSI TS 102
226 [2], and does not provide SCP80 capability, the remote APDU command string is unwrapped by the
closest ascendant Security Domain that has a Key Set for SCP80. If the Key Set indicated in SCP80
according to [1] is not present in this Security Domain or no ascendant security Domain has SCP80
capability, the remote APDU command string, as defined in [2], is rejected with the status code
"unidentified security error".
1. Security Domain with no Secure Channel Key Set
a. If the closest ascendant is the associated Security Domain the remote APDU command
string is trusted and processed by the targeted Security Domain according to [2]
b. If the closest ascendant Security Domain is not the associated Security Domain, the
targeted Security Domain may use the SCP02 Secure Channel of its associated Security
Domain to secure each command received in the remote APDU command string

prohibited.
Unwrap SCP80 security

APSD1
SCP80
APSD2
SCP02
APSD3 may use the Secure

Channel of APSD2 to process
APSD3 each command of the remote
No Key Set APDU command string.
Figure 4-3: Targeted Security Domain without a Key Set.
2. Security Domain having one complete Key Set for a Secure Channel;
a. When the targeted Security Domain has a SCP80 Key Set, the security of the remote
APDU command string is unwrapped by the Security Domain itself and processed as
specified in [2]. Any attempt to initiate a SCP02 Secure Channel within the command
script shall be rejected.
b. When the targeted Security Domain does not have a SCP80 Key Set, the remote APDU
command string is not trusted. The Security Domain may use its own SCP02 Secure
Channel to secure each command received in the remote APDU command string
APSD1 APSD 1 unwraps SCP80

SCP80 security
APSD 2 secures each

command, received in the
APSD2 remote APDU format string,
SCP02 using its own secure channel.
Figure 4-4: Targeted Security Domain without SCP80 Capability
4.4.2 Secure Channel Interface Usage

The targeted Security Domain shall use its own Secure Channel or the Secure Channel of its associated
Security Domains if it has no Key Set, to check the remote APDU command string.
1. If the Secure Channel is SCP80, the secure messaging has already been processed before
forwarding the APDU command string to the Security Domain. In this case, a specific behavior is
defined for the SecureChannel(…)Interface;
o SecureChannel.getSecurityLevel(…)is used to verify the Secure Channel security
level
o SecureChannel.processSecurity()throws an ISO Exception with status code
ISO7816.SW_INS_NOT_SUPPORTED
o SecureChannel.unwrap(…)may be called and will not return an error, but will not perform
any additional secure messaging processing
o As the response will be secured implicitly according to the security level defined in ETSI TS
102 225 [1], SecureChannel.wrap()may be called and will not return an error, but will not
do any processing on the outgoing response message

prohibited.
o SecureChannel.encrypt(…) and SecureChannel.decrypt(…) use the Key Identifier

3 of the Key Set Version used to process the SCP80 security (see Annex A of ETSI TS 102
225 [1]). The mode to be used when encrypting and decrypting with DES keys is ECB
o The security level reflects the coding of the SPI as defined in paragraph 5.1.1 of [1];
• AUTHENTICATED | C_MAC: SPI.B1.b2 is set to 1, SPI.B1.b1 is set to 0
• C_DECRYPTION: bit SPI.B1.b3 is set to 1
• R_MAC: bit SPI.B2.b4 is set to 1, SPI.B2.b3 set to 0
• R_ENCRYPTION: bit SPI.B2.b5 is set to 1
o SecureChannel.resetSecurity()throws an ISO Exception with status code
ISO7816.SW_CONDITION_OF_USE_NOT_SATISFIED
2. If the Secure Channel is SCP02, the SecureChannel interface is used to process the security of
each command received in the remote APDU command string according to appendix E of GP CS
v2.2.1 [3].
4.5 Applications
The requirements are defined in section 2.4 of the GP CS v2.2 Mapping Guidelines [4].

prohibited.
5 Data Requirements
The following requirements are for support of data within OPEN and Security Domains.
5.1 AID Values

The initial Issuer Security Domain AID is specified and AID update is managed in accordance with the GP
CS v2.2 Mapping Guidelines [4]. The TAR for compact and expanded format is 'B2 01 00', as defined in
ETSI TS 101 220 [8]. The Application privileges of the Issuer Security Domain are initially set to '9E FE
80'. If the card cannot assign the Card Reset Privilege or the Final Application Privilege to the ISD, then
the initial value is '9A FC 80'. The Trusted Path privilege is mandatory.
The AID for the installable Security Domain Executable Load File (package) and the AID for the
Executable Module (applet) within the GlobalPlatform Registry are defined in section 3.1 of [4]. The Issuer
Security Domain is this Executable Load File’s associated Security Domain.
For UICCs supporting a Controlling Authority Security Domain (CASD), the AID for the CASD Executable
Load file (package) is 'A0 00 00 01 51 53 50 43 41 53 44' and the AID for the CASD Executable Module
(applet) is 'A0 00 00 01 51 53 50 43 41 53 44 00'. The AID for the CASD Application shall be 'A0 00 00 01
51 53 50 43 41 53 44 00' and the TAR value for compact and expanded format is 'B2 02 01', as defined in
ETSI TS 101 220 [8]. The CASD Executable Load File is associated with the Issuer Security Domain.
Upon successful installation, the CASD application is associated with the Issuer Security Domain.
5.2 Issuer Security Domain
5.2.1 Data Store

These requirements are defined in section 3.2.1 of the GP CS v2.2 Mapping Guidelines [4].
5.2.1.1 Card Recognition Data (tag '66')

The Issuer Security Domain may store card Recognition Data as defined below in Table 5-1.

prohibited.
Tag Length Data / Description Presence

'66' '30'-n Card Data Mandatory
'73' '2E'-n Card Recognition Data Mandatory
'06' '07' '2A 8648 86FC6B 01' Mandatory
'60' '0B' Card Management Type & Version Mandatory
'06' '09' '2A 8648 86FC6B 02 02 02' Mandatory
'63' '09' Card Identification Scheme Mandatory
'06' '07' '2A 8648 86FC6B 03' Mandatory
'64' '0B' ISD Secure Channel Protocol & Options Mandatory
'06' '09' '2A 8648 86FC6B 04 80 00' Mandatory
'64' '0B' ISD Secure Channel Protocol & Options Conditional
'06' '09' '2A 8648 86FC6B 04 02 55' Conditional
'65' '0A' Card Configuration Details Optional
'06' '08' '2A 8648 86FC6B 05 04' Conditional
'66' '0C' Card/Chip Details Optional
'0A' '2B 06 01 04 01 2A 02 6E 01 01' Conditional
Java Card 2.1.x
'06'
'2B 06 01 04 01 2A 02 6E 01 02'
Java Card 2.2
Table 5-1: ISD Card Recognition Data
5.2.2 Secure Channel Keys

For SCP02, these requirements are defined in section 3.2.2 of [4].
For SCP80, these requirements are defined in ETSI TS 102 225 [1].
5.2.3 Default Secure Channel Sequence Counter (tag 'C1')

These requirements are defined in section 3.2.3 of [4].
5.2.4 Key Information Template and Key Information Data (tags 'E0' and 'C0')
These requirements are defined in section 3.24 of [4].
5.3 Supplementary Security Domains present on the UICC
5.3.1 Data Store

These requirements are defined in section 3.3.1 of the GP CS v2.2 Mapping Guidelines [4].
5.3.1.1 Security Domain Recognition Data

The Security Domain shall provide the content of Tag '66' as defined below in Table 5-2. The SCP
information shall represent the actual SCP supported by the instance of the Security Domain. This
information is dynamically built in response to each GET DATA request for this Tag value. This information
may be updated using the STORE DATA command.

prohibited.

'66' '23'-n Security Domain Data Mandatory
'73' '21'-n SD Recognition Data Mandatory
'06' '07' '2A 8648 86FC6B 01' Mandatory
'60' '0B' SD Management Type & Version Mandatory
'06' '09' '2A 8648 86FC6B 02 02 02' Mandatory
'63' '09' SD Identification Scheme Mandatory
'06' '07' '2A 8648 86FC6B 03' Mandatory
'64' '0B' SD Secure Channel Protocol & Options Conditional
'64' '0B' SD Secure Channel Protocol & Options Conditional
'65' '0B' SD Configuration Details Optional
'09' '2A 8648 86FC6B 05' + APSD Conditional
'06'
capability info
Table 5-2: Security Domain Recognition Data
5.3.2 Secure Channel Keys

For SCP02, these requirements are defined in section 3.2.2 of the GP CS v2.2 Mapping Guidelines [4].
For SCP80, these requirements are defined in ETSI TS 102 225 [1].
5.3.3 DAP Verification Key

For implementations that support public key cryptography, both RSA and DES schemes shall be
implemented.
5.3.4 Default Secure Channel Sequence Counter (tag 'C1')

5.3.5 Key Information Template and Key Information Data (tags 'E0' and 'C0')
5.3.6 Token Verification Key

For implementations that support public key cryptography, both RSA and DES schemes shall be
implemented.

prohibited.
6 Key Usage
Each Security Domain requires keys for Secure Messaging and to perform the functions associated with
its privileges. The Key Version Numbers identifying these keys are listed below.
• Key Version number range ('20' to '2F') is reserved for SCP02
o Key identifier '01' defines the encryption key as specified in sections 3.3.2 and 4 of the GP
CS v2.2 Mapping Guidelines [4]
o Key identifier '02' defines the MAC key as specified in sections 3.3.2 and 4 of [4]
o Key identifier '03' defines the data encryption key (DEK) as specified in sections 3.3.2 and
4 of [4]
• Key Version 'FF' is reserved for use by an Issuer Security Domain supporting SCP02, and cannot
be used for SCP80. This initial key set shall be replaced by a key set with a Key Version Number
in the ('20' to '2F') range.
• Key Version number range ('01' to '0F') is reserved for SCP80
• Key Version number '70' with Key Identifier '01' is reserved for the Token Key, which is either a
RSA public key or a DES key
• Key Version number '71' with Key Identifier '01' is reserved for the Receipt Key, which is a DES
key
• Key Version Number '11' is reserved for DAP as specified in ETSI TS 102 226 [2]
• Key Version Number '73' with Key Identifier '01' is reserved for the DAP verification key as
specified in sections 3.3.3 and 4 of [4], which is either an RSA public key or DES key
• Key Version Number '74' is reserved for the CASD Keys (cf. section 9.2)
o Key identifier '01' is reserved for PK.CA.AUT
o Key identifier '02' is reserved for SK.CASD.AUT (PK) and KS.CASD.AUT (Non-PK)
o Key identifier '03' is reserved for SK.CASD.CT (PK) and KS.CASD.CT (Non-PK)
• Key Version Number '75' with Key Identifier '01' is reserved for the key used to decipher the
Ciphered Load File Data Block described in section 4.8 of [5]. This key shall be a 16-byte DES
key. When ciphering the Load File Data Block, CBC mode with null ICV shall be used. Padding
shall be according to Annex B.4 of GP CS v2.2.1 [3].
An implementation of this configuration is not required to reject, but may do so, the loading of any of the
above keys when a Security Domain does not have the relevant usage privilege(s) for a key.
For a Security Domain that supports both SCP02 and SPC80 and receives an INITIALIZE UPDATE
command with a Key Version Number outside of the range reserved for SCP02, the command shall fail
and return a response of '6985'.
Initially for a Supplementary Security Domain on a UICC, no keys exist and the Security Domain uses the
keys of its associated Security Domain to set up a Secure Channel.
Management of any of the above keys is possible using either a PUT KEY command or the STORE DATA
command according to the following rules:

prohibited.
• If PUT KEY or STORE DATA is used within a Secure Channel according to SCP80, the provisions
of ETSI TS 102 226 [2] shall apply. For creating or updating keys with a KVN greater than '0F', the
DEK of the Secure Channel Key Set shall be used. It shall not be possible to use the DEK key
type single DES to update or create triple DES keys or RSA private keys, if any
• If PUT KEY or STORE DATA is used within a Secure Channel according to SCP02, SCP02 keys,
SCP80 keys and all other keys referenced in this document may be updated or created according
to section 6.9 of GP CS v2.2 Mapping Guidelines [4]

prohibited.
7 Delegated Management
7.1 Delegated Management Keys and tag
7.1.1 Token Key

A Security Domain with Token Verification privilege has one Token Verification Key, which is either a
1024-bit RSA public key or a double-length DES key. This Key is not used for Secure Channel initiation.
7.1.2 Receipt Key

A Security Domain with Receipt Generation privilege has one Receipt Generation Key, which is a double-
length DES key used to generate load, install, or delete receipts. This Key is not used for Secure Channel
initiation.
7.2 Token Computation and Verification

Tokens must be provided when the Delegated Management operation requires a pre-authorization. This
Token is the command signature using the Private or secret Key.
For the Token Generation, the tags 'B6', '42', and '45' shall be present in the INSTALL and DELETE
commands. The Security Domain with the Token Verification privilege shall check the consistency of the
values for tags '42' and '45'.
7.2.1 RSA Scheme

The description of the RSA scheme is defined in the section C.4 of the GP CS v2.2.1 [3].
7.2.2 DES Scheme

This scheme is as defined in section 4.7 of the GP CS v2.2 Amd. A [5]. The token length is 8 bytes.
7.3 Delegated Management Receipt

The descriptions of the Receipt schemes using symmetric keys are defined in section C.5 of [3]. Only
symmetric key schemes are supported.
Confirmation data shall include the Token Identifier that was present in tag 'B6' in the command data field
(see section 7.2).

prohibited.
8 APDU Commands
The commands described in this section are the following:
• DELETE
• GET DATA
• GET STATUS
• INSTALL
o INSTALL [for load]
o INSTALL [for install]
o INSTALL [for install and make selectable]
o INSTALL [for make selectable]
o INSTALL [for extradition]
o INSTALL [for registry update]
o INSTALL [for personalization]
• LOAD
• MANAGE CHANNEL
• PUT KEY (DES Keys)
• PUT KEY (RSA Public Key)
• SELECT
• SET STATUS
• STORE DATA
8.1 DELETE
Deletion of Applications or Executable Load Files is defined in section 11.2.2.3.1 of the GP CS v2.2.1 [3].
The recommendations regarding the command message data field, Card Life Cycle checks and status
words of section 6.1.2 of the GP CS v2.2 Mapping Guidelines [4] apply. The following overrides the
provisions in [4]: If the AID references the Issuer Security Domain, a response of '6A88' or '6985' is
returned.
The support of key deletion is optional. All of the Key Sets for a Security Domain may be deleted. If the
default Key Set is deleted, and one or more Key Sets remain, another Key Set becomes the new default
Key Set. The determination of the new default Key Set is UICC implementation-dependent.
The Key Set number is returned in the response to the INITIALIZE UPDATE command when executed
with the P1 = 0 (i.e. the default Key Set).
The presence of tags 'B6' and '9E' (Delete Token) is mandatory when the Security Domain processing this
command has the Delegated Management privilege.
8.2 GET DATA

This command is defined in section 6.3 of [4].

prohibited.
8.2.1 Command Message

Parameters P1 and P2
The parameters P1 and P2 define the tag of the data object to be read. The following tags are processed:
Tag
Length (Le) Meaning
(P1,P2)
1
'00','42' Var Card Issuer or Security Domain Provider Identifcation Number
1
'00','45' Var Card or Security Domain Image Number
3
'00','EE' Var Card Profile Unique Identifier
1
'00','CF' '0A' User Key diversification data
1
'00','E0' Var Key Information Template
1
'00','C1' '04' Sequence Counter of the default Key Version Number (Implicit Key Version )
1
'00','C2' '02' Confirmation Counter (conditionally supported)
1
'00','66' Var Card Recognition Data
2
'FF','1F' Var Menu Parameters Tag
2
'FF','20' '03' Card Resources Tag
2
'FF','21' Var Extended Card Resources Tag
4
'7F','21' Var Security Domain’s certificate store
Table 8-1: Data objects readable with GET DATA command

Note 1: these tags are described in the GP CS v2.2 Mapping Guidelines [4].
Note 2: these tags are described in ETSI TS 102 226 [2].
Note 3: this tag is described in the GP Card Customization Guide v1.0 [11].
Note 4: this tag is described in GP CS v2.2 Amd. A [5].
Data Field
In case of a GET DATA Menu Parameters the command data are coded as defined in [2].
In the other cases, the data field of the command message is empty unless a Message Authentication
Code is used.
8.3 GET STATUS

This command is defined in section 11.4 of the GP CS v2.2.1 [3]. The recommendations for the command
and response messages data field, Card Life Cycle, and status words of section 6.4.2 of [4] apply.
However, the following rule overrides the provisions in [4]: If the AID references the Issuer Security
Domain, a response of '6A88' or '6985' shall be returned.
Information relating to the API packages may be returned in the response to this command as Executable
Load Files.
The GET STATUS command applies to all Security Domains as defined by [3].

prohibited.
8.4 INSTALL
This command is defined in section 6.6 of [4]. In this configuration, the Delegated Management and some
tags defined by ETSI are supported, and therefore some features have been added. All Card Content
Management rules defined in section 9 of [3] apply.
8.4.1 INSTALL [for load]
General
A UICC is not required to open more than one card content loading session at a time.
Security Domain AID

At the request of OPEN, a Security Domain accepts an implicit Extradition if:
• its Life Cycle State is PERSONALIZED and,
• the Security Domain Provider's policy defined in Tag '82' of the Security Domain's Application
Specific Parameters (see section 4.3.2 and Table 4-3) allows acceptance of this implicit extradition
Otherwise, the Security Domain rejects the implicit Extradition and a response of '6985' is returned.
Load File Data Block Hash

The presence of the Load File Data Block Hash is required for the following cases:
• If the Supplementary Security Domain associated to the executable load file has the DAP
Verification privilege, or
• If a Security Domain with Mandated DAP is present, or
• If the Supplementary Security Domain performing the load has the Delegated Management privilege,
or
• If the Supplementary Security Domain associated to the executable load file has the Ciphered Load
File Data Block privilege (see section 9.1.3.7 of GP CS v2.2.1 [3]).
Load Token
If the Supplementary Security Domain performing the load has the Delegated Management privilege, then
the content of this field is present.
Ciphered Load File Data Block privilege

The Ciphered Load File Data Block privilege is as specified in section 9.1.3.7 of [3].
8.4.2 INSTALL [for install]
Application Privileges
The Application Privileges data field is checked against the list of privileges that are supported according
to Table 4-1.
Install Parameters
The tag 'CB' shall be supported; however its presence in the data field is conditional.
Tags 'CA' and 'EA' are supported. Their presence and content are as defined in ETSI TS 102 226 [2].

prohibited.
Install Token
If the Supplementary Security Domain performing the install command has the Delegated Management
privilege, then the content of this field is present.
8.4.3 INSTALL [for install and make selectable]
Application Privileges
The Application Privileges data field is checked against the list of privileges that are supported according
to Table 4-1.
Install and Make Selectable Parameters

The tag 'CB' shall be supported; however its presence in the data field is conditional.
Tags 'CA' and 'EA' are supported. Their presence and content are as defined in ETSI TS 102 226 [2].
Install and Make Selectable Token

If the Supplementary Security Domain performing the installation has the Delegated Management
8.4.4 INSTALL [for make selectable]
Make Selectable Token

If the Supplementary Security Domain performing the install command has the Delegated Management
8.4.5 INSTALL [for extradition]
Security Domain AID

At the request of OPEN, a Security Domain accepts an explicit Extradition if the following conditions are
met:
• its Life Cycle State is PERSONALIZED or the Security Domain has the Authorized Management
Privilege and is being extradited to itself, and
• the Security Domain Provider's policy defined in Tag '82' of the Security Domain's Application
Specific Parameters (see section 4.3.2 and Table 4-3) allows acceptance of this Extradition, and
• the Security Domain performing the Extradition is an ancestor Security Domain of the Security
Domain, Application, or Executable Load File referenced by this AID.
Otherwise, the Security Domain rejects the explicit Extradition and a response of '6985' is returned.
Application AID
If this AID does not reference an Application associated to the Security Domain processing the command,
a response of '6985' is returned.
Extradition Token
If the Supplementary Security Domain performing the extradition has the Delegated Management privilege
the content of this field is present.

prohibited.
8.4.6 INSTALL [for registry update]

The command shall only be processed by the Issuer Security Domain according to section 6.6.2 of GP CS
v2.2 Mapping Guidelines [4].
8.4.7 INSTALL [for personalization]

All Security Domains shall support this mechanism (i.e. the INSTALL [for personalization] command and
the subsequent STORE DATA commands) to personalize their associated applications. Refer to section
7.3.3 of the GP CS v2.2.1 [3] for the description of OPEN relating to the personalization of an Application.
Refer to Table 11-47 of [3] for the data field structure of this command. If the data field is not formatted
correctly (i.e. missing or incorrect length fields), a response of '6A80' is returned. The following
requirements exist for this field:
Application AID
The Application AID references an Application within the GlobalPlatform Registry that is associated to the
Security Domain to which this command is submitted. If this value does not reference an Application in the
GlobalPlatform Registry, a response of '6A88' is returned. If this value does not reference an Application
associated to the Security Domain to which this command is submitted, a response of '6985' is returned.
The successful processing of the above field results in the following:
The subsequent STORE DATA command(s) would be pre-processed by the Security Domain according to
the current Secure Channel prior the command being forwarded to the application being personalized. In
the case that the Associated Application is not a Security Domain, refer to section 11.11 of [3] and GP CS
v2.2 Amd A [5] for the structure of the subsequent STORE DATA commands. In the case that the
Associated Application is a Security Domain, refer to section 8.11.
If an attempt is made to personalize a Security Domain which is already in the PERSONALIZED life cycle
state during the processData() operation, it shall fail and return a response of '6985'.
8.5 LOAD
This command is defined in section 6.7 of the GP CS v2.2 Mapping Guidelines [4].
The Tag 'D4' is supported as defined in [5].
An implementation of this configuration shall support the presence of more than one DAP block in the
Load File.
8.6 MANAGE CHANNEL

8.7 PUT KEY (DES KEYS)

This command is defined in section 11.8 of the GP CS v2.2 [3], but with the considerations given in
section 6. A specific card implementation is not required to reject (but may do so) the loading of keys that
are not defined in section 6, Key Usage.
Command Message
Both formats 1 and 2 are supported.
The following Key Type is supported:

prohibited.
• '80': (ECB/CBC) implicitly known
Response Message
SW1 SW2 Meaning

'65' '81' Memory failure
'6A' '84' Not enough memory space
'6A' '88' Referenced data not found
'94' '84' Algorithm not supported
'6A' '80' ISO compliant standard status word for Algorithm not
supported
'94' '85' Invalid key check value
'69' '82' ISO compliant standard status word for Invalid key check value
Table 8-2: Processing State returned in the PUT KEY (DES Key) Response Message
8.8 PUT KEY (RSA PUBLIC KEY)

This command is defined in section 6.10 of the GP CS v2.2 Mapping Guidelines [4]. A specific card
implementation is not required to reject (but may do so) the loading of keys that are not defined in section
6, Key Usage. The exponent value shall not be checked.
Response Message
SW1 SW2 Meaning

'65' '81' Memory failure
'6A' '84' Not enough memory space
'6A' '88' Referenced data not found
'94' '84' Algorithm not supported
'6A' '80' ISO compliant standard status word for Algorithm not
supported
'94' '85' Invalid key check value
'69' '82' ISO compliant standard status word for Invalid key check value
Table 8-3: Processing State returned in the PUT KEY (RSA Public Key) Response Message
8.9 SELECT
This command defined in section 6.11 of [4] and ETSI TS 102 221 [7].
8.10 SET STATUS

A Security Domain with the Authorized Management privilege is permitted to lock itself or any Application
and Security Domain within the hierarchy consisting of itself and its own descendents. A Security Domain
with the Authorized Management privilege is permitted to unlock any Application and Security Domain
within the hierarchy consisting of its descendents.

prohibited.
8.11 STORE DATA

This command is defined in section 6.13 of [4], with the additional considerations provided in section 6. If
scenario #1 is supported by the CASD (see section 9), the P1 parameter shall be interpreted as described
in section 4.4 of GP CS v2.2 Amd. A [5] in order to support the ISO 7816-4 case 4 variant of this
command.
The DGI '9F70' is used to transition the life cycle state of any Security Domain. Additionally, the DGIs
defined in the GP CS v2.2 Amd. A [5] as well as DGIs defined in chapters 10 and 11 are supported
conditionally. The DGI formatting rules are defined in GP Systems Scripting [9].

prohibited.
9 Controlling Authority Security Domain (CASD)

To enable the confidential loading of an initial Secure Channel Key Set for newly created Security
Domains, a Controlling Authority Security Domain (CASD) shall be installed and fully personalized before
the card is provided to an issuer (e.g. MNO).
Only a single CASD instance (known as "the" CASD) may be installed on the card. To proceed with this
installation, the use of CASD load file, module and instance AIDs defined in section 5.1 are required. The
installation shall fail if attempted when the card is in the SECURED life cycle state.
The CASD supports either Secure Channel Protocol '02' (SCP02) with implementation option '55' (as
defined in appendix E of the GP CS v2.2.1 [3] and according to recommendations described in section 5
of the GP CS v2.2 Mapping Guidelines [4]), or Secure Channel Protocol '80' (SCP80) (as defined in ETSI
TS 102 225 [1]), or both.
As defined in GP CS v2.2 Amd. A [5], the CASD shall register an implementation of the Authority
interface as a unique Global Service.
9.1 CASD Management Data

For interoperability purpose, the CASD is required to expose its capabilities so that off-card entities know
which Confidential SD Personalization scenarios are supported by the card. The card may support several
scenarios. These scenarios are briefly introduced in section 4.3.3, and precisely described in section 10.
To expose its capabilities, the CASD shall provide off-card entities with the following Security Domain
Management Data, upon reception of a GET DATA command for tag '66' (as described in sections H.2
and H.3 of [3]):

'66' Security Domain Data Mandatory
'73' SD Recognition Data Mandatory
'06' '07' '2A 8648 86FC6B 01' Mandatory
'60' '0B' SD Management Type & Version Mandatory
'06' '09' '2A 8648 86FC6B 02 02 02' Mandatory
'63' '09' SD Identification Scheme Mandatory
'06' '07' '2A 8648 86FC6B 03' Mandatory
'64' '0B' SD Secure Channel Protocol & Options Mandatory
'06' '09' '2A 8648 86FC6B 04 02 55' Mandatory
'64' '0B' SD Secure Channel Protocol & Options Optional
'65' '0B' SD Configuration Details Mandatory
'06' '09' '2A 8648 86FC6B 05' + CASD capability info Mandatory
Table 9-1: CASD Management Data

prohibited.
CASD capability information is encoded on 2 bytes as follows:
8 7 6 5 4 3 2 1
b b b b b b b b Description
0 0 0 0 0 - - 1 Support for Confidential SD Personalization using Scenario #1
0 0 0 0 0 - 1 - Support for Confidential SD Personalization using Scenario #2.A
0 0 0 0 0 1 - - Support for Confidential SD Personalization using Scenario #2.B
x x x x x - - - RFU (0)
Table 9-2: CASD Capability Information (Byte 1): Supported Scenarios
8 7 6 5 4 3 2 1
b b b b b b b b Description
x x x x x x x 1 Support for PK scheme
x x x x x x x - RFU (0)
Table 9-3: CASD Capability Information (Byte 2): Supported Scenario Options
Byte 1 indicates which Confidential SD Personalization scenarios are supported by the card:
- Bit B1.b1 indicates whether scenario #1 is supported
- Bit B1.b2 indicates whether scenario #2.A is supported
- Bit B1.b3 indicates whether scenario #2.B is supported
- Other bits are reserved for future use (RFU)
NOTE: Whether a particular scenario is supported or not, will depend on the following conditions:
- The implementation of the CASD actually provides support for this scenario
- The CASD has been personalized with the keys and certificates required for this scenario
Byte 2 provides further indications on scenario options that are supported by the card:
- Bit B2.b1 indicates whether a PK scheme shall be used in conjunction with supported scenarios
(as indicated in Byte 1). Usage of PK scheme shall always be indicated on a card supporting PK
cryptography. Non-PK schemes are reserved for Non-PK cards
Currently, only Scenario #1 (Pull Model) defines both a PK scheme and a Non-PK scheme.
Scenario #2.A and #2.B (Push Model) define only a PK scheme
- Other bits are reserved for future use (RFU)
9.2 CASD Keys and Certificates

The CASD shall implement a PK scheme on cards providing support for PK cryptography, and a Non-PK
scheme on cards implementing symmetric cryptography only.

prohibited.
- Using the PK scheme, the CASD holds a number of asymmetric keys and certificates to perform
Signature, Encyrption and Certificate Verification. All certificates stored and/or processed by the
CASD are signed off-card using a valid CA Private Key (SK.CA.AUT) and may be verified off-card
using corresponding CA Public Key (PK.CA.AUT). All asymmetric keys shall be 1024-bit RSA
2
keys
- Using the Non-PK scheme, the CASD holds two distinct 16-byte DES keys, one for decryption
(KS.CASD.CT) and one for signature verification (KS.CASD.AUT).
9.2.1 Support for Public Key Scheme

The CASD shall provide off-card entities with a suitable Public Key Certificate:
- The GET DATA command shall be used with tag '7F21' to retrieve CA certificate store, from which it
shall be possible to extract at least one of the following CASD certificates:
o CERT.CASD.AUT, a CASD certificate suitable for use with scenario #1
o CERT.CASD.CT, a CASD certificate suitable for use with scenario #2.A and #2.B
CASD certificates shall be bound to their hosting cards (e.g. CSN, IIN and/or CIN). Some other card
information, certified by the Controlling Authority, may also be included in these certificates (e.g.
security evaluation level).
The AP is required to check the validity of any CASD certificate retrieved from the card, using a valid
CA Public Key (hereafter referred to as PK.CA.AUT), and from each such certificate, it shall recover
the corresponding CASD Public Key.
The CASD shall be able to store the following certificates and keys:
- The STORE DATA command (see section 4.10 of GP CS v2.2 Amd. A [5]) shall be used to store the
following keys:
o CA Public Key: PK.CA.AUT (KVN='74', KID='01')
o CASD Private Key for Signature: SK.CASD.AUT (KVN='74', KID='02')
o CASD Private Key for Decryption: SK.CASD.CT (KVN='74', KID='03')
- The STORE DATA command shall be used with DGI '7F21' to store CA certificate store
3
The use of signature with message recovery is recommended to generate small-sized certificates.
2
In this configuration, some mechanisms have been tuned so that data returned to off-card entities can fit within GET
DATA responses. Typically, the length of RSA key pairs (CASD, APSD) has a direct impact on this. The use of longer
RSA keys may be enabled in future versions of this document.
3
A suitable signature algorithm is the one described in ISO/IEC 9796-2 [10], using Digital Signature Scheme 1, the SHA-
1 hash function and trailer field option 1.

prohibited.
Table 9-4 describes the structure of a certificate based on the use of signature with message recovery:
Tag Length Description Presence

'7F21' Var. Certificate Mandatory
'93' 1-16 Certificate Serial Number Mandatory
'42' 1-16 CA Identifier Mandatory
'5F20' 1-16 Subject Identifier Mandatory
'95' 1 Key Usage
('82' digital signature verification, or
Mandatory
'88' encipherment for confidentiality)
ref. Table 11-17 of the GP CS v2.2.1 [3]
'5F25' 4 Effective Date (YYYYMMDD, BCD format) Optional
'5F24' 4 Expiration Date (YYYYMMDD, BCD format) Mandatory
'45' 1-16 CA Security Domain Image Number Mandatory
'53' 1-127 Discretionary Data Optional
'5F37' Var. Signature Mandatory
'5F38' Var. Public Key Modulus Remainder Mandatory
Table 9-4: CASD Certificate Structure (Certificate with Message Recovery)
Table 9-5 describes data (TLV-encoded) signed using the CA Private Key (SK.CA.AUT, private
counterpart of PK.CA.AUT) to generate a Certificate with message recovery:

'7F49' Var. Public Key Mandatory
- '82' '01' or '03' Public Key Exponent Mandatory
- '81' Var Public Key Modulus Mandatory
'5F25' 4 Effective Date (YYYYMMDD, BCD format) Conditional
'95' 1 Key Usage
Mandatory
ref. Table 11-17 of [3]
'45' 1-16 CA Security Domain Image Number Mandatory
'53' 1-127 Discretionary Data Conditional
Table 9-5: Data signed to generate a CASD Certificate with Message Recovery
The data recovered from the verification of the signature (tag '5F37'), as described in [10], includes part
of tag '7F49', including tag '82' and part of tag '81' (Public Key Modulus leftmost bytes). Public Key
Modulus rightmost bytes (Remainder) are retrieved from tag '5F38'.
Note: The Subject Identifier is a unique identifier of the owner of the public key that is certified. The CA
Identifier is a unique identifier of the owner of the key pair that has been used to produce the certificate.

prohibited.
9.2.2 Support for Non-Public Key Scheme

The CASD shall store secret symmetric keys for encryption and signature verification.
The PUT KEY command or the STORE DATA command (according to [5]) shall be used to store the
following keys:
o CASD Signature Key: KS.CASD.AUT (KVN='74', KID='02')
o CASD Encryption Key: KS.CASD.CT (KVN='74', KID='03')
9.3 Support for Authority Interface (Global Service)

An implementation of the Authority interface shall be registered during the installation of the CASD as a
unique Global Service instance under Service Family Identifier '83' (see section 5.2 of [5]). The registration
shall fail if the card has already reached the SECURED life cycle state. Only Security Domains shall be
able to use this Global Service.

prohibited.
10 Confidential Setup of Secure Channel Keys

Enabled by the presence and the capabilities of the CASD (see section 9.1), one of the following
scenarios may be used once, and once only, to confidentially personalize a set of Secure Channel Keys of
a Security Domain.
For all scenarios, the CASD can be invoked even if the APSD is already in the PERSONALIZED state. In
this case, all previously loaded keysets for the APSD are discarded.
10.1 Scenario #1 (Pull Model)

This scenario is used to pull Secure Channel Keys from the APSD. This scenario has two variants: one
using a PK scheme, the other using a Non-PK scheme. The use of a particular variant is bound to the
capabilities of the CASD, as described in section 9.1.
When the PK scheme is used, a RSA Public Key is retrieved by the APSD (using the service of the CASD)
from a Public Key Certificate sent by its provider.
When the Non-PK scheme is used, the APSD is provided with a symmetric key bound to its provider,
which was previously encrypted and signed by the CA.
The APSD key (symmetric or asymmetric) is used by the APSD to encrypt the keys that are generated on
card.
Figure 10-1 and Figure 10-2 illustrate how scenario #1 can be used to confidentially personalize an initial
set for Secure Channel Keys for a Security Domain, using the PK scheme and the Non-PK scheme,
respectively. These diagrams also show how a Link Platform Operator (LPO) that is not trusted by the
Application Provider is involved in this scenario.

prohibited.
Off-Card LPO UICC
Optional step: (SELECT CASD)

Not required when OTA link is used.
(SELECT Response)
GET DATA ['7F21']

Retrieve CA certificate store. CA certificate store is returned.
[certificates]
- Forward response to Application Provider.
- Application Provider verifies CERT.CASD.AUT and
recovers PK.CASD.AUT.
Optional step: (SELECT SD)

(SELECT Response)
Secure Channel Setup
Establish a secure channel. A secure channel is established.
(done)
INSTALL [for install] APSD

Create a new Supplementary Security Domain for A new Supplementary Security Domain is created.
the Application Provider.
INSTALL Response
INSTALL [for personalization] APSD

Personalize the Supplementary Security
A new personalization session is started.
Domain on behalf of the Application Provider.
INSTALL Response
STORE DATA [CERT.AP.CT]

Application Provider sends CERT.AP.CT - CASD verifies CERT.AP.CT using PK.CA.AUT.
(previously signed using SK.CA.AUT) to - APSD recovers and stores PK.AP.CT.
APSD.
STORE DATA Response
STORE DATA [On-board Key Generation]

Request on-board key generation by APSD. - APSD triggers on-board key generation (RGK).
- APSD encrypts RGK using PK.AP.CT.
- CASD signs encrypted data using SK.CASD.AUT.
Signed/Encrypted RGK
- Application Provider verifies signature using PK.CASD.AUT.
- Application Provider decrypts RGK using SK.AP.CT.
- Application Provider derives Secure Channel keys from RGK.
Figure 10-1: Scenario #1 (Pull Model), using PK scheme

prohibited.
Off-Card LPO UICC
Optional step: (SELECT SD)

(SELECT Response)
(done)

Create a new Supplementary Security Domain for A new Supplementary Security Domain is created.
the Application Provider.
INSTALL Response
INSTALL [for personalization] APSD

INSTALL Response
STORE DATA [KS.AP.CT]

- CA encrypts KS.AP.CT using KS.CASD.CT, upon - CASD verifies KS.AP.CT using KS.CASD.AUT.
demand from the Application Provider. - CASD decrypts KS.AP.CT using KS.CASD.CT
- CA signs encrypted data using KS.CASD.AUT. - APSD recovers and stores KS.AP.CT.
- Application Provider sends encrypted/signed data to
APSD.
STORE DATA Response
STORE DATA [On-board Key Generation]

Request on-board key generation by APSD. - APSD triggers on-board key generation (RGK).
- APSD encrypts RGK using KS.AP.CT.
- CASD signs encrypted data using KS.CASD.AUT.
Signed/Encrypted RGK
- Application Provider requests signature verification from CA
services.
- Application Provider decrypts RGK using KS.AP.CT.
- Application Provider derives Secure Channel keys from RGK.
Figure 10-2: Scenario #1 (Pull Model), using Non-PK scheme
10.1.1 Presenting AP Public Key Certificate

This section describes how to load the AP Public Key Certificate (CERT.AP.CT) according to section 4.3
of the GP CS v2.2 Amd. A [5] when the CASD provides support for PK scheme (refer to section 10.2.1).
The AP Public Key Certificate (CERT.AP.CT) shall be a non-self descriptive certificate generated using
signature with message recovery as described in ISO/IEC 9796-2 [10], using Digital Signature Scheme 1,
the SHA-1 hash function and trailer field option 1. The Application Provider's Public Key (PK.AP.CT) shall
be a 1024-bit RSA Public Key.
DGI '00DE' is used to send CERT.AP.CT to the APSD:
DGI Length Description

Certificate with Message Recovery
'00DE' Var.
(signature algorithm described in [10]])
Table 10-1: DGI '00DE' for AP Public Key Certificate

prohibited.
The content of DGI '00DE' is as follows:

'7F21' Var. Certificate Mandatory
'95' 1 Key Usage
Mandatory
ref. Table 11.17 of the GP CS v2.2.1 [3]
'5F25' 4 Effective Date (YYYYMMDD, BCD format) Optional
'53' 1-127 Discretionary Data Optional
'5F37' Var. Signature Mandatory
'5F38' Var. Public Key Modulus Remainder Mandatory
Table 10-2: Structure of AP Public Key Certificate with Message Recovery
Verification of the certificate Expiration Date is optional and beyond the scope of this configuration.
The following TLV-encoded data are signed off-card with SK.CA.AUT to generate the content of tag '5F37'
(signature), as described in [10]:

'7F49' Var. Public Key Mandatory
- '82' '01' or '03' Public Key Exponent Mandatory
- '81' Var Public Key Modulus Mandatory
'95' 1 Key Usage
Mandatory
ref. Table 11.17 of the GP CS v2.2.1 [3]
'5F25' 4 Effective Date (YYYYMMDD, BCD format) Conditional
'53' 1-127 Discretionary Data Conditional
Table 10-3: Data signed to generate the AP Public Key Certificate with Message Recovery
The LV format is used to allow for flexible CA identification schemes.

prohibited.
The CASD is responsible for verifying the certificate using PK.CA.AUT. More precisely, the APSD shall
provide the CASD with tag '7F21' (certificate), using the Authority interface in MODE_KEY_RECOVERY
mode. Upon successful verification, the CASD shall copy the following structure recovered from the
verification of the certificate, at the location specified by the APSD in the call to the
Authority.recoverKey() method:
Length Description
1 Public Key Exponent Length ('01' or '03')
1 or 3 Public Key Exponent Value
1 Public Key Modulus Length ('80')
Var. Public Key Modulus Value
Table 10-4: Key data recovered from AP Public Key Certificate verification
NOTE: The Public Key Modulus leftmost bytes are recovered from the verification of the signature
('5F37'). The Public Key Modulus rightmost bytes are recovered from the Public Key Modulus
Remainder ('5F38').
The certificate is sent to the card to store corresponding public key but there is no need for an off-card
entity to retrieve it. The certificate is discarded once the public key has been stored.
The AP Public Key (PK.AP.CT) shall be discarded as soon as a Secure Channel Key Set has been
successfully generated and the on-card generated secret has been sent back to the Application Provider.
10.1.2 Loading AP Symmetric Key

This section describes how to load the AP Symmetric Key (KS.AP.CT) according to section 4.3 of GP CS
v2.2 Amd. A [5]] when the CASD provides support for the Non-PK scheme (refer to section 9.2.2). The
KS.AP.CT key is a double-length DES key.
DGI '00B8', '80B8' and '00AE' (defined in [5]) shall be sent to the APSD, in order to push the KS.AP.CT.
DGI '00B8' provides meta-information on the KS.AP.CT.The content of DGI '00B8' is as follows:

'B8' 9 Template (CT) Mandatory
Key Usage Qualifier = '40' Mandatory
'95' 1
(encryption of sensitive data in responses)
'80' 1 Key Type = '80' (DES) Mandatory
'81' 1 Key Length = '10' Mandatory
Table 10-5: Content of DGI '00B8' content for AP Symmetric Key Meta-Data
DGI '80B8' contains the encrypted value of the KS.AP.CT.

The KS.AP.CT is encrypted (using KS.CASD.CT) by the Controlling Authority using Triple DES algorithm
(in ECB mode).
DGI '00AE' provides integrity data for the KS.AP.CT. The content of DGI '00AE' is as follows:
Tag Length Description

'8E' 8 Signature of (DGI '00B8' || DGI '80B8')
Table 10-6: Content of DGI '00AE' for AP Symmetric Key Integrity Signature

prohibited.
The content of tag '8E' is a signature generated by the Controlling Authority over the concatenation of DGI
'00B8' and DGI '80B8', using Single DES + Final Triple DES algorithm (see GP CS v2.2.1 [3] – Appendix
B.1.2.2) with padding as defined in Annex B.4 of [3].
The APSD shall provide the CASD with the concatenation of DGI '00B8', '80B8' and '00AE', using the
Authority interface in MODE_KEY_RECOVERY mode. The CASD shall verify the signature provided
within tag '8E' (using KS.CASD.AUT) and decrypt DGI '80B8' (using KS.CASD.CT). The CASD shall then
copy the decrypted value of the KS.AP.CT at the location specified by the APSD in the call to the
Authority.recoverKey() method.
The APSD is then responsible for reading and storing KS.AP.CT.
The KS.AP.CT key shall be discarded as soon as a Secure Channel Key Set has been successfully
generated and the on-card generated secret has been sent back to the Application Provider.
10.1.3 Pulling AP Secure Channel Keys

DGI '00A6' is sent to the APSD to trigger on-card key generation and provides identification data for the
generated keys. The content of DGI '00A6' is as follows:

'A6' Var. Template (CRT) Mandatory
'90' 1 Scenario Identifier '01' Mandatory
'95' 1
(secure messaging in command data fields)
'83' 1 Key Version Number = '01' – '7F' Optional
'91' 2 or 5 Initial value of sequence counter Optional
'45' Max. 8 Security Domain Image Number (SDIN) Optional
Table 10-7: Content of DGI '00A6' (Pull Model)
Tag 'A6' provides identification data for 3 Secure Channel Keys.
Tag '83' is used to specify a Key Version Number for the generated Key Set. When the APSD supports
more than one Secure Channel Protocol, using this tag is mandatory (otherwise, the command is
rejected), and this Key Version Number indicates the Secure Channel Protocol to which the generated
Key Set shall be bound (either SCP80 or SCP02), as described in section 6. If a single Secure Channel
Protocol is supported, and this tag is not present, the generated Key Set will be assigned an implicit Key
Version Number of '01'. Key Identifiers are implicitly known as '01', '02 and '03' respectively for ENC, MAC
and DEK keys.
Tag '91' is optional and can be used to specify the initial value of the sequence counter associated with a
specified Key Version Number. The length of the value shall be consistent with the protocol associated
with this Key Set. If this tag is not present, this initial value is implicitly known as 0.
Finally, tag '45' may be provided to link the on-card generated secret (see below) to the APSD, that is, tag
'45' if provided, will be part of the data signed by the CASD (see Table 10-8).
Upon reception of DGI '00A6', a Randomly Generated Key (RGK) is generated, and the three Secure
Channel Keys are derived from RGK as specified in section 4.6 of GP CS v2.2 Amd. A [5]. Then, the
generated Secure Channel Keys are stored by the APSD according to identification data supplied in tag
'A6'.
The RGK is then ciphered, signed and sent back to the AP, as specified in section 4.4 of [5]:

prohibited.
- Depending on the type of the AP encryption key, symmetric (KS.AP.CT) or asymmetric (PK.AP.CT),
either RSA algorithm or Triple DES algorithm (CBC mode with NULL 8-byte ICV) shall be used to
encrypt the RGK. The length of the RGK is known. PKCS#1 v1.5 padding for encryption shall be
used in the case of RSA (see PKCS#1 [12]). Padding is not applied for Triple DES.
- The APSD shall then provide the CASD with the following data, using the Authority interface in
MODE_SIGN mode:
Length Description
1 Length of AP Security Domain AID
5-16 AP Security Domain AID
1 Length of Control Reference Information
Var. Control Reference Information (Content of 'A6')
1 Length of Encrypted RGK
Var. Encrypted RGK
Table 10-8: Pull Model - Data to be signed on-card by the CASD
If the CASD holds an asymmetric signing key (SK.CASD.AUT), a signature of above data shall be
generated according to ISO/IEC 9796-2 [10], using Digital Signature Scheme 1, the SHA-1 hash
function and trailer field option 1.
If the CASD holds a symmetric signing key (KS.CASD.AUT), a signature of above data shall be
generated using padding according to Annex B.4 of [3] and the Single DES + Final Triple DES
algorithm described in GP CS v2.2.1 [3] – Appendix B.1.2.2.
- A response is returned to the Application Provider:

o If a DES signature was generated by the CASD, then the signed data (as described in Table
10-8) shall be returned, followed by the generated signature wrapped in LV format.
o If a RSA signature with message recovery was generated by the CASD, then the following
data shall be returned:
Length Description
1 Length of CASD Signature
Var. CASD Signature
1 Length of Remainder Data
Var. Remainder Data
Table 10-9: Pull Model - CASD Signature Data
According to signature with message recovery scheme [10], Remainder Data are those data
part of signed data (as described in Table 10-8) that would not be recovered from the
signature verification process.
The Application Provider shall recover signed data (including Encrypted RGK) by concatenating the data
recovered from the signature verification process and remainder data. Notice that if the APSD used DES
cryptography to obtain Encrypted RGK, the length of Remainder Data will be 0. The Application Provider
applies the same algorithm as the APSD to derive its Secure Channel Keys from the recovered RGK.
The Application Provider is now able to use its own keys to establish a Secure Channel session.

prohibited.
10.2 Scenario #2.A (Push Model with Application Provider Certificate)

This scenario is used to push Secure Channel Keys to the APSD. A RSA Public Key is retrieved by the
APSD (using the service of the CASD) from a Public Key Certificate sent by its provider. This key is used
to verify a signature of pushed Secure Channel Keys. Secure Channel Keys are sent encrypted to the
APSD and decrypted using a CASD service.
Figure 10-3 illustrates how scenario #2.A can be used to confidentially personalize an initial set of Secure
Channel Keys for a Security Domain. This diagram also shows how a Link Platform Operator (LPO) that is
not trusted by the Application Provider is involved in this scenario.

prohibited.
Figure 10-3: Scenario #2.A (Push Model with Application Provider Certificate)
Off-Card LPO UICC
Optional step: (Select CASD)

(Select Response)
GETGET
DATADATA
[PK.CASD.AUT]
['7F21']
PK.CASD.AUT, PK.CASD.CERT
certificates
- Application Provider verifies CERT.CASD.CT and
recovers PK.CASD.CT.
Optional step: (Select SD)

(Select Response)
(done)

Create a new Supplementary Security A new Supplementary Security Domain is created.
Domain for the Application Provider
INSTALL Response
INSTALL [for Personalization] APSD

INSTALL Response
STORE DATA [CERT.AP.AUT]

Application Provider sends CERT.AP.AUT - CASD verifies CERT.AP.AUT using
(previously signed using SK.CA.AUT) to APSD. PK.CA.AUT.
- APSD recovers and stores PK.AP.AUT.
STORE DATA Response
STORE DATA [Encrypted APSD key(s)]

- Application Provider encrypts its keys using PK.CASD.CT. - APSD verifies encrypted data using PK.AP.AUT.
- Application Provider signs encrypted data with SK.AP.AUT. - CASD decrypts data using SK.CASD.CT.
- Application Provider sends encrypted/signed data to APSD. - APSD recovers its Secure Channel keys from
decrypted data.
STORE DATA Response
10.2.1 Presenting AP Public Key Certificate

The DGIs described in section 10.1.1 are used to present the application provider public key certificate for
authentication (CERT.AP.AUT). The application provider public key for authentication (PK.AP.AUT) is
extracted from this certificate.
10.2.2 Pushing AP Secure Channel Keys

DGI '00A6', '8010' and '00AE' shall be sent to the APSD, in order to push AP Secure Channel Keys.

prohibited.
DGI '00A6' is used to provide identification data for pushed keys. The contents of DGI '00A6' are as
follows:

'90' 1 Scenario Identifier '02' Mandatory
'95' 1
Table 10-10: Content of DGI '00A6' (Push Model #2.A)
Tag 'A6' provides identification data for 3 Secure Channel Keys.

Tag '83' is used to specify a Key Version Number for pushed keys. When the APSD supports more than
one Secure Channel Protocol, using this tag is mandatory (otherwise, the command is rejected), and this
Key Version Number indicates the Secure Channel Protocol to which the pushed Key Set shall be bound
(either SCP80 or SCP02), as described in section 6. If a single Secure Channel Protocol is supported, and
this tag is not present, the pushed Key Set will be assigned an implicit Key Version Number of '01'. Key
Identifiers are implicitly known as '01', '02 and '03' respectively for ENC, MAC and DEK keys.
Tag '91' is optional and can be used to specify the initial value of the sequence counter associated with a
specified Key Version Number. The length of the value shall be consistent with the protocol associated
with this Key Set. If this tag is not present, this initial value is implicitly known as 0.
DGI '8010' is used to push key values encrypted according to PKCS#1 [12]:
DGI Length Description

Encrypted Secure Channel Keys
'8010' Var.
ENC || MAC || DEK
Table 10-11: Push Model - Encrypted Secure Channel Keys
The content of DGI '8010' shall be decrypted using the Authority.recoverKey() method (based on
the use of SK.CASD.CT).
DGI '00AE' provides integrity data for the Secure Channel Keys.The content of DGI '00AE' is as follows:
Tag Length Description

'9E' Var. Signature of (DGI '00A6' || DGI '8010')
Table 10-12: Push Model - Verification Template Content

prohibited.
The content of tag '9E' is a PKCS#1 v1.5 Block Type 01 signature (see PKCS#1 [12]) generated by the
Application Provider over the concatenation of DGI '00A6' and DGI '8010'. This signature shall be verified
by the APSD, using the Application Provider Public Key (PK.AP.AUT), before any attempt to store the
recovered Secure Channel Keys.
As soon as the Secure Channel Keys have been decrypted and the signature has been verified, they are
stored by the APSD according to supplied identification data. The APSD is now able to use its own Secure
Channel Keys.

prohibited.
10.3 Scenario #2.B (Push Model without Application Provider Certificate)

In this scenario, a LPO creates a new APSD for an Application Provider (AP) and populates it with an
initial, temporary set of SCP keys. The AP uses these temporary keys to populate its own set of SCP
keys. These keys are protected and decrypted on-card by the CASD.
For example, this scenario applies to the following situations:
- The MNO (in the role of LPO) creating a Security Domain for an Application Provider
- The MNO (in the role of LPO) creating a Security Domain for a TSM (Trusted Service Manager)
- A TSM (in the role of LPO) creating a Security Domain for an Application Provider
This scenario can be used to enable either a SCP80 or a SCP02 link for the Application Provider. When a
SCP80 link is to be established, the AP shall use its own OTA platform. In particular, the APSD shall be
installed with support for SCP80.
Figure 10-4 illustrates how scenario #2.B can be used to confidentially personalize an initial set of Secure
Channel Keys for a Security Domain. This diagram also shows how a Link Platform Operator (LPO) that is
not trusted by the Application Provider is involved in this scenario.

prohibited.
Figure 10-4: Scenario #2.B (Push Model without Application Provider Certificate)
Off-Card LPO UICC
Optional step: (Select SD)

(Select Response)
(done)

Create a new Supplementary Security A new Supplementary Security Domain is created.
Domain for the Application Provider
INSTALL Response
INSTALL [for Personalization] APSD

INSTALL Response
STORE DATA [Temporary APSD key(s)]

Send Application Provider's Temporary Secure Store Temporary Secure Channel keys.
Channel keys.
STORE DATA Response
Off-Card Application Provider Platform UICC
Optional step: (Select CASD)

(Select Response)
GETGET
DATADATA
[PK.CASD.AUT]
['7F21']
PK.CASD.AUT,
certificates
PK.CASD.CERT
Application Provider verifies CERT.CASD.CT and
recovers PK.CASD.CT.
Optional step: (Select APSD)

(Select Response)
Establish a secure channel with APSD A secure channel is established with the APSD.
(with request for MAC protection at least). (done)
STORE DATA [Encrypted APSD key(s)]

- CASD decrypts data using SK.CASD.CT.
- Application Provider encrypts its keys using PK.CASD.CT. - APSD recovers its Secure Channel keys from
- Application Provider sends encrypted data to APSD. decrypted data.
STORE DATA Response
10.3.1 Detailed Steps

The LPO creates APSD for the AP, with support for the SCP80 (resp. '02') protocol (and possibly other
protocols).

prohibited.
The LPO populates an initial, temporary set of SCP keys. To do so, the LPO may either:
- Open a secure link with the LPOSD, and use both INSTALL[for personalization] and STORE
DATA commands to send temporary SCP keys to the APSD or
- Using its own keys (as specified in section 4.4.1), open a secure link with the APSD and use the
PUT KEY command to send temporary SCP keys to the APSD.
The Secure Channel Protocol to which these keys are bound (either SCP80 or SCP02), shall be selected
according to KVN usage described in section 6, and may depend on whether the APSD supports one or
more Secure Channel Protocols. A secure link shall be established between the LPO and the AP to share
these keys.
The AP is now able to use these temporary keys to set up a SCP session with the APSD. In the case of a
SCP80 link, the AP is now required to use its own OTA platform (or at least, independent from the LPO).
The AP shall then
- Retrieve certificate CERT.CASD.CT from the CASD certificate store, check the certificate, using
PK.CA.AUT, and its content (in particular, card related data), and recover PK.CASD.CT
- Initiate a SCP session with the APSD, using temporary keys and at least the MAC security level.
- Load a new SCP Key Set encrypted using PK.CASD.CT
This is done in the same way as described in section 10.2.2, except for the following:
o The contents of DGI '00A6' shall be encoded as follows:

'90' 1 Scenario Identifier '04' (refer to Table 9-2) Mandatory
'95' 1
Table 10-13: Content of DGI '00A6' (Push Model #2.B)
o There is no need to send DGI '00AE', as the origin and the integrity of the keys that are
pushed to the APSD are ensured by the current Secure Channel session
o Any Key Set installed prior to the one currently being pushed by the AP shall be discarded
upon successful storage of the new Key Set
As soon as the Secure Channel Keys have been decrypted by the CASD, using SK.CASD.CT, they
are stored by the APSD according to the supplied identification data.
The AP shall now initiate a new SCP session using its new keys, to perform other personalization steps. In
particular, it may now populate Secure Channel Keys for other supported protocols, if any.

prohibited.
11 List of Tables and Figures

Table 1-1: Normative References ...................................................................................................................... 5
Table 2-1: Abbreviations and Notations ............................................................................................................ 7
Table 4-1: Supported Privileges ........................................................................................................................ 9
Table 4-2: Security Domain Install Parameters ............................................................................................... 12
Table 4-3: Encoding rules for tags '82', '83', and '87' defined in Table 4-2. .................................................... 13
Table 5-1: ISD Card Recognition Data ............................................................................................................ 18
Table 5-2: Security Domain Recognition Data ................................................................................................ 19
Table 8-1: Data objects readable with GET DATA command ......................................................................... 24
Table 8-2: Processing State returned in the PUT KEY (DES Key) Response Message ................................ 28
Table 8-3: Processing State returned in the PUT KEY (RSA Public Key) Response Message ..................... 28
Table 9-1: CASD Management Data ............................................................................................................... 30
Table 9-2: CASD Capability Information (Byte 1): Supported Scenarios ........................................................ 31
Table 9-3: CASD Capability Information (Byte 2): Supported Scenario Options ............................................ 31
Table 9-4: CASD Certificate Structure (Certificate with Message Recovery) ................................................. 33
Table 9-5: Data signed to generate a CASD Certificate with Message Recovery .......................................... 33
Table 10-1: DGI '00DE' for AP Public Key Certificate ..................................................................................... 37
Table 10-2: Structure of AP Public Key Certificate with Message Recovery .................................................. 38
Table 10-3: Data signed to generate the AP Public Key Certificate with Message Recovery ........................ 38
Table 10-4: Key data recovered from AP Public Key Certificate verification .................................................. 39
Table 10-5: Content of DGI '00B8' content for AP Symmetric Key Meta-Data ............................................... 39
Table 10-6: Content of DGI '00AE' for AP Symmetric Key Integrity Signature ............................................... 39
Table 10-7: Content of DGI '00A6' (Pull Model) .............................................................................................. 40
Table 10-8: Pull Model - Data to be signed on-card by the CASD .................................................................. 41
Table 10-9: Pull Model - CASD Signature Data .............................................................................................. 41
Table 10-10: Content of DGI '00A6' (Push Model #2.A) .................................................................................. 44
Table 10-11: Push Model - Encrypted Secure Channel Keys ......................................................................... 44
Table 10-12: Push Model - Verification Template Content.............................................................................. 44
Table 10-13: Content of DGI '00A6' (Push Model #2.B) .................................................................................. 48
Figure 4-1: Example 1 of Security Domain hierarchy ...................................................................................... 11

Figure 4-2: Example 2 of security domain hierarchy ....................................................................................... 11
Figure 4-3: Targeted Security Domain without a Key Set. .............................................................................. 15
Figure 4-4: Targeted Security Domain without SCP80 Capability .................................................................. 15
Figure 10-1: Scenario #1 (Pull Model), using PK scheme............................................................................... 36

prohibited.
Figure 10-2: Scenario #1 (Pull Model), using Non-PK scheme ....................................................................... 37

Figure 10-3: Scenario #2.A (Push Model with Application Provider Certificate) ............................................. 43
Figure 10-4: Scenario #2.B (Push Model without Application Provider Certificate) ........................................ 47
END OF DOCUMENT

prohibited.

Globalplatform Card Uicc Configuration: Member Release

Uploaded by

Copyright:

Available Formats

Globalplatform Card Uicc Configuration: Member Release

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Globalplatform Card Uicc Configuration: Member Release

Uploaded by

Copyright:

Available Formats

GlobalPlatform Card

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

This document is provided as a member benefit to GlobalPlatform

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

2 ABBREVIATIONS AND NOTATIONS ................................................................................................................. 6

7 DELEGATED MANAGEMENT ............................................................................................................................ 22

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

8.2.1 Command Message ............................................................................................................................... 24

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

Table 1-1: Normative References

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

2 Abbreviations and Notations

APDU Application Protocol Data Unit

API Application Programming Interface

APSD Application Provider Security Domain

CASD Controlling Authority Security Domain

ISD Issuer Security Domain

KS Secret Symmetric Key

LPO Link Platform Operator

LPOSD Security Domain of the Link Platform Operator

MAC Message Authentication Code

MNO Mobile Network Operator

NAA Network Access Application (e.g. SIM, USIM, etc.)

OTAPO OTA Platform Operator

OTASD OTAPO Security Domain

PK Public Key of an asymmetric key pair.

PKI Public Key Infrastructure

SK Private key of an asymmetric key pair

TSM Trusted Service Manager

SK.CA.AUT CA Private Key used to sign certificates (off-card)

PK.CA.AUT CA Public Key used to verify certificates (off-card)

PK.AP.AUT Application Provier Public Key (Push Model)

PK.AP.CT Application Provider Public Key (Pull Model)

CERT.AP.AUT Application Provider Certificate

CERT.AP.CT Application Provider Certificate

KS.AP.CT Application Provider Symmetric Key used for Encryption/Decryption

CERT.CASD.CT CASD Certificate holding a Public Key suitable for Encryption

SK.CASD.AUT CASD Private Key used for Signature

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

PK.CASD.AUT CASD Public Key used for Signature Verification

PK.CASD.CT CASD Public Key used for Encryption

KS.CASD.CT CASD Symmetric Key used for Encryption/Decryption

KS.CASD.AUT CASD Symmetric Key used for Signature/Verification

Table 2-1: Abbreviations and Notations

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

3.1 Security Domains

3.2 Required Application Programming Interfaces

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

4 UICC Security Policies

ISD CASD APSD NAA Application

Table 4-1: Supported Privileges

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

4.2 Issuer Security Domain

4.3 Supplementary Security Domains

4.3.1 Security Domain Hierarchies

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.

Figure 4-1: Example 1 of Security Domain hierarchy

Figure 4-2: Example 2 of security domain hierarchy

Copyright  2008-2011 GlobalPlatform Inc. All Rights Reserved.