kms functional reqs v1 0

7/23/2019 KMS Functional Reqs v1 0

1/64

GlobalPlatform Key Management System

Functional Requirements

1.0

November 2003


2/64

GlobalPlatform Key Management System Functional Requirements Page 2

Table of Contents

1. DOCUMENT OVERVIEW...................................................................................................... 7

1.1 INTRODUCTION ................................................................................................................ 71.2 SCOPE .............................................................................................................................. 71.3 PURPOSE OF THIS DOCUMENT .......................................................................................... 81.4 INTENDED AUDIENCE....................................................................................................... 81.5 VERSION INFORMATION................................................................................................... 81.6 REFERENCES AND APPLICABLE DOCUMENTS .................................................................. 9

1.7 TERMINOLOGY............................................................................................................... 102. 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 ......................................................................... 183.2 REQUIREMENTS FOR HSM............................................................................................. 183.3 REQUIREMENT FOR ACCESS AND AUDIT ....................................................................... 19

3.4 REQUIREMENTS FOR SUPPORTING CRYPTOGRAPHIC ALGORITHMS AND THEIR MODES193.5 REQUIREMENTS FOR KEY PROFILE................................................................................ 203.6 REQUIREMENTS FOR KEY GENERATION........................................................................ 20

3.6.1 [ R-20 ] TDEA:...................................................................................................... 203.6.2 [ R-21 ] RSA:......................................................................................................... 21

3.7 REQUIREMENTS FOR KEY REVOCATION........................................................................ 213.8 REQUIREMENTS FOR STORING KEYS ............................................................................. 213.9 REQUIREMENTS FOR KEY EXCHANGING ....................................................................... 22

3.9.1 General Principle for Exchanging Keys................................................................ 223.9.2 Exchanging Key Profiles ....................................................................................... 223.9.3 Exchanging TDEA keys ......................................................................................... 233.9.4 Exchanging RSA keys ............................................................................................ 24

3.10 REQUIREMENTS FOR IMPORTING AND EXPORTING KEYS.............................................. 243.11 REQUIREMENTS FOR KEY SEPARATION......................................................................... 243.12 REQUIREMENTS FOR THE DATE CHECKING................................................................... 243.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............................................................................................... 27A.1.2 GLOBALPLATFORM KEY MANAGEMENT SYSTEM OVERVIEW .................................. 27A.1.3 GPCARD KMSVERSUS APPLICATION KMS............................................................. 28

A 1 3 1 Key Management System Keys 28


3/64


A.1.5 APPLICATION KMSKEYS .......................................................................................... 38

A.2. FUNCTIONAL REQUIREMENTS TO SUPPORT A GLOBALPLATFORM CARD40

A.2.1 FUNCTIONAL REQUIREMENTS ................................................................................... 40A.2.1.1 Overall requirements for a KMS ........................................................................... 40A.2.1.2 Requirements for HSM.......................................................................................... 40A.2.1.3 Requirement for Access and Audit......................................................................... 40A.2.1.4 Requirements for Supporting Cryptographic Algorithms...................................... 40A.2.1.5 Requirements for Key Profile ................................................................................ 41A.2.1.6 Requirements for Key Generation ......................................................................... 41A.2.1.7 Requirements for Storing Keys .............................................................................. 41

A.2.1.8 Requirements for Key Exchanging ........................................................................ 42A.2.1.9 Requirements for Importing and Exporting Keys.................................................. 46A.2.1.10 Requirements for Key Separation...................................................................... 46A.2.1.11 Requirements for Date Checking....................................................................... 46A.2.1.12 Requirements for Expiration and Deletion........................................................ 46A.2.1.13 Requirements for Key Derivation...................................................................... 46A.2.1.14 Transport of Application Secret Data ............................................................... 46A.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............................................................................................... 49B.1.2 ACTORS ROLES AND RESPONSIBILITIES .................................................................... 49B.1.3 EMVAPPLICATION KEYS .......................................................................................... 50B.1.4 EMVAPPLICATION RELATED INFORMATION ........................................................... 51B.1.5 PROCESSES................................................................................................................. 52

B.1.5.1 RSA Data ............................................................................................................... 52B.1.5.2 TDEA Data ............................................................................................................ 52

B.2. FUNCTIONAL REQUIREMENTS TO SUPPORT AN EMV APPLICATION .......... 54

B.2.1 EMVCASE STUDY .................................................................................................... 54B.2.2 FUNCTIONAL REQUIREMENTS ................................................................................... 54

