KMS Functional Reqs v1 0

GlobalPlatform Key Management System
Functional Requirements
1.0
November 2003
GlobalPlatform Key Management System Functional Requirements
Page 2
Table of Contents
1. DOCUMENT OVERVIEW...................................................................................................... 7
1.1
1.2
1.3
1.4
1.5
1.6
1.7
INTRODUCTION ................................................................................................................ 7
SCOPE .............................................................................................................................. 7
PURPOSE OF THIS DOCUMENT .......................................................................................... 8
INTENDED AUDIENCE ....................................................................................................... 8
VERSION INFORMATION ................................................................................................... 8
REFERENCES AND APPLICABLE DOCUMENTS .................................................................. 9
TERMINOLOGY............................................................................................................... 10
2. OVERVIEW OF KEY MANAGEMENT SYSTEMS ......................................................... 15

2.1
WHAT IS A KMS ............................................................................................................ 17
3. GENERAL KEY MANAGEMENT SYSTEM REQUIREMENTS ................................... 18

3.1
OVERALL REQUIREMENTS FOR A KMS ......................................................................... 18
3.2
REQUIREMENTS FOR HSM............................................................................................. 18
3.3
REQUIREMENT FOR ACCESS AND AUDIT ....................................................................... 19
3.4
REQUIREMENTS FOR SUPPORTING CRYPTOGRAPHIC ALGORITHMS AND THEIR MODES19
3.5
REQUIREMENTS FOR KEY PROFILE ................................................................................ 20
3.6
REQUIREMENTS FOR KEY GENERATION ........................................................................ 20
3.6.1
[ R-20 ] TDEA:...................................................................................................... 20
3.6.2
[ R-21 ] RSA: ......................................................................................................... 21
3.7
REQUIREMENTS FOR KEY REVOCATION ........................................................................ 21
3.8
REQUIREMENTS FOR STORING KEYS ............................................................................. 21
3.9
REQUIREMENTS FOR KEY EXCHANGING ....................................................................... 22
3.9.1
General Principle for Exchanging Keys................................................................ 22
3.9.2
Exchanging Key Profiles ....................................................................................... 22
3.9.3
Exchanging TDEA keys ......................................................................................... 23
3.9.4
Exchanging RSA keys ............................................................................................ 24
3.10 REQUIREMENTS FOR IMPORTING AND EXPORTING KEYS.............................................. 24
3.11 REQUIREMENTS FOR KEY SEPARATION......................................................................... 24
3.12 REQUIREMENTS FOR THE DATE CHECKING ................................................................... 24
3.13 REQUIREMENTS FOR EXPIRATION AND DELETION ........................................................ 25
APPENDIX A GLOBALPLATFORM CARD ...................................................................... 26
A.1. ABOUT GLOBALPLATFORM KEY MANAGEMENT SYSTEMS............................ 27
A.1.1
ABOUT THIS CHAPTER ............................................................................................... 27
A.1.2
GLOBALPLATFORM KEY MANAGEMENT SYSTEM OVERVIEW .................................. 27
A.1.3
GP CARD KMS VERSUS APPLICATION KMS............................................................. 28
A.1.3.1 Key Management System Keys .............................................................................. 28
A.1.3.2 Naming Convention for Keys................................................................................. 29
A.1.3.3 Key Management System Roles ............................................................................. 30
A.1.3.4 Key Management System scenarios....................................................................... 32
A.1.3.5 KMS with DAP Verification .................................................................................. 34
A.1.4
GP CARD KMS KEYS ................................................................................................ 36
A.1.4.1 GP Card KMS for Issuer Security Domain ........................................................... 37
A.1.4.2 GP Card KMS for Supplementary Security Domain ............................................. 37
Copyright 2003 GlobalPlatform Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use
of this information is governed by the GlobalPlatform license agreement and any use inconsistent with that
agreement is strictly prohibited.
A.1.5
Page 3
APPLICATION KMS KEYS .......................................................................................... 38
A.2. FUNCTIONAL REQUIREMENTS TO SUPPORT A GLOBALPLATFORM CARD40

A.2.1
FUNCTIONAL REQUIREMENTS ................................................................................... 40
A.2.1.1 Overall requirements for a KMS ........................................................................... 40
A.2.1.2 Requirements for HSM .......................................................................................... 40
A.2.1.3 Requirement for Access and Audit......................................................................... 40
A.2.1.4 Requirements for Supporting Cryptographic Algorithms...................................... 40
A.2.1.5 Requirements for Key Profile ................................................................................ 41
A.2.1.6 Requirements for Key Generation ......................................................................... 41
A.2.1.7 Requirements for Storing Keys .............................................................................. 41
A.2.1.8 Requirements for Key Exchanging ........................................................................ 42
A.2.1.9 Requirements for Importing and Exporting Keys.................................................. 46
A.2.1.10
Requirements for Key Separation...................................................................... 46
A.2.1.11
Requirements for Date Checking....................................................................... 46
A.2.1.12
Requirements for Expiration and Deletion........................................................ 46
A.2.1.13
Requirements for Key Derivation ...................................................................... 46
A.2.1.14
Transport of Application Secret Data ............................................................... 46
A.2.1.15
Requirements for other Crypto Functions ......................................................... 46
APPENDIX B EMV APPLICATION .................................................................................... 48
B.1. EMV APPLICATION DETAILS....................................................................................... 49
B.1.1
ABOUT THIS CHAPTER ............................................................................................... 49
B.1.2
ACTORS ROLES AND RESPONSIBILITIES .................................................................... 49
B.1.3
EMV APPLICATION KEYS .......................................................................................... 50
B.1.4
EMV APPLICATION RELATED INFORMATION ........................................................... 51
B.1.5
PROCESSES ................................................................................................................. 52
B.1.5.1 RSA Data ............................................................................................................... 52
B.1.5.2 TDEA Data ............................................................................................................ 52
B.2. FUNCTIONAL REQUIREMENTS TO SUPPORT AN EMV APPLICATION .......... 54
B.2.1
EMV CASE STUDY .................................................................................................... 54
B.2.2
FUNCTIONAL REQUIREMENTS ................................................................................... 54
B.2.2.1 Overall Requirements for a KMS .......................................................................... 55
B.2.2.2 Requirements for HSM .......................................................................................... 55
B.2.2.3 Requirement for Access and Audit......................................................................... 55
B.2.2.4 Requirements for Supporting Cryptographic Algorithms...................................... 55
B.2.2.5 Requirements for Key Profile ................................................................................ 56
B.2.2.6 Requirements for Key Generation ......................................................................... 56
B.2.2.7 Requirements for Storing Keys .............................................................................. 57
B.2.2.8 Requirements for Key Exchanging ........................................................................ 57
B.2.2.9 Requirements for Importing and Exporting Keys.................................................. 62
B.2.2.10
Requirements for Key Separation...................................................................... 62
B.2.2.11
Requirements for Date Checking....................................................................... 62
B.2.2.12
Requirements for Expiration and Deletion........................................................ 62
B.2.2.13
Requirement for Issuer Certificate Request....................................................... 62
B.2.2.14
Requirement for Issuer Certificate Response Import ........................................ 62
B.2.2.15
Transport of Application Secret Data ............................................................... 62
B.2.2.16
Requirements for other Crypto Functions ......................................................... 62
Page 4
APPENDIX C - POSSIBLE GLOBAL PLATFORM KMS CONFIGURATIONS.............. 64

Page 5
Table of Tables
Table 1: Definitions ....................................................................................................... 13
Table 2: Naming convention for Keys........................................................................... 30

Page 6
Table of Figures
Figure 2-1 : Relationship between Key Values, Attributes and Key Profiles ............ 15
Figure 2-3 : Example of Key Values shared by two parties ........................................ 16
Figure 1-1: Key Management System Roles ................................................................ 31
Figure 1-3: KMS with one Security Domain ................................................................ 33
Figure 1-5: KMS with more than one Security Domain .............................................. 34
Figure 1-7: KMS with DAP Verification....................................................................... 35
Figure 1-9: KMS with Delegated Management ........................................................... 36

Page 7
1. Document overview
1.1
Introduction
The process of providing applications on a GlobalPlatform Multi-application Chip

Card requires intensive use of cryptography and cryptographic keys based on the
integrated security architecture of GlobalPlatform.
The management of these cryptographic keys is becoming increasingly important as
the environment in which the Chip Card comes to life becomes more complex. Many
entities may play a role in the production of a multi application chip card. Each
entity will have security responsibilities within its role and must manage its part of
the security architecture seamlessly within the overall security architecture. To be
able to perform these security responsibilities, a Key Management System (KMS)
that meets certain requirements shall be used.
This document will outline the functional requirements for a Key Management
System as part of the overall GlobalPlatform Security Architecture.
1.2
Scope
The GlobalPlatform Key Management Functional Requirements define the

minimum functional requirements required for the support of keys within the
Security Architecture of GlobalPlatform. The scope extends the requirements for key
management to include the requirements for cryptographic services.
Application specific keys may also be supported by a GlobalPlatform Key
Management System.
The document identifies the general requirements for robust key management. The
document covers how the keys are generated, stored, how they are used and how
they are exchanged between entities. At a more specific level the document covers
the cryptographic keys for the Issuer Security Domain and any supplementary
Security Domains, plus the services that are needed for card enablement and
application loading.
Furthermore, the document covers the key management services needed by the
Application Provider when personalizing applications, plus the types of keys
potentially needed or supported in this area.
The Key Management Functional Requirements relate to the GlobalPlatform
Card Specification 2.1.

1.3
Page 8
Purpose of this document
The intention of GlobalPlatform KMS Functional Requirements is to serve as input

to the GlobalPlatform Profile Specification, GlobalPlatform Messaging Specification
and GlobalPlatform Scripting Specification providing a means to unambiguously
identify the Key Values, the cryptographic services and the messages containing
cryptographic methods, used within GlobalPlatform.
Furthermore it provides a GlobalPlatform view of the roles and responsibilities of
the entities handling these keys.
1.4
Intended audience
This document is intended to be read by card issuers, application providers, system

developers and system integrators playing a role in the production of Key
Management systems for GlobalPlatform Chip Cards.
It is assumed that the intended readership is already familiar with Card
Management Systems, smart cards and the GlobalPlatform specifications.
1.5
Version information
Version
Date
1.0
November 2003
Comments

