GlobalPlatform Card Security Requirements Specification

GlobalPlatform
In the late 1990s, VISA developed a set of VISA OpenPlatform (VOP) standards that defined how applications can be remotely managed on the card, terminal, and systems related to downloading, installing, deleting, and personalization of applications.
It soon became clear that in order for the VOP platform to be widely distributed, it had to be as open as possible. As a result, the VOP specifications were transferred by VISA to the OpenPlatform consortium, consisting of a number of organizations that expressed interest in the VOP specifications. Since then, the platform has been called OpenPlatform. However, in 1999, the platform and its supporting consortium were renamed GlobalPlatform.
Today, the GlobalPlatform consortium is an open, independent, non-profit organization responsible for developing and distributing the GlobalPlatform platform of The same name, as well as microprocessor card technologies in General. GlobalPlatform members include the largest payment systems VISA International, MasterCard Worldwide, JCB Co.Ltd, as well as major card manufacturers (Gemalto, Oberthur Card Systems, Giesecke & Devrient, Sagem Orga), microprocessors (NXP Semiconductors, Renesas, STMicroelectronics, Hitachi Ltd, Infineon Technologies, Toshiba Corporation, Fujitsu), computers and system software (Sun Microsystems, IBM), equipment for card personalization (Datacard) and other Companies.
The latest version of the GlobalPlatform 2.2 specification can be obtained for free on The website www.globalplatform.org. To date, it should be recognized that the GlobalPlatform technology is the most popular for managing multi-layer cards. According to various data, by the end of 2007, more than 195 million cards supporting the GlobalPlatform platform were circulating in the world, and more than 1.4 billion GSM cards used It for remote (over-the-air, or OTA) downloading of data and applications. The GlobalPlatform de facto platform is becoming the standard for remote secure download and management of microprocessor card applications. As an example, the ETSI GSM 03.19 standard, which defines the loading of applications on GSM cards, is completely based on the use of GlobalPlatform. Another example is the recently released GlobalPlatform UICC Specification V. 1.0, which provides guidance on implementing the GlobalPlatform Card Specification V. 2.2 in mobile communications and managing the secure delivery of new services. It defines each participant in the SIM/UICC card implementation process describes the roles and responsibilities of each player for various business models of card implementation.
The GlobalPlatform consortium has been focusing on platform security issues since its inception. The GlobalPlatform standard is supplemented by the GlobalPlatform Common Criteria Security Target Guidelines and GlobalPlatform Card Security Requirements Specification documents. The first document defines a methodology for evaluating the security of a card that supports the GlobalPlatform platform, based on the widely used Common Criteria approach (ISO 15408). The second document not only gathers together all the security requirements of the GlobalPlatform platform formulated in GPCS, but also defines the requirements for the Run-Time Environment of the card, its operating system and chip. This document is a guide to determining the card configuration that best meets the security policies set by the card Issuer and card application providers. The specification also provides a guide to risk management: it identifies possible risks, offers security policies that minimize the risks identified, and defines card configurations that match the security policies reviewed.
Below, we will focus on the GlobalPlatform platform in the projection of its use in microprocessor cards. A card that supports the GlobalPlatform platform will be called a GP card in the future.

GlobalPlatform Architecture
The GlobalPlatform Card Specification (GPCS) defines secure dynamic procedures for managing card and card applications, as well as card components, command sets and execution sequences, and security mechanisms used in application management procedures for multi-layer microprocessor cards. Application management procedures allow you to remotely download, install, and delete applications.
The description of GPCS is based on the concept of Run-Time Environment (RTE). RTE usually consists of a native card operating system, a virtual machine (VM, Virtual Machine), and an application programming interface (API, Application Programming Interface), which defines a set of structures and functions that are used when programming user applications and ensure proper interaction between the application and the card operating system.
Examples of well-known RTE components include the corresponding Java card components: Java Card VM and Java Card API.
The key concept of GlobalPlatform is security domains. Security domains are privileged card applications that represent the card Issuer and some external application providers (Application Provider). Security domains are able to establish secure data exchange channels with the appropriate application providers, which uses the secret keys stored on the card, as well as manage the card content (procedures for downloading, installing, extraditing, and deleting card applications). GP-card applications can be associated with certain security domains, as well as use their services. On the contrary, a security domain can receive information from an associated application. In this way, the app provider can interact with its app on the card through the appropriate security domain.
There are three main types of security domains:
security domain of the Issuer (Issuer Security Domain). Among the application providers, there is the most privileged one, called the card Issuer. The domain of the Issuer Security Domain is a mandatory detail of the GP-card, representing its Issuer on it. The Issuer Security Domain has the privilege to download, install, extradite, and delete any card application;
additional security domain Supplementary Security Domain (SSD). Intended for use by application providers other than the card Issuer;
domain Controlling Authority Security Domain (a special type of Supplementary Security Domain). It can be used (if present on the card and has the Required DAP Verification privilege) to check the source and integrity of all software modules loaded on the card, as well as the initial keys of SSD domains.