B.2.2.1 Overall Requirements for a KMS .......................................................................... 55B.2.2.2 Requirements for HSM.......................................................................................... 55B.2.2.3 Requirement for Access and Audit......................................................................... 55B.2.2.4 Requirements for Supporting Cryptographic Algorithms...................................... 55B.2.2.5 Requirements for Key Profile ................................................................................ 56B.2.2.6 Requirements for Key Generation ......................................................................... 56B.2.2.7 Requirements for Storing Keys .............................................................................. 57B.2.2.8 Requirements for Key Exchanging ........................................................................ 57B.2.2.9 Requirements for Importing and Exporting Keys.................................................. 62


4/64


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


5/64


Table of Tables

Table 1: Definitions .......................................................................................................13

Table 2: Naming convention for Keys...........................................................................30


6/64


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


7/64


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. Manyentities 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 supplementarySecurity 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

t ti ll d d t d i thi


8/64


1.3 Purpose of this document

The intention of GlobalPlatform KMS Functional Requirements is to serve as inputto 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 CardManagement Systems, smart cards and the GlobalPlatform specifications.

1.5 Version information

Version Date Comments

1.0 November 2003


9/64


1.6 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 25th1999

FIPS PUB 81: DES modes of Operation, December 2nd1980


10/64


1.7 Terminology

Term Definitions

AppletRepresentation of a chip application software and/or data. In thisdocument, 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 ManagementSystem (KMS)

The Application Key Management System provides applicationrelated key management on behalf of the Application Provider.

Application Loader

The Application Loader loads Card Issuer specific cards withapplications and / or personalization / customization data accordingto the instructions of the Application Provider, while complying withthe security policies of the Card Issuer.

Application Provider

The Application Provider procures the necessary components toload a complete application on to a card (i.e., application code,application data, application keys and/or certificates, and databelonging to a specific cardholder). The Application Provider has adirect business relationship with the cardholder and provides a card-based service to that cardholder.

Asymmetric Cryptography

A cryptographic technique commonly referred to as Public Key.This technique uses two related transformations, a publictransformation (defined by the public key component) and the

private transformation (defined by the private key component). Thetwo key components have a property that, given the public key, it iscomputationally not feasible to discover the private key.

Card Enabler / InitializerThe entity that prepares the platform for subsequent applicationloading.

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 ManagerThe Issuers on-card control mechanism for a GlobalPlatform chip-card.


11/64


Term Definitions

DAP Block

First part of the Load File used for ensuring Load File Data Block

verification.

Data PreparationThe process of gathering and preparing the necessary applicationdata and keys for input into the personalization device.

DecryptionThe reversal of the corresponding encryption, reversibletransformation of a cryptogram by cryptographic algorithm to retrievethe original plain text data.

Delegated ManagementAllows an Application Provider to load and install an application on acard, with the Card Issuer still retaining control over the content ofthe card.

Digital SignatureAn asymmetric transformation of data intended to prove to the datarecipient the origin and integrity of the data.

EncryptionThe reversible transformation of data by cryptographic algorithm toproduce a cryptogram.

GP Card KMS An instance of a GlobalPlatform Key Management System thatsupport the required functionality for use with a GP Card.

HSM

The HSM is a tamper-resistant device that provides thecryptographic facilities necessary for functions such assecuring application data generation, personalization and applicationloading.

Within this document the term HSM is used to indicate therequirement for a Hardware cryptographic device suitable for the

necessary operation.

ICCA card with an embedded processor chip on it, also referred to assmart card and chip card.

IC ManufacturerThe silicon manufacturer of the wafers containing chips with aspecified ROM configuration.

Initialization

The process of populating persistent memory (EEPROM) with datathat is common to a large number of cards while also including a

minimal amount of card unique items (e.g. ICC serial number andPersonalization keys).

(Application) Install

The process of allocating persistent memory (EEPROM) forapplication data and populating persistent memory with specific set-up data. For a Java Card, an instance of the applet is created andapplet objects are instantiated.


12/64


Term Definitions

Java

An interpretative programming language used for developing

applications targeted to Java Card chip-cards.

KeyA set of attributes that defines a component of cryptographicoperations. Attributes include the items like value, usage, key checkvalue, owner, name, expiration date, etc..

Key Value

A Key Value is an optional attribute of a Key Profile that contains thebits used to control a cryptographic operation.

The term Key Value is used in preference to key to ensuredistinction between a Key Value and a Key Profile.