1.6
Page 9
References and applicable documents
Europay, MasterCard, and Visa (EMV) Integrated Circuit Card

Specifications for Payment systems 3.1.1, May 1998Payment industry
specifications for chip-card and terminal interaction
EMV 2000 Integrated Circuit Card Specifications for Payment Systems, Book
2 Security and Key Management
GlobalPlatform Card Specification 2.1, June 2001 Chip-card specifications for
GlobalPlatform products.
GlobalPlatform Profiles Specification version 1.0, March 2002 Description of
the contents, format and usage of GlobalPlatform Card Profiles.
GlobalPlatform Scripting Specification, version 1.0, March 2002 Overview of
GlobalPlatform Personalization architecture and the role of scripts within in.
GlobalPlatform Card Customization Guide, version 1.0, March 2002 Defines
how multi-application smart cards can be managed using GlobalPlatform Profiles
and Scripts.
GlobalPlatform Messaging Specification, version 0.1.2-Draft, Oct 2002
FIPS PUB 46-3: Data Encryption Standard, October 25th 1999
FIPS PUB 81: DES modes of Operation, December 2nd 1980

1.7
Page 10
Terminology
Term
Definitions
Applet
Representation of a chip application software and/or data. In this

document, it refers to an application on a Java card.
Application Identification Number

(AIN)
The Application Providers unique Identifier as defined in ISO 7812.

This is similar in concept to the Issuer Identification Number.
Application Key Management

System (KMS)
The Application Key Management System provides application

related key management on behalf of the Application Provider.
Application Loader
The Application Loader loads Card Issuer specific cards with

applications and / or personalization / customization data according
to the instructions of the Application Provider, while complying with
the security policies of the Card Issuer.
Application Provider
The Application Provider procures the necessary components to

load a complete application on to a card (i.e., application code,
application data, application keys and/or certificates, and data
belonging to a specific cardholder). The Application Provider has a
direct business relationship with the cardholder and provides a cardbased service to that cardholder.
Asymmetric Cryptography
A cryptographic technique commonly referred to as Public Key.

This technique uses two related transformations, a public
transformation (defined by the public key component) and the
private transformation (defined by the private key component). The
two key components have a property that, given the public key, it is
computationally not feasible to discover the private key.
Card Enabler / Initializer
The entity that prepares the platform for subsequent application

loading.
Card Image Number (CIN)
Uniquely identifies a smart card within a Card Issuer environment

(Card Manager). The Card Image Number (CIN) is a "logical"
number controlled by the Card Issuer to uniquely identify a card (for
that issuer only, i.e. unique for an IIN) regardless of the target chip.
Refer also to the Security Domain Image Number (SDIN).
Card Issuer
The Card Issuer issues cards to cardholders.
Card Manager
The Issuers on-card control mechanism for a GlobalPlatform chipcard.
(Chip) Card Manufacturer
The entity that manufactures (fabricates) cards on behalf of and to

the requirements of the Card Issuer. The services performed
depend on the contractual relationship with the Issuer and may
include part or all of the card production process.
Chip card
A card with an embedded processor chip on it, also referred to as

ICC and smart card.

Page 11
Term
Definitions
DAP Block
First part of the Load File used for ensuring Load File Data Block
verification.
Data Preparation
The process of gathering and preparing the necessary application

data and keys for input into the personalization device.
Decryption
The reversal of the corresponding encryption, reversible

transformation of a cryptogram by cryptographic algorithm to retrieve
the original plain text data.
Delegated Management
Allows an Application Provider to load and install an application on a

card, with the Card Issuer still retaining control over the content of
the card.
Digital Signature
An asymmetric transformation of data intended to prove to the data

recipient the origin and integrity of the data.
Encryption
The reversible transformation of data by cryptographic algorithm to

produce a cryptogram.
GP Card KMS
An instance of a GlobalPlatform Key Management System that

support the required functionality for use with a GP Card.
The HSM is a tamper-resistant device that provides the
cryptographic facilities necessary for functions such as
securing application data generation, personalization and application
loading.
HSM
Within this document the term HSM is used to indicate the

requirement for a Hardware cryptographic device suitable for the
necessary operation.
ICC

smart card and chip card.
IC Manufacturer
The silicon manufacturer of the wafers containing chips with a

specified ROM configuration.
Initialization
The process of populating persistent memory (EEPROM) with data

that is common to a large number of cards while also including a
minimal amount of card unique items (e.g. ICC serial number and
Personalization keys).
(Application) Install
The process of allocating persistent memory (EEPROM) for

application data and populating persistent memory with specific setup data. For a Java Card, an instance of the applet is created and
applet objects are instantiated.
Issuer
Entity that is ultimately responsible for a card and all of its contents.
Issuer Identification Number (IIN)
The Issuer unique Identifier as defined in ISO 7812. For banks

issuing their own cards, a BIN may be used for this purpose. Thirdparty processors or other entities issuing cards may apply for an IIN
with the International Organization for Standardization (ISO).

Page 12
Term
Definitions
Java
An interpretative programming language used for developing

applications targeted to Java Card chip-cards.
Key
A set of attributes that defines a component of cryptographic

operations. Attributes include the items like value, usage, key check
value, owner, name, expiration date, etc..
A Key Value is an optional attribute of a Key Profile that contains the
bits used to control a cryptographic operation.
Key Value
The term Key Value is used in preference to key to ensure

distinction between a Key Value and a Key Profile.
A Key Value would normally be paired with other Key Profile
attributes such as a Key Check Value.
A representation of attributes that are used to describe parameters
of a particular key or type
Key Profile
A Key Profile may or may not contain all its attributes, such as Key
Value, a Key Profile not containing a Key Value could be used to
describe and the usage of a key type rather than a specific instance
of cryptographic key value.
An integrity value associated with a cryptographic key.
Key Check Value (KCV)
For DES/TDEA key value and DES/TDEA key component KCV shall
be the result, or partial result, of the encryption of eight bytes of
binary zeroes.
Key Encrypting Key (KEK)
Key used to encrypt another key.
Live
A Key Profile may be marked as Live or Test, a Key Profile marked

as Live should be treated as a data that has been used during the
creation of real applications/cards.
(Application) Load
The process of populating persistent memory (EEPROM) with

application software and linking it to the on-card infrastructure.
Message Authentication Code

(MAC)
A cryptographic transformation of data that protects the sender and

the recipient of the data against forgery or manipulation by third
parties.
Object Identifier (OID)
A number that uniquely identifies an object class or attribute. An

object identifier is represented as a dotted decimal string, such as
1.2.3.4. Object identifiers are organized into a global hierarchy.
National registration authorities issue root object identifiers to
individuals or organizations, who manage the hierarchy below their
root object identifier.
The encoding of an OID is defined in ISO/IEC 8825-1.
Personalization
The process of populating persistent memory (EEPROM) with

cardholder unique data.

Page 13
Term
Definitions
Platform Key Management System
The Platform Key Management System provides platform related

key management on behalf of Card Issuers.
Post-Issuance Load/Install
The process of downloading applications and data to the card after

the card has been issued to the cardholder. This process requires
establishing a secure channel between the Application Load Server
and the chip-card.
Private Key
The private (secret) component of an asymmetric key pair. Its owner

always keeps the private key in secret. The private key may be used
to decrypt messages that are encrypted using the corresponding
public key. It may also be used to digitally sign messages for
authentication purposes.
Public Key
The public component of an asymmetric key pair. The public key is

usually publicly exposed and available to users. A certificate to
prove its origin often accompanies it. The public key may be used to
encrypt messages intended for the owner of its corresponding
private key. It may also be used to verify a message digital signature
to authenticate the message sender.
Secure Channel
A communication mechanism between an off-card entity and a card

that provides a level of assurance, to one or both entities.
Security Domain
A specific system application on the card that represents a specific

Application Provider. The Security Domain holds encryption and
signature keys that are used to verify the integrity and authenticity of
its Application Providers applications.
Smart card

ICC and chip card.
Smart Card Management System

(SCMS)
The infrastructure required to support a multi-application program. It

includes, but is not limited to, card program set up, card and
application life cycle management, issuance and re-issuance
processes and the management of the card life cycle and business
rules between applications.
Symmetric Cryptography
A cryptographic technique that uses the same secret key for both
the originators and the recipients transformation. Without
knowledge of the secret key, it is computationally not feasible to
compute either the originators or the recipients transformation.
Test
A Key Profile may be marked as Live or Test, a Key Profile marked

as Test should be treated as a data that has been used during the
creation of test applications/cards.
Transport Key (TK)
Key used for transporting secret information between two entities.
Trust Model
Term used to indicate whether Card Issuer is trusted to perform the

load of 3rd party applications.
Table 1: Definitions
The requirements are stated using the terms shall, should and may. Where the
term shall is used the requirement is not optional. Where the term should is used
Page 14
the requirement is recommended. Where the term may is used the requirement is
optional.

Page 15
2. Overview of Key Management Systems