The Central element of the GP card architecture is the Card Manager, which is the main representative of the Issuer on the GP card. In the current version of GlobalPlatform Card Manager, it consists of the following components:
GlobalPlatform Environment (OPEN);
Issuer Security Domain;
services for verification of card holder (Cardholder Verification Methods).
The GlobalPlatform Environment (OPEN) performs the most important functions of the GlobalPlatform platform, including:
providing card applications with an open API application programming interface. In fact, for the Java card, the OPEN environment is an extension of the Java Card API, designed to implement functions for managing card applications;
performing the application selection procedure;
distribution of incoming commands to the card by card application;
logical channel management (optional);
support for card Content Management, i.e. downloading, installing, extraditing, and deleting applications;
managing APDU commands.
The GP card architecture is shown in figure 2.17.
All card communications with the outside world are organized through the OPEN environment. Commands (APDU blocks) first end up in the OPEN environment, which distributes them to the card applications they are intended for (for example, other applications or security domains).
In addition, OPEN performs various card content management procedures (for example, application code verification). The card content is defined below as the aggregate of the file container (Executable Load File), which consists of executable application modules (Executable Module), and its descriptive file (Application Information), which defines the container’s file management parameters for RTE (for example, requirements for installing executable modules on the card).
The OPEN environment also performs a number of card security functions by controlling access to the card, applications, and card security domains.
To perform all the functions listed above, the OPEN environment has access to the corresponding card information: life cycles

GP card architecture

cards, card applications and security domains, security domain privileges, card memory allocation, and so on. This information is stored in the Card Registry. The GPCs specification does not define mechanisms for managing and storing information in Card Registry. You only need to change the contents of the Card Registry for the card Issuer, the OPEN environment, or an authorized application. In this case, the main administrator and owner of the Card Registry is OPEN.
Another component of Card Manager is the security domain of the Issuer Security Domain. As mentioned earlier, the Issuer Security Domain is responsible for managing the card content and organizing a secure channel between the card and the external system during the process of personalization of the card and execution of its applications. This domain has the privilege to download, install, extradite, and delete any card application, regardless of who is the provider of this application.
Finally, the third component of Card Manager is the holder verification services. It provides verification of the cardholder. Here, the most common service is Global PIN, which is available to applications that have the corresponding privilege. The individual services of verification of the cardholder can be in different States (locked available). The services have strict mechanisms for controlling the situations in which they can be used.

The GPCs specification defines the stages of the GP card lifecycle. According to GPCS, the GP card may be in one of the following States.
The OP_READY state determines that the Issuer Security Domain system application is installed on the card, is able to communicate with the outside world using APDU commands, and is ready to work as the selected application. The RTE environment is ready to work, the applets in the card’s ROM are available, and the initialization keys required for interaction between the Issuer and the card are loaded.
The INITIALIZED state. The definition of this state is beyond the scope of the GPCS specification and may be specified by the card manufacturer, its Issuer, or subject to the terms of implementation of the card. The state allows loading some additional data to the card (for example, keys), but the card can’t be issued to its holder yet. You can only get to the INITIALIZED state from the OP_READY state without being able to go back.
The state SECURED. In this state, all Security Domain domains of the card contain key sets that are necessary for card personalization, including in post-issue mode, i.e. after the card is issued to its holder. You can only get to the SECURED state from the INITIALIZED state without being able to go back.
CARD_LOCKED state. In this state, the card Issuer blocks all applications on the card with the exception of Card Manager. The CARD_ LOCKED state can only be accessed from the SECURED state. In this case, the card can go back to the SECURED state. The transition to the CARD_ LOCKED state can be initiated either by Card Manager or by another application that is privileged to perform this function. Returning to the SECURED state is only possible at the initiative of the Card Manager.
The state was TERMINATED. In this state, all card functions are blocked (the card responds only to the GET DATA command). The transition to the TERMINATED state is possible only by a command from Card Manager or a privileged application.it is irreversible and is used when serious threats to the card’s security are detected, as well as when it expires.
The app can only be downloaded, installed, or deleted if the card is not in the CARD_LOCKED and TERMINATED States.
The GPCS specification defines the stages of the GP card application lifecycle. According to GPCS, the GP card application may be in one of the following States.