A Key Value would normally be paired with other Key Profileattributes such as a Key Check Value.

Key Profile

A representation of attributes that are used to describe parametersof a particular key or type

A Key Profile may or may not contain all its attributes, such as KeyValue, a Key Profile not containing a Key Value could be used todescribe and the usage of a key type rather than a specific instanceof cryptographic key value.

Key Check Value (KCV)

An integrity value associated with a cryptographic key.

For DES/TDEA key value and DES/TDEA key component KCV shallbe the result, or partial result, of the encryption of eight bytes ofbinary zeroes.

Key Encrypting Key (KEK) Key used to encrypt another key.

LiveA Key Profile may be marked as Live or Test, a Key Profile markedas Live should be treated as a data that has been used during thecreation of real applications/cards.

(Application) LoadThe process of populating persistent memory (EEPROM) withapplication 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 thirdparties.

Object Identifier (OID)

A number that uniquely identifies an object class or attribute. Anobject identifier is represented as a dotted decimal string, such as1.2.3.4. Object identifiers are organized into a global hierarchy.National registration authorities issue root object identifiers toi di id l i ti h th hi h b l th i


13/64


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 afterthe card has been issued to the cardholder. This process requiresestablishing a secure channel between the Application Load Serverand the chip-card.

Private Key

The private (secret) component of an asymmetric key pair. Its owneralways keeps the private key in secret. The private key may be usedto decrypt messages that are encrypted using the corresponding

public key. It may also be used to digitally sign messages forauthentication purposes.

Public Key

The public component of an asymmetric key pair. The public key isusually publicly exposed and available to users. A certificate toprove its origin often accompanies it. The public key may be used toencrypt messages intended for the owner of its correspondingprivate key. It may also be used to verify a message digital signatureto authenticate the message sender.

Secure Channel A communication mechanism between an off-card entity and a cardthat provides a level of assurance, to one or both entities.

Security Domain

A specific system application on the card that represents a specificApplication Provider. The Security Domain holds encryption andsignature keys that are used to verify the integrity and authenticity ofits Application Providers applications.

Smart cardA card with an embedded processor chip on it, also referred to asICC and chip card.

Smart Card Management System(SCMS)

The infrastructure required to support a multi-application program. Itincludes, but is not limited to, card program set up, card andapplication life cycle management, issuance and re-issuanceprocesses and the management of the card life cycle and businessrules between applications.

Symmetric Cryptography

A cryptographic technique that uses the same secret key for boththe originators and the recipients transformation. Withoutknowledge of the secret key, it is computationally not feasible to

compute either the originators or the recipients transformation.

TestA Key Profile may be marked as Live or Test, a Key Profile markedas Test should be treated as a data that has been used during thecreation of test applications/cards.

Transport Key (TK) Key used for transporting secret information between two entities.


14/64


the requirement is recommended. Where the term may is used the requirement is

optional.


15/64


2. Overview of Key Management Systems

The minimum functionality of a KMS is to logically maintain a key's set ofattributes, 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 thepopular 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.

KeyA

KeyB

Attributes

Key Profile1 Key Profile2

Attributes

Attributes

Key Profile3

Attributes

Key Profile5

Key Profile4

Key Profile6

Key Profile7a Key Profile7b

Key Profile7c

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

Figure 2-1 : Relationship between Key Values, Attributes and Key Profiles


16/64


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 Profile1created using Attributes, and Key Profile2using Attributes

Key Profile3based on Key Profile1when KeyAloaded, and Key Profile4using

Attributes

Key Profile5based on Key Profile1when KeyBloaded, and Key Profile6using

Attributes

Key Profiles7a7ccreated using Attributesand KeyBsplit 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 Profile1or Key Profile2,

which would provide the final usage attributes of the combined key. Attributeswill

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. PartyAis the owner of the

Key and use the key for Encryption, PartyBhave received the key from PartyAand

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 Valuebut will contain different attributes.


17/64


2.1 What is a KMS

A Key Management System is a system to securely generate, store, distribute anddelete 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 ManagementSystem. 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.


18/64


3. General Key Management System

RequirementsIn 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


19/64