The minimum functionality of a KMS is to logically maintain a key's set of
attributes, such as operations that can be performed by the key, validity period of
the key and associations of the key with other entities.
Keys within a system are in general used for different purposes. In order to ensure
a key is only used for the purpose for which it was intended, it has bound with it a
set of attributes defining how it may be used.
The term key in this document conveys a more comprehensive meaning than the
popular use of the term which simply refers to its cryptographic binary value. To
avoid confusion here the term Key Value is used to describe the cryptographic
binary value, and the term Key Profile is used to describe an object which contains
the Key Value and a set of attributes. Depending on the keys purpose, the
attributes contained within a Key Profile will vary.
Key Profile1
Attributes
Key Profile2
Attributes
Attributes
Key Profile4
Key Profile3
Attributes
Attributes
Key Profile7a
Attributes
KeyA
Key Profile6
Key Profile5
Attributes
Attributes
Attributes
KeyB
Attributes
Key Profile7b
Attributes
Key Profile7c
Attributes
Figure 2-1 : Relationship between Key Values, Attributes and Key Profiles
Figure 2-1 illustrates how various Key Profiles can be created from 3 sets of
attributes (, and ) and 2 keys (A and B).
Key Profile1 and Key Profile2 do not contain a Key Value, this would typically be the
first state of a Key Profile, where for example only usage has been set. From these
Key Profiles, Key Values can be added, essentially using the original as a template,
and in doing so creating new Key Profiles. If the same Key Value is to be used by
Page 16
two parties for different purposes then two Key Profiles would be required as they
must contain different attributes.
In the example the creation of the following new Key Profiles are shown:
Key Profile1 created using Attributes, and Key Profile2 using Attributes
Key Profile3 based on Key Profile1 when KeyA loaded, and Key Profile4 using
Attributes
Key Profile5 based on Key Profile1 when KeyB loaded, and Key Profile6 using
Attributes
Key Profiles7a7c created using Attributes and KeyB split into 3 components
Typically when transferring key components, such as Key Profiles7a..7c, they would
also be accompanied with another Key Profile, such as Key Profile1 or Key Profile2,
which would provide the final usage attributes of the combined key. Attributes will
not contain the final usage of the combined key; it instead contains the attributes
that explain this is a key component.
To illustrates how a Key Values and Key Profiles could be used, if we take an
example, from
Figure 2-2, where two parties (A & B) need to share a key. PartyA is the owner of the
Key and use the key for Encryption, PartyB have received the key from PartyA and
use the key for Decryption. This will then product two Key Profiles, one in each of
the Parties key management system, both Profiles will contain the same Key Value
but will contain different attributes.
Figure 2-2 : Example of Key Values shared by two parties

2.1
Page 17
What is a KMS
A Key Management System is a system to securely generate, store, distribute and

delete cryptographic Key Values and attributes. A KMS is part of a larger system
that requires cryptographic Key Values. A Key Management System is typically a
software based system making use of a hardware based cryptographic processor for
secure operations, and consists of 4 elements:
A database for storage of the Key Values and attributes
Services to the systems needing Key Values typically in the form of an API
An HSM (if required by the market security requirements) to ensure the

secrecy and integrity of the Key Values and attributes, and also provide a
resource for the mathematically intensive nature of Key Value generation
Procedures or more accurate man/machine interface supporting procedures
Except for the requirements for security and procedural support, a Key Management
System is much like any other management system e.g. a Card Management
System. At the heart of the system lies a Database storing the Data and an API
giving access to that Data and the services associated with it.

Page 18
3. General Key Management System

Requirements
In order to protect an asset and manage Key Values in a robust way there are
certain principles that must be applied to the design of a key management system.
There are certain requirements for key management that are general enough to be
listed as requirements for all KMSs. The requirements stated in this document, if
followed, lay down a basis for interoperability and mutual trust between business
entities that need to share and/or use cryptographic information.
3.1
Overall requirements for a KMS
[ R-1 ] The KMS shall be able to maintain Key Profiles during the entire lifetime for
a specific Key Profile i.e. from definition, generation and storing, exchanging and
using to expiration and deletion.
[ R-2 ] The KMS shall provide services to relevant systems having the need for use
of a specific Key Profile. These services will provide a mechanism for users of the
KMS to generate exchange and retrieve keys.
[ R-3 ] The KMS shall have any secret or critical function (such as generating or
unwrapping/wrapping Key Values) performed within a Hardware Security Module
or equivalent secure component.
[ R-4 ] The KMS shall be able to recover all Key Profiles within the KMS in case of
failure in the KMS itself or in the HSM utilized.
3.2
Requirements for HSM
The KMS relies on a HSM to supply certain capabilities the following section.
[ R-5 ] The actual implementation of such a support is not mandated, but the
minimum requirements for a HSM shall encompass support for:
[ R-5a ] Key Value generation
[ R-5b ] Key Value exchange
[ R-5c ] Key Profile separation (logically split key attributes)
[ R-5d ] Key Value export and import
[ R-5e ] Secure storage of Key Value

Page 19
[ R-5f ] RNG testing shall be performed periodically to verify that is

continues to operate correctly according to FIPS 140-2, any errors shall be
reported to the KMS.
[ R-6a ] Services offered by the HSM, in addition to the requirements stated in this
document shall not enable the HSM requirements of the GlobalPlatform KMS to be
circumvented, for example the KMS requires Key Profile separation, the HSM must
not offer additional or legacy services to enable the key separation to be overridden.
[ R-6b ] The HSM shall be certified on a level corresponding to at least FIPS 140-2
level 3.
3.3
Requirement for Access and Audit
[ R-7 ] The KMS shall be able to limit access to each Key Value and the functions
possible for a Key Value to those with a defined need. [ R-8 ] No person must have
access to a clear text value of any Key Value within the KMS.
[ R-9 ] The KMS shall be able to manage and track any changes to the Key Profiles.
[ R-10 ] The changes shall be tracked in a way that the information concerning the
changes can be trusted. [ R-11a ] The changes may be tracked in a way that they
can be compared with information of the intended use of the Key Values and
functions within the Key Management System. [ R-11b ] Periodically an audit shall
be done to review the changes tracked in order to verify that all of them are correct.
3.4
Requirements for Supporting Cryptographic Algorithms

and their Modes
[ R-12 ] The KMS shall be capable of supporting Key Values for the following
algorithms:
[ R12a ] TDEA Triple Digital Encryption Algorithm

ECB & CBC as described in FIPS PUB 81.
[ R-12b ] RSA Rivest Shamir Adleman
While it is envisaged that various symmetric and asymmetric cryptographic

algorithms could be supported, this document only outlines the requirements for the
last two mentioned examples.

3.5
Page 20
Requirements for Key Profile
[ R-13 ] The KMS shall support a standard structure representing the attributes of
a Key Value. The structure will be known as a Key Profile and act as a prototype for
a Key Value.
The attributes making up a Key Profile can be grouped into three sections. The first
contains those attributes used to identify a Key Profile (Owner, Source/Sender,
Destination/Receiver, Name, etc.). The second is made up of those attributes that
define the context, environment, usage, type, etc. of a Key Profile. The final section
contains those attributes that make up a version of a key (value,
expiration/activation dates, version identification, integrity checks, etc.).
[ R-14 ] A Profile is a unique set of attributes and shall be uniquely identified. Many
Key Profiles can be based on a single source Profile if they share the same context,
environment, usage, type, etc. (i.e. multiple versions of a Key Value would share the
same Profile).
[ R-15 ] The presence of individual attributes or parts of a Key Profile shall be
classified as mandatory or optional. [ R-16 ] A Key Value shall not be used for
cryptographic purposes unless all mandatory attributes are present in a Key Profile.
[ R-17 ] see [ R-29 ] for requirements on Key Exchange.
A Key Value may be associated with more than one Key Profile although this
requirement is not expected to be needed within the same KMS system. An example
of this is the Transport Key used by the Card Issuer may have the usage of Wrap
and Encrypt, and for the Card Enabler the same Key Value is to be loaded into a
different Key Profile which may have a usage of Unwrap and Decrypt. These two
different actors therefore use different KMSs with the correct Key Profile loaded into
each. If the Card Issuer and Card Enabler were being carried out by the same actor
they would probably not use a Transport Key.
3.6
Requirements for Key Generation
[ R-18 ] The KMS shall be able to generate Key Values compliant to the
cryptographic algorithms supported by the KMS.
[ R-19 ] The generated Key Values shall be cryptographically sound according to the
nature of the algorithm. This requirement encompasses the algorithms defined in
this document:
3.6.1
[ R-20 ] TDEA:
[ R-20a ] Shall be 128 bit key, comprising of 112 bit Key Value plus odd
parity

Page 21
[ R-20b ] Weak or semi-weak Key Values shall not be allowed
[ R-20c ] Shall be generated using either a True Random Number Generator

or a Pseudo Random Number Generator. The Random Number Generator
that is used shall be designed to pass the statistical tests specified in FIPS
140-2
3.6.2
[ R-21 ] RSA:
The General KMS requirement here is to support generation of RSA-keys, however

actual specific requirements to the RSA key generation can and probably will be
obtained from the requirements for the GP Card and/or Application KMSs.
[ R-21a ] The KMS should be able to generate and manage RSA keys with a
Public Key modulus lengths greater than or equal to 512 bits
[ R-21b ] The RSA key shall be generated to meet the requirements specified
in the Key Profile defined for each application
3.7
Requirements for Key Revocation
[ R-22 ] Where revocation services are employed the following requirements shall be
maintained:
[ R-22a ] Maintaining a list of revoked key values and all associated profiles
[ R-22b ] Report list of revoked key values & profiles
[ R-22c ] Distribution of revocation lists or other mechanisms to verify

current or recent validity of keys
3.8
Requirements for Storing Keys
[ R-23 ] All Key Values, based on their longevity, shall be stored in a way that they
are protected from exposure and unauthorized modification; the associated key
profiles shall also be protected from unauthorized modification. A procedural policy
is required to define what is modifiable with what level of authorization.
[ R-24 ] Along with the actual Key Value other information shall be stored. This
information represents necessary properties of the Key Value. Other than the
properties than can be found in the corresponding Key Profile, a Key Value has
properties that are directly related to the actual value. The information stored shall
include at least:
[ R-24a ] Unique ID of the specific Key Value.

Page 22
[ R-24b ] The intended usage of the Key Value.
[ R-24c ] The ID of the Key Profile.
[ R-24d ] Information on how the Key Value is encrypted, i.e. an

identification of the Key Profile encrypting the Key Value.
[ R-24e ] Expiration date.
[ R-24f ] Indicator for whether a Key Value is for test or live-environment.
[ R-24g ] Key Check Value, which makes it possible to exchange information

about a given Key Value without exposure of the actual Key Value.
3.9
Requirements for Key Exchanging
3.9.1
General Principle for Exchanging Keys
[ R-25 ] The KMS shall be able to exchange both the Profile of the key and the Key
Value itself.
[ R-26 ] It may be possible to exchange a number of Transport Keys (TK) between
physically separated Key Management Systems, which have the need to exchange
Key Profiles.
[ R-27 ] At least the first Key Profile exchanged between two such systems shall be
done in a manner that shall provide mutual authentication1 between the two
entities. [ R-28 ] The key exchange may be done in manner that provides secrecy of
the Key Value.
Transport Keys can be exchanged using various methods and/or media such as
diskette, paper, Smart Cards, VPN or LAN-connections.
3.9.2
Exchanging Key Profiles
[ R-29 ] The KMS shall support the following to enable Exchanging Key Profiles:
[ R-29a ] The KMS shall be able to store, organize and retrieve the
information relating to the Profile used for a specific Key Value.
Mutual Authentication in this context can be achieved procedurally or cryptographically.