The INSTALLED state. The application is associated with one of the security domains, memory is allocated for the application data and for its operation, the application is entered in the card Registry of the card.
SELECT state. In this state, the application is able to accept APDU commands. Sometimes the SELECTED state is combined with the INSTALLED state. The transition to the SELECTABLE state can be initiated either by Card Manager or by the security domain that the application is associated with. The transition is irreversible.
The state of PERSONALIZED. In this state, the application has all the necessary data and keys for normal operation. You can only get to the PERSONALIZED state from the SELECTED state. This transition is initiated by the application itself and is irreversible.
The BLOCKED state. In this state, the app behavior is restricted and determined by the app itself. This state is initiated by the application when an internal or external security threat is detected. The application can get to the BLOCKED state from the SELECTED and PERSONALIZED States. By the application’s decision, it is possible to return it to the state from which it got to the BLOCKED state.
The LOCKED state. In this state, the app is completely disabled. The transition to the LOCKED state is only possible from the BLOCKED state and can only be initiated by Card Manager. At the initiative of Card Manager, the application can be returned to the BLOCKED state.

Management of card content
Managing card content is one of the main functions of the GlobalPlatform platform. This function is critical, because errors in its execution can lead to serious security problems for the card. This function is so important for managing the contents of a multi-layer card that it has also been standardized under ISO 7816-13
“Commands for application management in multi-application environment” regardless of the operating environment of card applications, i.e. not only for GP cards.
Loading card content allows an external system to add an application or application data to the card using its representative on the card (for example, the Application Provider Security Domain or the Issuer Security Domain).

The following provisions are basic for uploading content:
content loading is not allowed when the card is in a blocked state (CARD_LOCKED or TERMINATED);
the Load File loaded to the card consists of a Load File Data Block and, in General, several DAP (Data Authentication Pattern) blocks. Each DAP block contains a Load File Data Block Signature made by one of the application vendors whose software modules are contained in the Load File Data Block. To create a Load File Data Block Signature, use the value Load File Data Block Hash, which is a hash function from the Load File Data Block, and the key of the application provider. The Load File Data Block Signature is then used by the security domains of the respective application providers to authenticate the sources of software modules and ensure the integrity of the uploaded data;
the Load File Data Block contains all the information (application modules and application information description files) that RTE needs to create a card application on the card. Examples of Load File Data Block are Java Card CAP files and Windows for Smart Cards OPL files.
card applications are created from the Load File Data Block as follows. First, based on the received Load File Data Block information, a container called an Executable Load File is created on the card and consists of executable modules for individual applications. Then, during the installation of the Executable Module, its instances (instances, or instances) are created, which are applications of the multi-layer card. The diagram for creating a card application from the Executable Load File is shown in figure 2.18.
You can use two commands to upload content to the card:
the INSTALL [for load] command is a request to download a file and defines the download requirements;
the LOAD command used to transport the Load File to the card’s EEPROM memory.
When receiving the INSTALL [for load command] the OPEN module checks whether the same file was previously uploaded to the card (checks for the ID of the file being uploaded in the Card Registry). If the INSTALL [for load command] specifies the security domain that the file to download is associated with, then OPEN checks whether the specified security domain exists on the card, whether it has the necessary privileges to download the file, and whether the security domain is in a valid state for downloading the file. Finally, if all checks were successful, OPEN extracts the INSTALL [for load] command from the data] the value of Load File Data Block Hash and passes it to the security domain for DAP verification.
Obviously, loading a Load File generally requires multiple LOAD commands. Microprocessor cards usually have a communication buffer for receiving information from the outside of the size of 100-250 bytes. Therefore, to load a Load File of a size such as 2 KB, you will need several LOAD commands. When each new LOAD command is received by the OPEN tools, it checks whether there is free memory needed to store the received information.
After receiving the last LOAD command, the OPEN environment determines whether additional checks of the loaded data are required (DAP verification). To perform DAP verification, the security domain must have a special privilege to do so. In GlobalPlatform, there is a privilege called the Mandated DAP Privilege. Usually, the Issuer Security Domain and the Controlling Authority Security Domain can have this privilege. If a domain with the “Mandated DAP Privilege” exists on the card, all applications uploaded to the card must pass DAP verification.
After loading the card content successfully, the Executable Load File appears in the card’s EEPROM, ready for its installation process. In this case, executable modules are registered in the card Registry of the card. Executable modules can be installed at any time. For example, the Executable Load File can be loaded into ROM memory at the card production stage, and the Executable modules included in it will be installed after the card is issued to its holder.
The file is installed using the INSTALL [for install] command. When this command is received, OPEN checks for memory for installing the application, associates the application with the appropriate security domain, creates instances of the application’s executable module, and makes the necessary entries about installing the application in the Card Registry.
The GlobalPlatform platform supports the Delegated Management Model, which is very useful and widely used in practice. This model allows the card Issuer to provide app providers with the ability to download, install, and delete their apps themselves when the card Issuer delegates these functions to them. In this case, content management is performed by the application provider’s security domain.
In the Delegated Management Model, the Issuer still indirectly retains control over the card content management. This happens in the following way. The app provider pre-agrees with the card Issuer that it will be able to perform certain card content management functions related to its apps. These functions include downloading, installing, extraditing (linking the application to a certain security domain), and deleting the vendor’s application. The Issuer may allow the supplier to perform all of the listed functions, or only some of them. The Issuer’s authorization (preauthorization) is executed by transferring the corresponding digital tokens to the application provider: Load Token, Install Token, Extradition Token, and Delete Token. Each of the listed tokens represents the signature of the card Issuer. The Issuer signs some critical parameters of the application provider’s command that is intended to perform one of the card content management functions. The command must contain the token calculated for it. Successful verification of the token by the security domain is a prerequisite for executing the command.
For example, if you use the Load Token, the latter is passed to the card in the data of the INSTALL [for load] command. In this case, the list of data signed by the Issuer includes the parameters of the INSTALL [for load] command, Executable Load File AID (Application ID), Security Domain AID, Load File Data Block Hash, and other data.
When the OPEN environment receives the INSTALL [for load] command, it checks for the presence of a security domain on the card, whose ID (Security Domain AID) specified in the command,as well as whether the security domain has the Token Verification Privilege. If all checks are successful, OPEN sends the Load Token for verification to the application provider’s security domain. If the Load Token verification failed, the LOAD commands for loading the corresponding Load File Data Block will not be passed to the card, and the application loading process will stop.
After the download is complete, the security domain can optionally generate a Load Receipt for the card Issuer, which is a confirmation of successful app download.
The GlobalPlatform platform behaves similarly when the card performs other card content management functions (installation, extradition, and app deletion).
It should be noted that with the help of token technology, the Issuer can delegate to the security domain not only the functions of managing the card content, but also managing the application lifecycle and updating the Card Registry. For example, after successful verification of the Make Selectable Token, the security domain of the application provider can move the application to the SELECTED state, and after successful verification of the Registry Update Token, it can perform a Card Registry update associated with the application download.
The GlobalPlatform Card Specification V. 2. 2 offers a new business model for managing card content, in which service providers have the ability to fully control the card content in their allocated memory area of the card (the so-called Authorized Mode).