[ 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-2level 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 Algorithmsand 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


20/64


3.5 Requirements for Key Profile

[ R-13 ] The KMS shall support a standard structure representing the attributes ofa 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 forcryptographic 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 adifferent 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


21/64


[ 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 theyare 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


22/64


[ 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 informationabout 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 KeyValue 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 authentication1between the twoentities. [ 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 theinformation relating to the Profile used for a specific Key Value.


23/64


[ R-29b ] The exchange of Key Values between KMSs shall utilize KeyProfiles.

[ 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 theGlobalPlatform 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, (wherem


24/64


3.9.4 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 senderand 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 Valueimport/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 ] Th KMS h ll hibit th f K V l t id th K P fil


25/64


3.13 Requirements for Expiration and Deletion

[ R-39 ]The KMS shall support and use processes to have a Key Profile expired,

archived and deleted.


26/64


Appendix A GlobalPlatform Card

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

applied.

Gl b lPl f K M S F i l R i P


27/64


A.1. About GlobalPlatform Key ManagementSystems

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 ofapplication 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.

Gl b lPl tf K M t S t F ti l R i t P 28


28/64


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 theapplications.

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 CardIssuers 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.



29/64


RSA keys used by the GP Card KMS for Delegated Management and/or DAP-

verification

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, S-

MAC, 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

ADKENCCard unique Security Domain Key Value derived from AMK used

for encrypting the commands to and from ICC during Post-issuance

ADKDEKCard unique Security Domain Key Value derived from AMK used

for encrypting Application Key Values during Post-issuance

ADKMACCard unique Security Domain Key Value derived from AMK used

for MACing the commands to and from ICC during Post-Issuance

AMKApplication 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

CDKDEKCard unique Issuer Key Value derived from CMK used for

encrypting Application Key Values during Post issuance

CDKENCCard 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 MACingthe 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



30/64


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

ISKInitial Supplier Key Value ensures that the Card Enabler can

only process on ICC to which he is entitled

KDCDEKCard unique Initial Card Manager Key Value derived from KMC

used for encrypting Application Key Values during personalization

KDCENC

Card unique Initial Card Manager Key Value derived from KMC

used for encrypting the commands to and from ICC during

personalization

KDCMAC

Card unique Initial Card Manager Key Value derived from KMC

used for MACing the commands to and from ICC during

initialization and personalization

KDDDEKCard unique Initial Security Domain Key Value derived from KMD

used for encrypting Application Key Values during Personalization

KDDENC

Card unique Initial Security Domain Key Value derived from KMD

used for encrypting the commands to and from ICC during

Personalization

KDDMAC

Card unique Initial Security Domain Key Value derived from KMD

used for MACing the commands to and from ICC during

Initialization and Personalization

KMCInitial Issuer Master Key Value used by the Card Issuer to

control the initialization and personalization of each ICC

KMDInitial Application Provider Master Key Value controls a non

Card Manager Security Domain as KMC does for Card Manager

TKTransport Key Value established for secure exchange of Key Values

between any two entities

Table 2: Naming convention for Keys



31/64


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 playsmore 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 for the naming and definition of the

key types.

Table 2: Naming convention for Keys

IC

Manufacturer

CardManufacturer

Card Enabler

Application

Loader

IC with

ISK

Issuer ICC with

KDC

GP Card

KMS

(Issuer

Security

Domain)

KMC

KMC

TK(CDK)

Application

KMS

TK'(Application keys)

Produces IC

Install ISK

Enables ICC for an Issuer (IIN)

Installs KDC by knowledge of ISK

ICC with

ISK

Embeds IC in Card= ICCInstall/Load Card Manager

Leaves ISK unmodified

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

M S it D i it tili it S it D i

Has responsibility for

the Issuer Security

Domain = the overall

Security of the ICC

Manufacturer

KMS

ISK

ISK

TK

TK'

ISK



32/64

f y g y q g

Note 1: The impact to the Key Management Systems when an Application Provider

uses a Supplementary Security Domain will be outlined in detail in sectionA.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 theIssuers 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



33/64

A.1.3.4.1 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 sametrust-model as the GP Card KMS either being the same organization or under

control of a mutual agreed trust-model.

Card Enabler

Application

Loader

Issuer ICC with

KDC

GP Card

KMS

(Issuer

Security

Domain)

KMC

KMC

TK(CDK)

Application

KMS


TK

TK'

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



34/64

GP Card

KMS

(Supplementary

Security

Domain)

KMD

KMD

TK(ADK)


Application

KMS

Card Enabler

Application

Loader

Issuer ICC with

KDC

GP Card

KMS

(Issuer

Security

Domain)

KMC

KMC

TK(CDK)

Application

KMS


TK

TK' TK'

TK

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 trust-model. 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.



35/64

ICC with KDC,

KDD and DAP key

DAP Private orDES Secret Key

DAP Public or

DES Secret Key

DAP Signature

GP Card

KMS

(Supplementary

Security

Domain)

KMD

KMD

TK(ADK)


ApplicationKMS

Card Enabler

Application

Loader

GP Card

KMS

(Issuer

Security

Domain)

KMC

KMC

TK(CDK)

ApplicationKMS


TK

TK' TK'

TK

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.



36/64

ICC with KDC,

KDD and DAP key

Token

DAP Private or

DES Secret Key

Note 1

DAP Public or

DES Secret Key

Note 1

GP Card

KMS

(Supplementary

Security

Domain)

KMD

KMD

TK(ADK)


Application

KMS

Card Enabler

Application

Loader

GP Card

KMS

(Issuer

Security

Domain)

KMC

KMC

TK(CDK)

Application

KMS


TK

TK' TK'

TK

DAP

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.

Th GP C d KMS i i b id h T K V l d f



37/64

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.

MAC Key(KDCmac);

Encryption Key(KDCenc);

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.

MAC Key(CDKmac)

Encryption Key(CDKenc)

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 IPKTOKENsecret Key Value will be

stored within the GP Card KMS used to generate tokens. The IPKTOKENpublicKey Value will be sent to the card enabler for placing on the card. The

detailed token format is defined in theGlobalPlatform Card

Specification2.1.



38/64

MAC Key(KDDmac)

Encryption Key(KDDenc)

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.

MAC Key(ADKmac)

Encryption Key(ADKenc)

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 Specification2.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



39/64

Secret data such as PIN

Confidential data

Each type of secret or confidential information shall be treated differently as to the

nature of its type.



40/64

A.2. Functional Requirements to Support aGlobalPlatform 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 Requirementssection 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 inthe 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 R i t f S ti C t hi Al ith



41/64

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:



42/64

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 General Principle for Exchanging Keys

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 fora 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 D l d M d/ DAP ifi i i d



43/64

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. Thisinformation 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;




44/64

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 bothsender 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;

Indicator for whether the Key Value is a test or a live key;

Key Check Value making it possible to verify that the Key Value after

installation has the same value at both sender and receiver;

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

h ll b h d d i T K d i i



45/64

ID of the specific Key Value uniquely identifying the Key Value to both


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

installation has the same value at both sender and receiver;

A unique identification to both sender and receiver of the Transport Key

used for encrypting the exchanged Key Value during transport.

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 associatedinformation.

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

the Key Value. This shall at least encompass:



46/64

Generation date;

Effective date;

Expiration date;


Key Check Value making it possible to verify that Key Value after

installation has the same value at both sender and receiver.

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 SeparationThe 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

Th GP C d KMS h ll t th d d f t f t ti t



47/64

MACing using the methods defined in the GlobalPlatform Card specification

2.1, appendix B

Signature-generation with RSA-keys as defined in GlobalPlatform CardSpecification 2.1, when Delegated Management or DAP verification are

required.

SHA-1 Secure Hashing Algorithm 1



48/64

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.



49/64

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 CertificationAuthority (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 usedto 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



50/64

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

o Issuer Master Keys (IMKs):

Application Cryptogram (IMKAC)

Secure Messaging Integrity (IMKMAC)

Secure Messaging Confidentiality (IMKENC)

o

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

o Issuer:

Issuer Keyset

Issuer Public Key Certificate

o ICC


PIN E i h t K (PEK)


51/64

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)

o 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

o ICC

Dynamic Data Authentication (DDA):

DDA Public Key Remainder

PIN Encipherment Key (PEK):

PEK P bli K R i d


B 1 5 P


52/64

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 PublicKey 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 DataThe 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


Once the MKs have been generated it is the responsibility of the Issuer to provide


53/64

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.


B 2 Functional Requirements to Support an EMV


54/64

B.2. Functional Requirements to Support an EMVApplication

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:

K V l ti


In addition to the common requirements of the General and GP Card KMS the


55/64

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 beused 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:


B.2.2.5 Requirements for Key Profile


56/64

q y

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 GenerationThe 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 PseudoRandom 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 R-

20c. The primality test can be statistical or deliver absolute proof. If it

t ti ti l it h ld b b d i d i lit t t l ith


B.2.2.7 Requirements for Storing Keys


57/64

q g y

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 General Principle for Exchanging Keys

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 tha

kms functional reqs v1 0

Documents