The intention of this requirement is to ensure the key value & attributes are shared with the
correct party and not an impostor.
1

Page 23
[ R-29b ] The exchange of Key Values between KMSs shall utilize Key
Profiles.
[ R-29c ] The KMS shall support a method to ensure the integrity of a Key
Profile. This integrity must be maintained during profile storage or exchange,
even if the exchange is performed in multiple transmissions.
3.9.3
Exchanging TDEA keys
[ R-30 ] The KMS shall be able to support a secure exchange of TDEA Keys with
another KMS using the GlobalPlatform Key Profile as specified in the
GlobalPlatform Profiles specification.
[ R-31 ] A Key shall be exchanged as components or in encrypted format as
mutually agreed upon between sender and receiver. If exchanged as components, the
Key Value shall be exchanged as a number of components, bigger than one, with
each component written to a separate medium (e.g. one diskette per component), and
each should be sent independently.
The number components (n) shall ensure that the knowledge of one, or m, (where
m<n) of the components impeaches the recover of other components or the clear key
value.
[ R-32 ] In case a Key Profile is imported into the KMS, the KMS shall be able to
check for odd parity of the Key Value. When the Key Value does not have odd parity
the KMS shall not accept the Key Profile.
[ R-33 ] In both cases, certain information other than the actual Key Value shall be
transferred along with the Key Value. This information shall encompass at least:
[ R-33a ] ID of the specific Key Profile uniquely identifying the Key Profile to
both sender and receiver;
[ R-33b ] Indicator for whether the Key Value is a test or a live key;
[ R-33c ] Key Check value making it possible to verify that Key Value after
installation has the same value at both sender and receiver;
[ R-33c1 ] If exchanged in the clear each component shall have a Key
Check Value attached;
[ R-33c2 ] For both clear and encrypted Key Values the final
(combined) Key Value shall have a Key Check Value attached;
[ R-33d ] For Encrypted Key Values only, a unique identification of the

Transport Key (TK) used to encrypt the exchanged Key Value. The ID shall
be unique to both sender and receiver, and based on Name/Owner/Version or
OID.

3.9.4
Page 24
Exchanging RSA keys
[ R-34 ] RSA Key Profiles shall be exchanged in the following manner:
[ R-34a ] Public Key Values shall be exchanged using a method providing

authenticity and integrity.
[ R-34b ] Private Key Values shall be exchanged using a method providing

authenticity, integrity and secrecy.
[ R-35 ] For both Public and Private Key Profiles certain information other than the
key itself will be transferred along the Key Value. This shall at least encompass:
[ R-35a ] ID of the specific Key Profile uniquely identifying the key to both
sender and receiver;
[ R-35b ] Indicator for whether the Key Value is a test or a live key;
[ R-35c ] Integrity check such as a Key Check Value making it possible to

verify that Key Value after installation has the same value at both sender
and receiver;
[ R-35d ] For Private Key Values, a unique identification of the Transport

Key (TK) used to encrypt the Private Key Value during transport.
3.10
Requirements for Importing and Exporting Keys
[ R-36 ] The KMS shall support and use mechanisms to prevent Key Value
import/export unless explicitly authorized.
3.11
Requirements for Key Separation
[ R-37 ] The KMS shall support and use methods to make it impossible to use a Key
Value for another usage or purpose other than the intended usage as indicated by
the associated Key Profile.
3.12
Requirements for the Date Checking
[ R-38 ] The KMS shall prohibit the usage of Key Values outside the Key Profiles
valid date range.

3.13
Page 25
Requirements for Expiration and Deletion
[ R-39 ] The KMS shall support and use processes to have a Key Profile expired,
archived and deleted.

Page 26
Appendix A GlobalPlatform Card

This appendix covers the Case study of a GlobalPlatform Card and is a hypothetical
example of how the tools described in the main part of this document could be
applied.

Page 27
A.1. About GlobalPlatform Key Management

Systems
A.1.1 About this chapter
Whenever a Key Management System is evaluated, those business requirements
necessary for a specific implementation are naturally of highest importance.
Besides the general requirements for a Key Management System as defined in
chapter 3, there are specific GlobalPlatform requirements for managing the Key
Values for GlobalPlatform cards and applications. These requirements are derived
from the GlobalPlatform Card Specification 2.1.
In order to understand these requirements it is necessary to provide an overview of
the GlobalPlatform key types and how they are distributed.
A.1.2 GlobalPlatform Key Management System overview

A GlobalPlatform Key Management System (KMS) shall support the GlobalPlatform
Security Architecture requirements.
Security Domains form the basis for the GlobalPlatform security architecture. A
Security Domain can be either the Issuer Security Domain managed by the Card
Issuer or it can be a Supplementary Security Domain managed by an Application
Provider, a regulatory authority or the Issuer itself.
There are two types of Key Management Systems.
The GP Card KMS used by the Card Issuer for support of Key Profiles and
methods for the Issuer Security Domain and any Supplementary Security
Domains;
The Application KMS used by the Application Provider for support of

application specific Key Profiles, PINs and data;
A KMS used by an Application Provider for a Supplementary Security Domain falls

under the scope of a GP Card KMS.
The implementation of Platform and Application Key Management Systems within
the larger production environment is dependent on the role and set of services
offered by the entity requiring key management.
At the most basic level, it is up to the Card Issuer to make decisions regarding the
distribution of Key Values and the implementation of a KMS. The KMS may be a
stand-alone workstation using a Hardware Security Module (HSM) as an encryption
Page 28
engine, it may be separate or integrated with the Smart Card Management System
(SCMS) or it may even serve as both the GP Card KMS and the Application KMS for
some of the Card Issuers applications.
A.1.3 GP Card KMS versus Application KMS

It is important to understand the difference between GP Card KMS and an
Application KMS.
The GP Card KMS manages Key Profiles for the Issuer Security Domain and
Supplementary Security Domains, while the Application KMS manages keys for the
applications.
The Card Issuer will use the GP Card KMS for managing its Issuer Security Domain
Key Profiles, the Application Provider will use the GP Card KMS for managing its
Supplementary Security Domain keys, and both will use the Application KMS for
managing their application Key Profiles.
The application Key Profiles are managed by the Application Provider, but Card
Issuers routinely provide at least one application as well, and thus require an
Application KMS. However the Card Issuer may allow other applets on the card,
belonging to third party Application Providers within the same trust-model. This
means that the Card Issuer and a specific Application Provider have a mutually
agreed business relationship, making it feasible to use the Card Issuer Key Profiles
for the loading and personalization of the application Providers application. In this
scenario only one GP Card KMS is required, however an Application KMS is
required for each application supported on the card.
If the Card Issuer wishes to allow third party applets that are not within the same
trust-model, it becomes necessary to introduce Supplementary Security Domains, in
addition to the Issuer Security Domain. This makes it possible for an Application
Loader to add applications to a card without using the Issuer Security Domain Key
Values. A GP Card KMS, separate from the one belonging to the Card Issuer must
then be set up for the Application Provider, in which case there will be two Platform
Key Management systems and an Application KMS for each application on the card.
Alternatively, the Issuer or an Application Provider may set up a Supplementary
Security Domain purely to perform DAP verification to ensure the Card Issuers
approval of all the application loads.
A.1.3.1 Key Management System Keys

The Key Management System supports the following types of Key Values:
TDEA keys used by the GP Card KMS for the Issuer Security Domain and
Supplementary Security Domains;

Page 29
RSA keys used by the GP Card KMS for Delegated Management and/or DAPverification
A.1.3.2 Naming Convention for Keys

Table 2 defines the different key types typically used in a GlobalPlatform
implementation that must be managed by a KMS. GlobalPlatform defines three
derived key types for the Secure Channel Protocol management, namely S-ENC, SMAC, and DEK. In order to precisely identify a Key Value and the step of the card
life cycle where it applies, a prefix is added in this document to the name of each key
type. As an example, the Initial Issuer Security Domain key types are prefixed with
KDC (KDCenc, KDCmac, and KDCdek).
Name
Description
ADKENC
Card unique Security Domain Key Value derived from AMK used
for encrypting the commands to and from ICC during Post-issuance
ADKDEK
for encrypting Application Key Values during Post-issuance
ADKMAC
for MACing the commands to and from ICC during Post-Issuance
AMK
Application Provider Master Key Value locks the non Card

Manager Security Domain as CMK does for Card Manager
Application
keys
Non-GlobalPlatform Key Values, which uses GlobalPlatform Key

Values during personalization of the ICC
CDKDEK
Card unique Issuer Key Value derived from CMK used for
encrypting Application Key Values during Post issuance
CDKENC
Card unique Issuer Key Value derived from CMK used for
encrypting the commands to and from ICC during Post issuance
CDKMAC
Card unique Issuer Key Value derived from CMK used for MACing
the commands to and from ICC during Post issuance
CMK
Issuer Master Key Value used by Card Issuer to prevent the ICC
from further Initialization and Personalization using KMC and to
control Post-issuance initialization and Personalization
CMKRECEIPT
Security Domain Key Value Signing Receipt Optionally used by

the Issuer Security Domain to sign a receipt after a successful
delegated management load, install, extradition or delete
IKPTOKEN
Issuer Private/Public Key Pair Values Signing/Verifying Token

For delegated management, the private component is used by an

Page 30
issuer to sign Extradition, Load and Install tokens. The public

component is placed in the Issuer Security Domain in order to
verify the Extradition, Load and Install tokens
before delegated management Extradition, Load or Install is
permitted
ISK
Initial Supplier Key Value ensures that the Card Enabler can
only process on ICC to which he is entitled
KDCDEK
Card unique Initial Card Manager Key Value derived from KMC
used for encrypting Application Key Values during personalization
KDCENC
used for encrypting the commands to and from ICC during
personalization
KDCMAC
used for MACing the commands to and from ICC during
initialization and personalization
KDDDEK
Card unique Initial Security Domain Key Value derived from KMD
used for encrypting Application Key Values during Personalization
KDDENC
used for encrypting the commands to and from ICC during
Personalization
KDDMAC
used for MACing the commands to and from ICC during
Initialization and Personalization
KMC
Initial Issuer Master Key Value used by the Card Issuer to

