GlobalPlatform Key Management System

This article provides an overview of GlobalPlatform (GP) Key Management and includes a proposed architecture for an efficient GP Key Management System (KMS) based on the Cryptomathic - Crypto Key Management System (CKMS). This article is not intended to cover all possible uses of GlobalPlatform, but is meant to provide an overview of how it may well be used in an environment where the chip is personalized centrally, after which it is delivered to the end-user and subsequently updated with new applications from various parties, called Application Providers.

Example

Throughout this article, the following example may serve as a guideline: Consider a mobile Network Operator who supplies their customers with hand-sets containing a GP chip including appropriate, standardized interfaces such as some of the many GP Secure Channel Protocols. Part of the business model in this example is to allow application providers and customers to agree on a peer-to-peer basis for services - assuming the Network Operator authorizes the Application Provider to issue and install an application for the customer that can use a protected application space on the chip, allocated by the Network Operator. It may be useful to think of two or more applications, e.g.

1. a contactless payment application (e.g. EMV-based)

2. a 2FA token application (e.g. OATH-based)

Additionally, it would be common for the Network Operator to install their own applications for all users, say an application which allows the customer to purchase and install ring-tones:

3. Ring-tone application (e.g. DRM-based)

We note that the above applications are likely to use a number of application specific keys which are outside the scope of the so-called GP Card KMS, but rather within the so-called Application KMS. The remainder of this article will focus on keys managed using the GP Card KMS, although the Cryptomathic Key Management System supports both.

GP Domains and GP Card KMS Keys

A practical way of implementing the above example using GlobalPlatform would be for the Network Operator to operate a GP KMS that they would use to personalize the chip.

Step 1: Issuer Security Domain In receiving the handset from the manufacturer along with the ISK (Initial Supplier Key), the chip could be personalized with one single security domain - the so-called Issuer Security Domain (ISD) using the keys derived from the Initial Issuer Master Key (KMC). Under this domain, the Ring-tone application would be personalized and uploaded using the keys derived from the KMD (Initial Application Provider Master Key). Next, a CMK (Issuer Master Key) would be installed, effectively locking the ISD into a state where the Ring-tone application could be used and new Supplementary Security Domains (SSD) initialized later. Following hand-out to the end-user, the end-user would be able to agree with a Payment Scheme Issuer (i.e. a bank) on a contactless application, as in our example above, who would then act as an Application Provider. Caution: be careful not to confuse with the GP term for Issuer used previously! See Figure 1 for a logical representation of the security domains under GP: the blue arrows depict which keys are used to control a given part of the GP chip environment.

Step 2: Supplemental Security Domain(s) The bank makes a request to the Network Operator to create a SSD, which the Network Operator does using commands protected by the keys derived from the CMK. In setting up the security domain, the Network Operator would load a new KMD or AMK, subject to the implementation.

Next, the Network Operator derives the keys necessary for the secure channel, e.g. ADKDEK, ADKENC and ADKMAC (used by the bank for 1. encrypting application keys, 2. application load commands and 3. MAC'ing of commands, respectively) and passes these three derived keys to the bank (if not transferring the AMK itself) using a secure channel agreed in advance between the two parties, as well as transferring them securely to the chip. The process may optionally include inserting the DAP (Data Authentication Pattern) key of the bank, i.e. a public key which can subsequently be used to verify that the bank has signed the code intended to run on the chip. Now the bank is ready to post-personalize the chip with the contactless payment application based on the AMK key derivatives.

Repeat Step 2 for any other application providers, e.g. that of the 2FA application.

Figure 1: The GP chip divided into security domains

CKMS as a GP KMS

The Cryptomathic Key Management System can be used as both a GP Card KMS and a GP Application KMS.

GP KMS In our example above, the Network Operator would operate the main GP Card KMS managing the ISK received from the Integrated Circuit manufacturer as well as any KMC, KMD, CMK and AMK keys. The Application Provider would operate a combined GP Card KMS and GP Application KMS - the prior for deriving or using the ADK keys associated with the allocated SSD on the chip and the latter for managing the contactless payment application, i.e. the EMV Issuer Master Keys, the EMV Issuer Certificate, etc.

Encoding Using ADKs In simple scenarios, the Application Provider might not wish to operate an entire Key Management System, but would rather be interested in a module that could be used to encode the APDU (Application Protocol Data Unit) sets associated with the application in question and prepare the load code using the SSD specific ADKs and optionally the DAP.

Final Observations and Recommendations

Data Authentication Pattern under GlobalPlatform: the DAP key is envisaged to be either a symmetric key or an asymmetric key pair of which the public key is loaded into the SSD and the private key kept secret for signing the application code by the Application Provider. The use of the DAP is optional. If used, we recommend referring to the form described in the GlobalPlatform Card Specifications 2.2, i.e. the form under which the DAP is suggested, simplified into two scenarios - that a hash is applied to the Load File Data Block for ensuring integrity of the data and that a signature is applied to the hash for authenticity of the origin.

HSMs In either scenario we recommend using HSMs (Hardware Security Modules) for managing and using keys and we note that for a number of applications, the use of specially programmed HSMs is a firm requirement.

Unique AMKs We recommend using unique AMKs per card and per SSD to avoid the risk of applications being loaded onto any unintended system.

Secure Operations Finally, we recommend that any GP Card KMS operated by the GP Issuer (in our example, the Network Operator) or the Application Provider (the bank, in our example) to be operated in a secure and controlled environment with system users' roles and responsibilities well defined and enforced using hardware tokens such as operator chip cards.

Figure 2: GP Card Keys Used in the GP Chip Lifecycle Stages (excl. EOL)

For more on centralised and compliant key management with automated distribution to any endpoint, see CKMS product page or the blog post discussing the advantages of centralised key management.