Secure Channel Protocol
To interact with the outside world (for example, to perform card content management procedures), all card security domains are able to establish a secure connection with authorized external systems. The Protocol for organizing and managing a secure connection between a GP card and an external system is defined in GPCS and is called the Secure Channel Protocol (CPS). The Protocol provides:
mutual authentication of the GP card and the external system;
authentication of the source received by the card information (i.e. proof of the fact that the obtained card information comes from an authenticated previously external system), the integrity of the received card information (i.e. proof of the absence of the modification of information) and accuracy of the resulting card sequences of information units (i.e., the proof that the blocks are obtained by card in the same sequence as that sent by an external system);
confidentiality of information received by the card.
Mutual authentication of the GP card and the external system is performed in accordance with the following algorithm.
It is assumed that the external system used the SELECT command to pre-select the card security domain (the security domain is the selected card application). Then the external system sends the initialize UPDATE command to the card, which contains a random host challenge number generated by the external system.
The card generates its own random number card challenge and, using card challenge, host challenge and secret keys stored on the card and shared by the card with an external system, creates session keys to generate cryptograms, ensure the integrity and confidentiality of transmitted data.
The card calculates the cryptogram and responds to the INITIALIZE UPDATE command. The response data contains a cryptogram and a random number of the card challenge card.
The external system checks the cryptogram and generates its own version of the cryptogram, in which the same data (card challenge, host challenge) is signed in a different sequence.
External system authentication is performed using the EXTERNAL AUTHENTICATE command, which contains the cryptogram of the external system in the data field.
The card checks the cryptogram and sends a response to the EXTERNAL AUTHENTICATE command, thus completing the process of mutual authentication of the card and the external system.
The integrity of the data transmitted to the GP card is ensured by using the MAC value (Message Authentication Code) calculated from the data transmitted to the card using session keys generated at the stage of mutual authentication of the card and the external system.

The correct sequence of commands received by the card is ensured by the fact that when calculating the MAC value for the next command, the MAC value calculated for the previous command is used.
Finally, the confidentiality of some sensitive data transmitted to the card is ensured by using the corresponding session key generated during the mutual authentication stage of the card and the external system.
Chapter 5 of this book describes the EMV Card Personalization Specification. This standard actually uses the SCP Protocol specification to establish a secure connection between the personalization machine controller and the card.