control the initialization and personalization of each ICC
KMD
Initial Application Provider Master Key Value controls a non

Card Manager Security Domain as KMC does for Card Manager
TK
Transport Key Value established for secure exchange of Key Values

between any two entities
Table 2: Naming convention for Keys

A.1.3.3 Key Management System Roles
In order to understand the key types and services needed by a GlobalPlatform Key
Management System (KMS), it is necessary to see it in conjunction with the various
roles of the entities taking part in the process of producing a GlobalPlatform Chip
Card.
Page 31
Figure 1-1: Key Management System Roles illustrates the various roles and their
interaction with of the GlobalPlatform KMS. The separation between each role in
this figure, as with all figures in this document, does not imply that one entity is
restricted to only one role. On the contrary it will be typical that one entity plays
more than one role, for example a Card Issuer will typically also perform Application
Key Management for one or more applications on the ICC.
Refer to Table 2: Naming convention for Keys for the naming and definition of the
key types.
IC
Manufacturer
Produces IC
Install ISK
ISK
IC with
ISK
ISK
Manufacturer
KMS
Card
Manufacturer
ICC with
ISK
ISK
KMC
Has responsibility for

the Issuer Security
Domain = the overall
Security of the ICC
GP Card
KMS
(Issuer
Security
Domain)
KMC
TK
TK(CDK)
TK'(Application keys)
TK'
Application
KMS
Embeds IC in Card= ICC

Install/Load Card Manager
Leaves ISK unmodified
Card Enabler
Enables ICC for an Issuer (IIN)

Installs KDC by knowledge of ISK
Issuer ICC with

KDC
Application
Loader
Loads and Installs any applet using KDC for

secure messaging
Personalizes applet using KDC for secure
messaging and confidentiality of application
keys and PINs
Finally secures the Card by installing CDK
Has responsiblity of application keys and PINs

Will provide these to Application Loader using a Transport Key
Application KMS can be a role of Card Issuer, it can be seperate utilizing Card
Manager Security Domain or it can utilize its own Security Domain
Figure 1-1: Key Management System Roles

Page 32
Note 1: The impact to the Key Management Systems when an Application Provider
uses a Supplementary Security Domain will be outlined in detail in section A.1.5
Application KMS keys.
In this context, it is expected, if being part of a GP Card KMS, that the
Manufacturer KMS, for ISK, will use the same algorithm, mechanisms and method
as the GP Card KMS in general.
The ISK shared between the IC Manufacturer and Card Enabler is to ensure that
the IC is protected between the IC manufacturer and the Card Enabler.
The Card Enabler enables the card for a specific Card Issuer by assigning the
Issuers IIN to the ICC and by installing the initial set of Issuer Key Values (KDCs)
derived from the Issuers Initial Master Key Value KMC.
Through the distribution of the KMC to a specific Application Loader the Card
Issuer now controls who can load, install and personalize the applets on the ICC.
During the Personalization process it is possible to use the GlobalPlatform KDCs for
the personalization of the application Key Values, PIN and other secret data to be
used by a specific applet.
After the Applet has been personalized the Card Issuer secures the card by having
the CDKs derived from CMK installed. By doing so, the KMC is effectively disabled.
The Card Issuer can now use the CMK as the Key Value to secure any post-issuance
activity on the card.
A.1.3.4 Key Management System scenarios

There are at least four distinct pre-issuance scenarios for a GlobalPlatform KMS:
KMS with one Security Domain (automatically being the Issuer Security
Domain)
KMS with more than one Security Domain (i.e. the Issuer Security Domain
and one or more Supplementary Security Domains).
KMS with more than one Security Domain and integrity-checking when
loading and/or installing the applet (DAP Verification).
KMS with more than one Security Domain having one or more
Supplementary Security Domains with Delegated Management privilege for
application load and install.
For all scenarios the method for protecting the IC between the IC Manufacturer and
Card Enabler is the ISK Key Value as described in Figure 1-1: Key Management
System Roles. This part of the scenario being constant it is not repeated in
subsequent specific scenario illustrations nor is the Manufacturer KMS detail
repeated for the same reason.
A.1.3.4.1
Page 33
KMS with one Security Domain
The first scenario is as illustrated in Figure 1-3. It assumes that the Card Issuer
controls the GP Card KMS and that the Application Provider is under the same
trust-model as the GP Card KMS either being the same organization or under
control of a mutual agreed trust-model.
KMC
GP Card
KMS
(Issuer
Security
Domain)
KMC
TK
TK(CDK)
Card Enabler
Issuer ICC with

KDC
Application
Loader
TK'
Application
KMS
Figure 1-2: KMS with one Security Domain

If the GP Card KMS and the Application KMS are implemented as one system, the
TK Key Value used for transporting the CDKs could be the same as for transporting
the application Key Values.
A.1.3.4.2
KMS with more than one Security Domain
The second scenario assumes that the Card Issuer and the Application Provider are
not under the same trust-model. Hence it must be possible for the Application
Provider to establish a secure channel without using the Card Issuer Key Values.

KMC
GP Card
KMS
(Issuer
Security
Domain)
KMC
TK
TK(CDK)
Card Enabler
Issuer ICC with

KDC
Application
Loader
TK'
Page 34
KMD
GP Card
KMS
(Supplementary
Security
Domain)
KMD
TK
TK(ADK)
TK'
Application
KMS
Application
KMS
Figure 1-3: KMS with more than one Security Domain
A.1.3.5 KMS with DAP Verification

Again the Card Issuer and the Application Provider are not under the same trustmodel. This third scenario is the same as the second scenario, but with an additional
feature. It is possible for the Application Provider to verify that the applet loaded
and installed by the Card Issuer is the correct one.

Page 35
DAP Public or
DES Secret Key
KMC
GP Card
KMS
(Issuer
Security
Domain)
KMC
TK
TK(CDK)
Card Enabler
DAP Private or
DES Secret Key
KMD
ICC with KDC,

KDD and DAP key
GP Card
KMS
(Supplementary
Security
Domain)
KMD
TK
TK(ADK)
Application
Loader
TK'
TK'
DAP Signature
Application
KMS
Application
KMS
Figure 1-4: KMS with DAP Verification

Note: DAP Verification may be based on TDEA or RSA.
A.1.3.5.1
KMS with Delegated Management
The fourth scenario assumes that the Card Issuer and the Application Provider are
not under the same trust-model, and that the Card Issuer uses Load and Install
Tokens to allow Load and Install of applets via the Supplementary Security
Domains with the Delegated Management Privilege.

DAP Private or
DES Secret Key
Note 1
Page 36
DAP Public or
DES Secret Key
Note 1
Card Enabler
KMC
GP Card
KMS
(Issuer
Security
Domain)
KMC
TK
ICC with KDC,

KDD and DAP key
TK(CDK)
KMD
GP Card
KMS
(Supplementary
Security
Domain)
KMD
TK
Application
Loader
TK(ADK)
TK'
TK'
Token
Application
KMS
DAP
Application
KMS
Figure 1-5: KMS with Delegated Management

Note1: DAP Verification may be based on TDEA or RSA.
A.1.4 GP Card KMS Keys

The GP Card KMS is used for generating and storing of Key Profiles for Issuer
Security Domain Key Values. The GP Card KMS also generates and stores the Key
Profiles for an Application Provider Security Domain. The GP Card KMS may be
used for exporting these Key Profiles to other entities such as the Card Enabler or
the Application Loader.
Key Values are identified by a Key Identifier and a Key Version as defined in
GlobalPlatform Card Specification 2.1.
The GP Card KMS maintains, beside the Transport Key Values used for secure
communication with other Key Management Systems, two categories of key types:
Key Profiles for secure communication and content management between the
card and an off-card entity;
Key Profiles for managing permissions and application integrity.

Page 37
A.1.4.1 GP Card KMS for Issuer Security Domain

A.1.4.1.1
Secure Channel Protocol Keys
Initial Update Master Key (KMC), used to derive the Initial Card
Manager Key Values below for Card Enablement.
9 MAC Key (KDCmac);
9 Encryption Key (KDCenc);
9 Key Encryption Key (KDCdek).
Final Card Manager Master Key (CMK), used to derive the final Card
Manager Key Values below for the SECURED state. During personalization,
only the final derived Key Values are exchanged with the Application Loader,
i.e. the Key Values are derived by the GP Card KMS and the master key
remains known to the Issuer only.
9 MAC Key (CDKmac)
9 Encryption Key (CDKenc)
9 Key Encryption Key (CDKdek).
A.1.4.1.2
Permission Management Keys
Card Manager or Issuer Security Domain Receipt Key (CMKRECEIPT),

used to sign a receipt indicating that a delegated management load, install,
extraction, or deletion has occurred.
Issuer private/public key pair (IPKTOKEN), used to sign the Extradition,

Load and Install tokens. The KMS must have the flexibility to support key
lengths ranging from 512 to 2048 bits. The IPKTOKEN secret Key Value will be
stored within the GP Card KMS used to generate tokens. The IPKTOKEN public
Key Value will be sent to the card enabler for placing on the card. The
detailed token format is defined in the GlobalPlatform Card
Specification 2.1.
A.1.4.2 GP Card KMS for Supplementary Security Domain

A.1.4.2.1
Secure Channel Protocol Keys
Initial Update Security Domain Master Key (KMD), used to derive the
Initial Security Domain Key Values for Application Enablement.

Page 38
9 MAC Key (KDDmac)

9 Encryption Key (KDDenc)
9 Key Encryption Key (KDDdek).
Final Security Domain Master Key (AMK), used to derive the final
Security Domain Key Values for personalizing the Security Domain. During
personalization, only the final derived keys are exchanged with the
Application Loader, i.e. the Key Values are derived by the GP Card KMS and
the master Key Value remains known to the Application Provider only.
9 MAC Key (ADKmac)
9 Encryption Key (ADKenc)
9 Key Encryption Key (ADKdek).
A.1.4.2.2
Permission / Integrity Management Keys
DAP Verification Key, used to verify the Load file of the Application
Provider. The key type can be a public key or a TDEA key. The format of the
load file includes a DAP block (a signature of the load file generated using a
symmetric key or an asymmetric key) followed by the Load File Data Block
(which is the actual code). The detailed format is defined in the
GlobalPlatform Card Specification 2.1.
A.1.5 Application KMS keys

The Application KMS will be used for generation and storing of Key Profiles for
applet specific purposes and possible export of those Key Profiles to the Application
Loader. Since these Key Profiles are application specific and not defined within
GlobalPlatform, they are not identified by name and as unique Key Profiles they are
not considered part of this specification.
However since the intention is to use the GP Card KMS Key Profiles for a secure
load of the application Key Values plus other secret information, the services
provided by the GP Card KMS Key Profiles for those purposes will be defined here.
Due to key type separation purposes, it does make sense to identify the application
Key Profiles and secret data, not by name, but by type. The Application KMS Key
Profiles can be used to protect Key Values and data of the following type:
DES/TDEA keys
RSA private keys

Secret data such as PIN
Confidential data
Page 39
Each type of secret or confidential information shall be treated differently as to the

nature of its type.

Page 40
A.2. Functional Requirements to Support a

GlobalPlatform Card
The term GP Card KMS will be used throughout this document to reference the
requirements detailed in this chapter.
A.2.1 Functional Requirements

The GP Card KMS requirements described in this chapter are extensions to the
requirements specified in the General Key Management System Requirements
section 3.
A.2.1.1 Overall requirements for a KMS

The KMS shall be able to maintain Key Profiles for the entire lifetime of each
specific key i.e. from definition, generation and storage, through Key Profile
exchange and usage to expiration and deletion.
The KMS shall provide services to relevant systems having a need for the use of a
specific Key Value.
The KMS shall have any secret or critical function (such as generating or
unwrapping/wrapping Key Values) performed within a Hardware Security Module
or equivalent secure component.
The KMS shall be able to recover all Key Values within the KMS in case of failure in
the KMS itself or in the HSM utilized.
A.2.1.2 Requirements for HSM

As previously stated in the General KMS requirements.
A.2.1.3 Requirement for Access and Audit

A.2.1.4 Requirements for Supporting Cryptographic Algorithms


Page 41
A.2.1.5 Requirements for Key Profile

The GP Card KMS shall be able to define Key Profiles of all the key types, which are
defined within the system. The Key Profile shall encompass at least:
Key Profile ID;
Key Profile Version;
Effective date;
Expiration date;
Usage of Key;
Application ID of the Security Domain. The ID is the Issuer Identification

Number (IIN) for the Card Issuer and the Application Provider Identification
Number for an Application Provider.
Details surrounding the format and usage of a Key Profile are to be described in the
GlobalPlatform Profile Specification.
A.2.1.6 Requirements for Key Generation

The GP Card KMS shall be able to support TDEA keys of following characteristics:
As previously stated in the General KMS requirements, with the following
exception:
The GP Card KMS shall be able to support RSA key pairs only if the GP
Card KMS supports Delegated Management or LoadToken utilizing RSA:
A.2.1.7 Requirements for Storing Keys

All Key Values, which due to their longevity, shall be stored in a way that they are
protected from exposure and unauthorized modification, the associated information
shall also be protected from unauthorized modification.
Along with the actual Key Value certain other information shall be stored. This shall
include at least:
ID of the specific Key Value uniquely identifying the key;
Key Profile of the key, which includes items such as:

Version of the Key Profile;

Page 42
Information on how the key is encrypted, i.e. an identification of the

Key encrypting the Key Value;
Installation, Effective, and Expiration dates;
Indicator for whether a Key Value is for test or live-environment;
Key Check Value to make it possible to exchange information about a
given Key Value without exposure the Key Value itself.
Information on the key Values extended usage
A.2.1.8 Requirements for Key Exchanging

A.2.1.8.1
A given implementation of a GP Card KMS shall be able to support a secure

exchange of Key Profiles with another GP Card KMS, an Application KMS or
another Key Management system that supports the messaging formats specified for
a GP Card KMS.
The KMS shall be able to exchange information concerning both the Profile of the
key and the Key Value.
The mechanism of exchange shall ensure integrity of the data and transfer.
For the GP Card KMS, there are 5 different methods of exchanging Key Values
and/or key information:
Key Profile information only;
Clear TDEA Key Value component with reference to a previously exchanged

Key Profile;
Encrypted TDEA Key Value with reference to a previously exchanged Key

Profile;
Encrypted TDEA Key Value combined with the Key Profile itself;
Clear Public Key Value with reference to a previously exchanged Key Profile,
if Delegated Management and/or DAP verification is supported.
A.2.1.8.2
Exchanging Profile of the Key
The GP Card KMS shall be able to exchange the Key Profile for a specific Key Value
(see section A.2.1.5 Requirements for Key Profile). The GP Card KMS shall support

Page 43
methods to ensure the integrity of the Key Profile during exchange and/or after
installation.
A.2.1.8.3
Exchanging TDEA Keys
A number of Transport Keys (TK) shall be exchanged between two KMS having the
need for exchanging Key Values.
The Transport Keys exchanged shall be exchanged in a manner that shall provide
mutual authentication and secrecy. It is suggested that the KMS Usage Guidelines
are followed to provide the necessary security.
If encrypted, the Key Values shall be encrypted using TDEA in ECB mode as defined
in GlobalPlatform Card Specification 2.1.
The Transport Keys can be exchanged using various media such as diskette, paper,
Smart Cards, VPN or LAN-connections.
A.2.1.8.3.1 Exchanging Clear TDEA Key Value components
The first Transport Key exchanged shall be exchanged as a number (greater than 1)
of components, each component separately transferred between sender and receiver.
Subsequent exchange of Key Profiles may use this Transport Key during transport.
The components shall be split from and combined to the final Key Value using the
Exclusive Or (XOR) technique.
Certain information other than the actual key component shall be transferred. This
information shall encompass at least:
ID of the specific Key Value uniquely identifying the Key Profile to both
Number of Components;
Component Number;
Key Profile ID;
Generation date;
Effective date;
Expiration date;
Indicator for whether the Key Value is a test or a live key;

Page 44
Key Check Value of each component;
Key Check Value for the final combined Key Value, making it possible to
verify that the Key Value after installation has the same value at both
sender and receiver.
A.2.1.8.3.2 Encrypted TDEA Key with reference to a Key Profile

The subsequent Transport Keys or permanent Platform keys shall be exchanged
encrypted using a Transport Key during transport in a format mutually agreed upon
between sender and recipient.
The clear-text value of the key, prior to being encrypted under the Transport Key,
shall have odd parity.
Certain information other than the actual encrypted Key Value shall be transferred
along with the Key Value. This information shall encompass at least:
ID of the specific Key Value uniquely identifying the Key Value to both
Key Profile ID;
Generation date;
Effective date;
Expiration date;
Key Check Value making it possible to verify that the Key Value after
A unique identification to both sender and receiver of the Transport Key

used for encrypting the exchanged Key Value during transport.
A.2.1.8.3.3 Encrypted TDEA Keys with a Key Profile

The Platform keys, which at a specific location only exist during the execution of a
process, shall be exchanged encrypted using a Transport Key during transport in a
format mutually agreed upon between sender and recipient.
The clear-text value of the key, before encrypted under the Transport Key, shall
have odd parity.
Page 45
Key Profile Information;
Card Identification Number (CIN) - unique for each card.
Generation date;
Effective date;
Expiration date;
Key Check Value making it possible to verify that Key Value after

If the Transport Key itself is not used directly as the Key Encryption Key, but
instead used to create a derived Key Encrypting Key, the information transferred
with the derived Key Value must include the derivation data.
If the Transport Key itself is not used directly as the Key Encryption Key, but
instead used to encrypt a random Key Encryption Key, used only for that
transaction, the information transferred with the actual Key Value must include the
encrypted random transaction key.
A.2.1.8.4
Clear Public RSA keys
If a specific GP Card KMS supports Delegated Management and/or DAP Verification

processes utilizing RSA, the Public RSA keys shall be exchanged using a method
providing authenticity and integrity of the Key Value and any associated
information.
Certain information other than the Key Value itself shall be transferred along with
the Key Value. This shall at least encompass:
Key Profile ID;

Generation date;
Effective date;
Expiration date;
installation has the same value at both sender and receiver.
Page 46
A.2.1.9 Requirements for Importing and Exporting Keys

The GP Card KMS shall support mechanisms to make it impossible for an
unauthorized import to the GP Card KMS or to export a generated and/or stored
Key Profile. It is suggested that the KMS Usage Guidelines are followed to provide
adequate security procedures.
A.2.1.10 Requirements for Key Separation

The KMS shall support methods to make it impossible to use a Key Value other than
for the purpose specified in the key usage attribute.
A.2.1.11 Requirements for Date Checking

A.2.1.12 Requirements for Expiration and Deletion

A.2.1.13 Requirements for Key Derivation

The GP Card KMS shall be able to derive Key Values as defined in GlobalPlatform
Card Specification 2.1.
A.2.1.14 Transport of Application Secret Data

The GP Card KMS shall support methods and formats for transporting secret
application information, i.e. keys, PIN Blocks and confidential data (see Section B.2
Functional Requirements to Support an EMV Application for details).
A.2.1.15 Requirements for other Crypto Functions

The GP Card KMS shall support the following cryptographic methods:
Page 47
MACing using the methods defined in the GlobalPlatform Card specification

2.1, appendix B
Signature-generation with RSA-keys as defined in GlobalPlatform Card

Specification 2.1, when Delegated Management or DAP verification are
required.
SHA-1 Secure Hashing Algorithm 1

Page 48
Appendix B EMV Application

This appendix covers the Case study of an EMV application and is a hypothetical
example of how the tools described in the main part of this document could be
applied.

Page 49
B.1. EMV Application Details

B.1.1 About this chapter
In order to understand the key types and processes the Application KMS will be
required to achieve, this chapter will provide a basic overview of the processes that
are required to prepare the data and key types for an EMV application.
This chapter will not cover the use of an EMV application once it has been
personalized.
The requirements for RSA Key Generation are based on off-card RSA Key
Generation, but does not exclude on-card RSA Key Generation.
B.1.2 Actors Roles and Responsibilities
Application Owner The Application Owner acts as the Certification

Authority (CA) who certifies the integrity of the Card Issuer and possibly the
Application Provider. Application Owners in EMV are Institutions such as
MasterCard and Visa that play the role of CAs, they are responsible for
certifying the integrity of Issuers.
Card Issuer The Issuer is the entity responsible for card issuance, although
the production of cards may be sub-contracted to a card production company.
The Issuer is also responsible for the generation of the data that will be used
to create the Card, such as Embossing, Magnetic Stripe, Carrier, etc.
Application Provider The Application Provider performs the Data

Generation of the EMV smart card application, specific for each cardholder.
Application Loader The Application Loader performs the Personalization of

the card and is the role responsible for the loading of the application and/or
application specific data onto the card.
On a multi-application card the Card Issuer and the Application Provider are not
always the same entity. However, this is seldom, if ever, the case with an EMV
application. Since Banks typically issue the card and provide the EMV application,
the Issuer and the Application Provider are the same entity. This chapter simply
refers to the Issuer since many of the EMV application key types refer to the Issuer.
However, it should be understood that in fact we are dealing with application
specific key types, if the EMV application provider will not be the Card Issuer, the
term Issuer should be understood to be an Application Provider.

Page 50
B.1.3 EMV Application keys
TDEA Keys
o
Transport Key (TK) Key or key(s) value are used to protect the
sensitive data (such as Key Values) as they are transported from
Issuer though Data Generation and onto Personalization. The data
protected from the Issuer may include a PIN Block, and the data
protected during Data Generation which will include all the EMV
scheme Key Values
Issuer Master Keys (IMKs):
Application Cryptogram (IMKAC)
Secure Messaging Integrity (IMKMAC)
Secure Messaging Confidentiality (IMKENC)
ICC Master Keys (MK)
Application Cryptogram (MKAC)
Secure Messaging Integrity (MKMAC)
Secure Messaging Confidentiality (MKENC)
RSA Keys:
o
Certification Authority (CA):

Note: This key is managed by the payment system, not the Issuer.
CA Public Key
Issuer:
Issuer Keyset
Issuer Public Key Certificate
ICC
Dynamic Data Authentication (DDA):
ICC Keyset
DDA ICC Public Key Certificate

Page 51
PIN Encipherment Key (PEK):

Note: The Issuer may choose to use DDA Key Values for the
PIN encipherment.
PEK Keyset
PEK Public Key Certificate
B.1.4 EMV Application Related Information
RSA Keys:
o
Certification Authority (CA):
CA Public Key Index
Registered Identifier (RID)
Issuer:
Issuer Public Key Certificate Requests
Issuer Public Key Certificate Response
Issuer Public Key Exponent
Issuer Public Key Certificate (CA signed ICert)
Issuer Public Key Remainder
ICC
Dynamic Data Authentication (DDA):
PIN Encipherment Key (PEK):
DDA Public Key Remainder
PEK Public Key Remainder
PIN Block

Page 52
B.1.5 Processes
B.1.5.1 RSA Data
A Card Issuer is required to register with a Certification Authority. This involves
the Issuer generating their own Issuer Keyset and providing the CA with an Issuer
Public Key Certificate request.
The Application Owner (Certification Authority (CA)) is then responsible for
certifying the Card Issuer by the creation of an Issuer Public Key Certificate (ICert)
and optionally an Issuer Public Key Remainder, using the CA Private Key to sign
the Issuer Public Key.
Once the CA has certified the Issuer Public Key, the Issuer will receive back an
Issuer Public Key Certificate and optionally an Issuer Public Key Remainder.
The Issuer has the following responsibilities:
For DDA the Issuer will be required to create an ICC Keyset and certify the
ICC Public Key using the Issuer Private Key, and to create an ICC Public
Key Certificate, and optionally an ICC Public Key Remainder.
PIN encipherment may use the ICC Key Value used for DDA or the Issuer
may use an ICC PIN Encipherment keyset using the same process used for
DDA.
The Signed Static Application Data (SAD) for each ICC is created by using
the Issuers Private Key.
Once the data has been generated and prepared, it is the responsibility of the
Issuer to provide the Application Loader with key and data; secrecy
(concerning key), confidentiality and integrity in general must be considered
for this operation.
B.1.5.2 TDEA Data

The Issuer is responsible for the creation of the Issuer Master Key (AC, MAC and
ENC). These key types may need to be exported to other parties such as Stand-in
Processor. If the role of Application Provider is not done using the same KMS as the
Card Issuer then the Key Profiles will be required to be exported to the KMS of the
Application Provider.
Once these Key Values have been generated the Issuer is responsible for the
creation of ICC Master Keys (MKs). This is typically achieved by deriving the
Master Keys with a piece of Cardholder specific information ie. the PAN and PAN
Sequence Number as shown in EMV 2000 Version 4.0 Book 2 Annex A1.4.

Page 53
Once the MKs have been generated it is the responsibility of the Issuer to provide
the Key Values to the Application Loader for loading onto the card; confidentiality
and integrity should be considered for this operation.

Page 54
B.2. Functional Requirements to Support an EMV

Application
While EMV is application specific we document the requirements for EMV as a case
study to demonstrate the KMS requirements for a typical Smartcard application.
Most of the requirements for an Application KMS are up to the specific application
specification to define and so are outside the scope of this document. However the
EMV application will be used as a case study from which to draw Application KMS
requirements.
Application KMS vendors will be responsible for providing extensions to these
requirements to meet the needs of other applications they intend to support. Vendor
specific extensions shall not undermine the security of the KMS requirements in this
document.
B.2.1 EMV Case Study

The remainder of this chapter uses the EMV application as the basis for the
requirements of Application KMS. Vendors not wishing to support an EMV
application are not required to meet these key type and key inter-change
requirements, however other applications are likely to re-use the same principles
that are required for the EMV application.
The EMV application has been chosen for the basis of the Application KMS
requirements due to the well defined and globally understood standards that are in
place to define the application. For further information of the EMV Application see
sections B.1.
B.2.2 Functional Requirements

To be able to utilize the GlobalPlatform security architecture for a secure
installation of an applet and/or applet specific data, the Application KMS shall also
support specific methods from General and GP Card KMS requirements. The
requirements necessary to support GlobalPlatform are a subset of the General and
GP Card KMS requirements for:
Key Value generation;
Key Value exchange;
Key Profile separation;
Key Value export and import.

Page 55
In addition to the common requirements of the General and GP Card KMS the
Application KMS will have a requirement for:
RSA EMV Certificate Inter-change;
Transport of application secret data.
For the transport of application Key Profiles and PINs, the Application KMS shall
make it possible to separate the following types of secret information and encrypt it
in accordance with the nature of its content:
TDEA keys;
RSA private keys;
Secret data like PIN;
Confidential data.
The Application KMS will not be used to generate, store or exchange PINs or other
confidential data, however the Key Profiles stored in the Application KMS may be
used for the encryption of PINs and/or other confidential data.
B.2.2.1 Overall Requirements for a KMS

B.2.2.2 Requirements for HSM

B.2.2.3 Requirement for Access and Audit

B.2.2.4 Requirements for Supporting Cryptographic Algorithms

The Application KMS shall at least be capable of supporting key types for the
following algorithms:
TDEA Triple Encryption Algorithm
RSA Rivest Shamir Adleman.

Page 56
B.2.2.5 Requirements for Key Profile

The Application KMS shall be able to define Key Profiles of all the keys profile,
which are defined within the system. The Key Profile shall encompass at least:
Key Profile ID;
Effective date;
Expiration date;
Usage of Key;
The Key Profile will be in detail be outlined later as part of the work to be done
subsequent to these Functional Requirements as GlobalPlatform Key Profile
Specification.
B.2.2.6 Requirements for Key Generation

The Application KMS shall be able to support TDEA keys of following
characteristics:
128 bit key, comprising of 112 bit Key Value plus odd parity
Weak or semi-weak Key Values are not allowed
Generated using either a True Random Number Generator or a Pseudo

Random Number Generator. The Random Number Generator that is used
shall, be designed to pass the statistical tests specified in FIPS 140-2
The Application KMS shall be able to support RSA key pairs of the following
characteristics:
512 bits to 1984 bits long in 8 bits increments
The factors of the modulus (p and q) shall be generated using random

number generation in combination with primality testing. The random
number generation part shall meet the same requirements as specified in R20c. The primality test can be statistical or deliver absolute proof. If it
statistical it should be based on a recognized primality test algorithm
executed with enough iterations as to give negligible probability of p or q not
being prime

Page 57
B.2.2.7 Requirements for Storing Keys

All Key Values, which due to their longevity, shall be stored in a way that they are
protected from exposure and unauthorized modification, the associated information
shall also be protected from unauthorized modification.
Along with the actual Key Value other information shall be stored. This shall
include at least:
ID of the specific Key Value uniquely identifying the key;
Key Profile of the key;
Version of the Key Profile;
Information on how the Key Value is encrypted, i.e. an identification of the

Key encrypting the Key;
Installation, Effective, and Expiration dates;
Indicator for whether a Key Value is for test or live-environment;
Key Check Value to make it possible to exchange information about a given

Key Value without exposure the Key Value itself.
B.2.2.8 Requirements for Key Exchanging

B.2.2.8.1
A given implementation of a Application KMS shall be able to support a secure

exchange of Key Profiles with another Application KMS, a GP Card KMS or another
Key Management system that supports the messaging formats specified for an
Application KMS.
The KMS shall be able to exchange information concerning both the Profile of the
key and the Key Value itself.
The mechanism of exchange shall ensure integrity of the data transferred.
For the Application KMS, there are the following different methods of exchanging
Key Values and/or key information:
Key Profile information only;
Clear TDEA Key Value component with reference to a previously exchanged

Key Profile;

Page 58
Encrypted TDEA Key Value with reference to a previously exchanged Key

Profile;
Encrypted TDEA Key Value combined with the Key Profile itself;
Encrypted Private RSA Key Value with reference to a previously exchanged

Key Profile;
Encrypted Private RSA Key Value with the Key Profile itself;
Clear Public Key Value with reference to a previously exchanged Key Profile.
B.2.2.8.2
Exchanging Profile of the Key
The Application KMS shall be able to exchange the Key Profile for a specific Key
Value (see section B.2.2.5 Requirements for Key Profile). The Application KMS shall
support methods to ensure the integrity of the Key Profile during exchange and/or
after installation.
B.2.2.8.3
Exchanging TDEA Keys
A number of Transport Keys (TK) shall be exchanged between two KMS having the
need for exchanging Key Profiles.
The Transport Keys exchanged shall be exchanged in a manner that shall provide
mutual authentication and secrecy. It is suggested that the KMS Usage Guidelines
are followed to provide the necessary security.
If being encrypted, the Key Values shall be encrypted using TDEA in ECB mode as
defined in GlobalPlatform Card Specification 2.1.
The Transport Keys can be exchanged using various media such as diskette, paper,
Smart Cards, VPN or LAN-connections.
B.2.2.8.3.1 Exchanging Clear TDEA Key Components
The first Transport Key exchanged shall be exchanged as a number (greater than 1)
of components, each component separately transferred between sender and receiver.
Subsequent exchange of Key Profiles may use this Transport Key during transport.
The components shall be split from and combined to the final Key Value using the
Exclusive Or (XOR) technique.
Certain information other than the actual Key Value component shall be transferred

Page 59
Number of Components;
Component Number;
Key Profile ID;
Generation date;
Effective date;
Expiration date;
Key Check Value of component;
Key Check Value for the final combined Key Value, making it possible to
verify that Key Value after installation has the same value at both sender
and receiver.
B.2.2.8.3.2 Encrypted TDEA Key with reference to a Key Profile

The subsequent Transport Keys or permanent Application Key Profiles shall be
exchanged encrypted using a Transport Key during transport in a format mutually
agreed upon between sender and recipient.
The clear-text value of the Key Value before encrypted under the Transport Key
shall be of odd parity.
Key Profile ID;
Generation date;
Effective date;
Expiration date;

Page 60

B.2.2.8.3.3 Encrypted TDEA Keys with a Key Profile

The Application keys, which at a specific location only exist during the execution of a
process, shall be exchanged encrypted using a Transport Key during transport in a
format mutually agreed upon between sender and recipient.
The clear-text value of the Key Value before encrypted under the Transport Key
shall be of odd parity.
Key Profile;
Generation date;
Effective date;
Expiration date;

used for encryption of the exchanged Key Value during transport.
B.2.2.8.4
Exchanging RSA Keys
B.2.2.8.4.1 Encrypted Private RSA Key with reference to a Key Profile

Certain information other than the Key Profile itself shall be transferred along with

Key Profile ID;
Generation date;
Effective date;
Expiration date;
Page 61
B.2.2.8.4.2 Encrypted Private RSA Key with the Key Profile

Certain information other than the Key Profile itself shall be transferred along with
Key Profile Information;
Generation date;
Effective date;
Expiration date;
B.2.2.8.4.3 EMV Issuer Certificate Request

In order for an EMV Issuer Certificate to be produced the EMV Application KMS
shall produce an EMV Issuer Certificate Request, as defined by the relevant EMV
CAs that will be supported by the EMV Application KMS vendor.
B.2.2.8.4.4 EMV Issuer Certificate Response
The Issuer Public Key Certificate and optionally the Issuer Public Key Remainder
shall be imported into the EMV Application KMS. The Certificate and Remainder
shall be validated against the relevant CA Public key and relevant Issuer Public Key
Certificate Request. This validation requires the presence of the relevant CA public
key in the EMV Application KMS.
Page 62
B.2.2.9 Requirements for Importing and Exporting Keys

The Application KMS shall support mechanisms to make it impossible for an
unauthorized import to the Application KMS or to export a generated and/or stored
Key Value.
B.2.2.10 Requirements for Key Separation

The KMS shall support methods to make it impossible to use a Key Value for
another usage or purpose than intended.
B.2.2.11 Requirements for Date Checking

B.2.2.12 Requirements for Expiration and Deletion

B.2.2.13 Requirement for Issuer Certificate Request

The Application KMS shall support the requesting of EMV Issuer Certificate for the
Certification Authorities the vendor wishes to support.
B.2.2.14 Requirement for Issuer Certificate Response Import

The Application KMS shall support the importing of EMV Issuer Certificate for the
Certification Authorities the vendor wishes to support.
B.2.2.15 Transport of Application Secret Data

The Application KMS shall support methods and formats for transporting secret
application information, i.e. Key Values, PIN Blocks and confidential data.
B.2.2.16 Requirements for other Crypto Functions

The Application KMS shall support at least the following cryptographic services to
allow the Application Provider to generate the application cryptographic data such
as the ICC Master Key Values, Static Data Authentication and ICC Public Key
certification:
MACing using method defined in GlobalPlatform Card Specification 2.1

Appendix B.1.2.2, otherwise known as ISO 9797-1 method 3;
Signature generation with RSA-keys;

Page 63
SHA-1 Secure Hashing Algorithm 1;
Key Derivation using the method described in EMV 2000 book 2 Annex A1.4
Master Key Derivation.
Note: The method described in A1.4 is an EMV option, not a mandate so
another method may be used.

GlobalPlatform
Key Management System Functional Requirements
Appendix C - Possible Global Platform KMS Configurations

Global Key Management System
GP Card Key Management Functions
Same Trust
Model
Not Same
Trust Model
DAP
Verification
Card Issuer
Card Issuer Security

Domain
Supplementary
Security Domain(s)
Manages Issuer security

domain Key Profiles
Manages Supplementary
Security Domain Key Profiles
Load/install/personalization of
an Application Provider applet,
data and Key Values
(One platform KMS services a
number of Applets within the
Issuer Security Domain)
(There will always be an Issuer
Security Domain)
N/A
Personalization of Application
Provider application data and
Key Values (One platform KMS
function / application supported)
Load/Install/Personalization of
Application Provider applet, data
and Key Values
(One platform KMS services a
number of Applets within that
security domain)
Ensure Card Issuers approval of
all application loads via DAP
Verification
Application Key Management Functions

Note: Card Issuer can be (and typical is) an
Manages Application Key Profiles
One Application KMS per Application Provider or
Application, depending on the choice of the
Application Provider.
(There can be more applications covered by the same
Application KMS, if the applications are similar in
their need for KMS services)
One Application KMS per Application Provider or
Application, depending on the choice of the
(There can be more applications covered by the same
Application KMS, if the applications are similar in
their need for KMS services)
N/A

Page 64

KMS Functional Reqs v1 0

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

KMS Functional Reqs v1 0

Diunggah oleh

Hak Cipta:

Format Tersedia

GlobalPlatform Key Management System

GlobalPlatform Key Management System Functional Requirements

2. OVERVIEW OF KEY MANAGEMENT SYSTEMS ......................................................... 15

WHAT IS A KMS ............................................................................................................ 17

3. GENERAL KEY MANAGEMENT SYSTEM REQUIREMENTS ................................... 18

GlobalPlatform Key Management System Functional Requirements

APPLICATION KMS KEYS .......................................................................................... 38

A.2. FUNCTIONAL REQUIREMENTS TO SUPPORT A GLOBALPLATFORM CARD40

GlobalPlatform Key Management System Functional Requirements

APPENDIX C - POSSIBLE GLOBAL PLATFORM KMS CONFIGURATIONS.............. 64

Copyright 2003 GlobalPlatform Inc. All Rights Reserved.

GlobalPlatform Key Management System Functional Requirements

Copyright 2003 GlobalPlatform Inc. All Rights Reserved.

GlobalPlatform Key Management System Functional Requirements

Copyright 2003 GlobalPlatform Inc. All Rights Reserved.

GlobalPlatform Key Management System Functional Requirements

The process of providing applications on a GlobalPlatform Multi-application Chip

The GlobalPlatform Key Management Functional Requirements define the

Copyright 2003 GlobalPlatform Inc. All Rights Reserved.

GlobalPlatform Key Management System Functional Requirements

Purpose of this document

The intention of GlobalPlatform KMS Functional Requirements is to serve as input

This document is intended to be read by card issuers, application providers, system

Copyright 2003 GlobalPlatform Inc. All Rights Reserved.

GlobalPlatform Key Management System Functional Requirements

References and applicable documents

Europay, MasterCard, and Visa (EMV) Integrated Circuit Card

Copyright 2003 GlobalPlatform Inc. All Rights Reserved.

GlobalPlatform Key Management System Functional Requirements

Representation of a chip application software and/or data. In this

Application Identification Number

The Application Providers unique Identifier as defined in ISO 7812.

Application Key Management

The Application Key Management System provides application

The Application Loader loads Card Issuer specific cards with

The Application Provider procures the necessary components to

A cryptographic technique commonly referred to as Public Key.

Card Enabler / Initializer

The entity that prepares the platform for subsequent application

Card Image Number (CIN)

Uniquely identifies a smart card within a Card Issuer environment

The Card Issuer issues cards to cardholders.

The Issuers on-card control mechanism for a GlobalPlatform chipcard.

(Chip) Card Manufacturer

The entity that manufactures (fabricates) cards on behalf of and to

A card with an embedded processor chip on it, also referred to as

Copyright 2003 GlobalPlatform Inc. All Rights Reserved.

GlobalPlatform Key Management System Functional Requirements

The process of gathering and preparing the necessary application

The reversal of the corresponding encryption, reversible

Allows an Application Provider to load and install an application on a

An asymmetric transformation of data intended to prove to the data

The reversible transformation of data by cryptographic algorithm to

An instance of a GlobalPlatform Key Management System that

Within this document the term HSM is used to indicate the

A card with an embedded processor chip on it, also referred to as

The silicon manufacturer of the wafers containing chips with a

The process of populating persistent memory (EEPROM) with data

The process of allocating persistent memory (EEPROM) for

Issuer Identification Number (IIN)

The Issuer unique Identifier as defined in ISO 7812. For banks

Copyright 2003 GlobalPlatform Inc. All Rights Reserved.

GlobalPlatform Key Management System Functional Requirements

An interpretative programming language used for developing