Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
In the late 1990s. VISA developed a set of VISA OpenPlatform (VOP) standards that defined how applications can be remotely managed on a card, terminal, and in systems associated with downloading, installing, uninstalling, and personalizing applications.
It soon became clear that for the widespread distribution of the VOP platform, it had to be as open as possible. As a result, the VOP specifications were handed over to VISA to the OpenPlatform consortium, made up of a number of organizations with an interest in the VOP specifications. From that moment on, the platform became known as OpenPlatform. However, in 1999, the platform, along with the consortium supporting it, was renamed GlobalPlatform.
Today the GlobalPlatform consortium is an open independent non-profit organization responsible for the development and distribution of 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 the largest 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), card personalization equipment (Datacard), and others.
The latest version of the GlobalPlatform 2.2 specification can be obtained free of charge from www.globalplatform.org. Today it should be recognized that the GlobalPlatform technology is the most popular for managing multi-application cards. According to various sources, by the end of 2007, more than 195 million cards supporting the GlobalPlatform platform circulated 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 is de facto becoming the standard for remote secure loading and management of smartcard applications. As an example, the ETSIGSM 03.19 standard, which defines the loading of applications on GSM cards, is entirely based on the use of the GlobalPlatform. Another example is the recently released GlobalPlatform UICC Specification v.1.0, which provides guidance for the implementation of the GlobalPlatform Card Specification v.2.2 in the field of mobile communications and the management of 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 since its inception. The GlobalPlatform Standard is complemented by the GlobalPlatform Common Criteria Security Target Guidelines and the GlobalPlatform Card Security Requirements Specification. The first document defines a methodology for assessing the security of a card supporting the GlobalPlatform, based on the widely used Common Criteria (ISO 15408) approach. The second document not only brings together all the security requirements for the GlobalPlatform as formulated in the GPCS, but also defines the requirements for the card's Run-Time Environment, its operating system and microcircuit. This document provides guidance for determining the configuration of the card that best complies with the security policies, established by the card issuer and the card application providers. The specification also provides guidance on risk management: it identifies potential risks, proposes security policies that minimize identified risks, and defines card configurations consistent with the security policies discussed.
Below we will focus on the GlobalPlatform in terms of its use in microprocessor cards. The card supporting the GlobalPlatform platform will hereinafter be referred to as the GP-card.
2.7.1. 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 their sequence of execution, security mechanisms used in procedures for managing applications of multi-application smart cards. Application management procedures provide the ability to download, install, and uninstall them remotely.
The description of GPCS is based on the concept of Run-Time Environment (RTE). Typically RTE consists of the native operating system of the card, the virtual machine (VM, Virtual Machine) and the application programming interface (API, Application Programming
Interface), which defines a set of structures and functions used in programming custom applications and ensuring the correct interaction between the application and the operating system of the card.
Examples of well-known RTE components include the corresponding Java card components: Java Card VM and Java Card API.
The key GlobalPlatform concept is Security Domains. Security Domains are privileged card applications that represent the card issuer and some external Application Provider. Security domains are able to establish secure communication channels with the respective application providers using the secret keys stored on the card, as well as manage the card content (procedures for loading, installing, extraditing and deleting card applications). GP card applications can associate with certain security domains and use their services. Conversely, a security domain can receive information from an application associated with it. Thus,
There are three main types of security domains:
All communications of the card with the outside world are organized through the OPEN environment. The commands (APDUs) first enter the OPEN environment, which distributes them to the card applications for which they are intended (for example, other applications or security domains).
In addition, OPEN performs various procedures for managing the content of the card (for example, verification of the application code). Everywhere below, the content of the card is understood as a set of the file container (Executable Load File), which consists of executable modules of applications (Executable Module), and its descriptive file (Application Information), which defines the parameters for managing the container files for RTE (for example, the requirements for installation on the card executable modules).
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 of the above functions, the OPEN environment has access to the relevant card information: lifecycles
Rice. 2.17. 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 the Card Registry. Only required to change the contents of the Card Registry by the card issuer, the OPEN environment, or an authorized application. The main administrator and owner of the Card Registry is OPEN.
Another component of Card Manager is the Issuer Security Domain. As noted earlier, the Issuer Security Domain is responsible for managing the content of the card and organizing a secure channel between the card and the external system in the process of personalizing the card and executing its applications. This domain has the privilege of downloading, installing, extraditing and deleting any card application, regardless of who the provider of that application is.
Finally, the third component of Card Manager is holder verification services. It provides verification of the cardholder. The most common here is the Global PIN service, which is available to applications that have the appropriate privilege. Individual cardholder verification services can be in different states (blocked, available). Services have strong controls over the situations in which they can be used.
MasterCard to J
The GPCS specification defines the lifecycle stages of a GP card. According to the GPCS, a GP card can be in one of the following states.
The OP_READY state determines the fact 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. RTE is ready to work, applets in the ROM card are available and the initialization keys required for communication between the issuer and the card are loaded.
INITIALIZED state. The definition of this state is outside the scope of the GPCS specification and can be specified by the card manufacturer, its issuer, or subject to the terms of the card implementation. The state allows some additional data (for example, keys) to be loaded onto the card, but the card cannot yet be issued to its holder. The INITIALIZED state can only be reached from the OP_READY state without the possibility of going back.
SECURED state. In this state, all Security Domains of the card contain the sets of keys required for personalization of the card, including in the post-issuance mode, that is, after the card is issued to its holder. The SECURED state can only be accessed from the INITIALIZED state without the ability to go back.
CARD_LOCKED state. In this state, the card issuer blocks all applications on the card with the exception of the Card Manager. The CARD_LOCKED state can only be entered 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 the Card Manager or by another application privileged to perform this function. Returning to the SECURED state is possible only at the initiative of the Card Manager.
TERMINATED state. In this state, all functions of the card are disabled (the card only responds to the GET DATA command). The transition to the TERMINATED state is possible only at the command of the Card Manager or a privileged application, it is irreversible and is used in case of detection of serious threats to the security of the card, as well as when it expires.
The application can be downloaded, installed, or uninstalled only if the card is not in the CARDJLOCKED and TERMINATED states.
The GPCS specification defines the lifecycle stages of a GP card application. According to the GPCS, a GP card application can be in one of the following states.
The INSTALLED state. The application is associated with one of the security domains, memory is allocated for application data and for its functioning, the application is included in the Card Registry of the card.
SELECTABLE state. In this state, the application is able to receive APDU commands. Sometimes the SELECTABLE state is combined with the INSTALLED state. The transition to the SELECTABLE state can be initiated either by the Card Manager or by the security domain to which the application is associated. The transition is irreversible.
PERSONALIZED state. In this state, the application has all the data and keys necessary for normal functioning. The PERSONALIZED state can only be reached from the SELECTABLE state. This transition is initiated by the application itself and is irreversible.
BLOCKED state. In this state, the behavior of the application is limited and is determined by the application itself. The transition to this state is initiated by the application when it detects an internal or external threat to its security. An application can enter the BLOCKED state from the SELECTABLE and PERSONALIZED states. At the decision of the application, it is possible to return it to the state from which it got into the BLOCKED state.
LOCKED state. In this state, the application is completely inoperable. The transition to the LOCKED state is only possible from the BLOCKED state and can only be initiated by the Card Manager. At the initiative of the Card Manager, it is possible to return the application to the BLOCKED state.
2.7.2. Card content management
Card content management is one of the core functions of the GlobalPlatform. The function is critical because errors in its execution can lead to serious card security problems. The function is so important for managing the content of a multi-application card that it has also been standardized within ISO 7816-13 "Commands for application management in multi-application environment" without regard to the operating environment of the card applications, ie not only for GP cards.
Loading card content allows an external system to add an application or application data to the card through its representative on the card (for example, Application Provider Security Domain or Issuer Security Domain).
The following provisions are basic for content uploading:
Content is loaded onto the card using two commands:
Load File
Mutable Persistent Memory
Rice. 2.18. Scheme of creating applications on a GP-card
If the file is loaded, then OPEN checks whether the specified security domain exists on the card, whether it has the necessary privileges to load the file, and whether the security domain is in a valid state for file loading. Finally, if all checks are successful, OPEN extracts the Load File Data Block Hash from the INSTALL [for load] data and passes it to the security domain for DAP verification.
Obviously, loading a Load File generally requires several LOAD commands. Microprocessor cards usually have a communication buffer for receiving information from the outside in the size of 100-250 bytes. Therefore, to load a Load File with a size of, for example, 2 KB, several LOAD commands are required. Whenever a new LOAD command is received by means of OPEN, a check is performed for the availability of free memory necessary to save the received information.
After receiving the last LOAD command, the OPEN environment determines if additional checks on the loaded data (DAP verification) are required. The security domain must have special privilege to perform DAP verification. There is such a privilege in GlobalPlatform as Mandated DAP Privilege. Typically Issuer Security Domain and Controlling Authority Security Domain can have this privilege. If a domain with the Mandated DAP Privilege exists on the card, then all applications loaded on the card must pass DAP verification.
After the successful completion of loading the content of the card, the Executable Load File appears in the EEPROM of the card, ready for the process of its installation. In this case, the executable modules Executable Module are registered
g an
MasterCard
^? 9
in the Card Registry card. Installation of executable modules can be performed at any time. For example, an Executable Load File can be loaded into ROM at the time of card manufacturing, and its associated Executable Modules will be installed when the card is issued to the card holder.
The file is installed using the INSTALL [for install] command. Upon receipt of this command, OPEN checks for memory to install the application, associates the application with the appropriate security domain, instantiates the application executable, and enters the required application installation records into the Card Registry.
The GlobalPlatform supports a very useful and widely used Delegated Management Model. This model allows the card issuer to provide application providers with the ability to independently download, install, and uninstall their applications when delegated to them by the card issuer. Content management in this case is performed by the security domain of the application provider.
In the Delegated Management Model, the issuer still indirectly retains control over the management of the card's content. It happens in the following way. The application provider pre-negotiates with the card issuer that it will be able to perform some of the card content management functions associated with its applications. These functions include downloading, installing, extracting (binding the application to some security domain), and uninstalling the vendor application. The issuer may allow the supplier to perform all of the listed functions or only some of them. The issuer's permission (pre-authorization) is made by transferring the corresponding digital tokens to the application supplier: Load Token, Install Token, Extradition Token and Delete Token. Each of the listed tokens is a signature of the card issuer. The issuer signs some critical parameters of the application provider command to perform one of the card content management functions. The command must contain the token computed for it. Successful validation of the token by the security domain is a prerequisite for the command to run.
For example, in the case of using 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 the security domain on the card, the Security Domain AID of which is specified in the command, and for the security domain to have the Token Verification Privilege privilege. If all checks are successful, OPEN sends the Load Token to the application provider's security domain for verification. If the Load Token verification fails, LOAD commands to load the corresponding Load File Data Block will not be sent 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 - confirmation of successful application download.
The GlobalPlatform behaves in a similar way when the card performs other card content management functions (installation, extradition, uninstallation of an application).
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 content of the card, but also managing the application life cycle and updating the Card Registry. For example, after successful verification of the Selectable Token token, the security domain of the application provider can put the application in the SELECTABLE state, and after successful verification of the Registry Update Token, it can update the Card Registry associated with loading the application.
The GlobalPlatform Card Specification v.2.2 proposes a new business model for card content management, in which service providers have the ability to fully control the content of the card in the dedicated memory area of the card (the so-called Authorized Mode).
2.7.3. Secure Channel Protocol
To interact with the outside world (for example, in order 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:
It is assumed that the external system has previously selected the card's security domain using the SELECT command (security domain is the selectable card application). Then the external system sends the INITIALIZE UPDATE command to the card, the data of which contains a random number of host challenge generated by the external system.
The card generates its own random number card challenge and, using the card challenge, host challenge and secret keys stored on the card and shared by the card with the external system, creates session keys to generate a cryptogram, 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.
The external system checks the cryptogram and generates its own version of the cryptogram, in which the same data (card challenge, host challenge) are signed in a different sequence.
The external system is authenticated using the EXTERNAL AUTHENTICATE command, in the data field of which the cryptogram of the external system is placed.
The card verifies the cryptogram, sends a response to the EXTERNAL AUTHENTICATE command, thereby 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 using the MAC (Message Authentication Code) value, calculated from the data transmitted to the card using the session keys generated at the stage of mutual authentication of the card and the external system.
The correctness of the 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 at the stage of mutual authentication 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 controller of the personalization machine and the card.
It soon became clear that for the widespread distribution of the VOP platform, it had to be as open as possible. As a result, the VOP specifications were handed over to VISA to the OpenPlatform consortium, made up of a number of organizations with an interest in the VOP specifications. From that moment on, the platform became known as OpenPlatform. However, in 1999, the platform, along with the consortium supporting it, was renamed GlobalPlatform.
Today the GlobalPlatform consortium is an open independent non-profit organization responsible for the development and distribution of 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 the largest 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), card personalization equipment (Datacard), and others.
The latest version of the GlobalPlatform 2.2 specification can be obtained free of charge from www.globalplatform.org. Today it should be recognized that the GlobalPlatform technology is the most popular for managing multi-application cards. According to various sources, by the end of 2007, more than 195 million cards supporting the GlobalPlatform platform circulated 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 is de facto becoming the standard for remote secure loading and management of smartcard applications. As an example, the ETSIGSM 03.19 standard, which defines the loading of applications on GSM cards, is entirely based on the use of the GlobalPlatform. Another example is the recently released GlobalPlatform UICC Specification v.1.0, which provides guidance for the implementation of the GlobalPlatform Card Specification v.2.2 in the field of mobile communications and the management of 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 since its inception. The GlobalPlatform Standard is complemented by the GlobalPlatform Common Criteria Security Target Guidelines and the GlobalPlatform Card Security Requirements Specification. The first document defines a methodology for assessing the security of a card supporting the GlobalPlatform, based on the widely used Common Criteria (ISO 15408) approach. The second document not only brings together all the security requirements for the GlobalPlatform as formulated in the GPCS, but also defines the requirements for the card's Run-Time Environment, its operating system and microcircuit. This document provides guidance for determining the configuration of the card that best complies with the security policies, established by the card issuer and the card application providers. The specification also provides guidance on risk management: it identifies potential risks, proposes security policies that minimize identified risks, and defines card configurations consistent with the security policies discussed.
Below we will focus on the GlobalPlatform in terms of its use in microprocessor cards. The card supporting the GlobalPlatform platform will hereinafter be referred to as the GP-card.
2.7.1. 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 their sequence of execution, security mechanisms used in procedures for managing applications of multi-application smart cards. Application management procedures provide the ability to download, install, and uninstall them remotely.
The description of GPCS is based on the concept of Run-Time Environment (RTE). Typically RTE consists of the native operating system of the card, the virtual machine (VM, Virtual Machine) and the application programming interface (API, Application Programming
Interface), which defines a set of structures and functions used in programming custom applications and ensuring the correct interaction between the application and the operating system of the card.
Examples of well-known RTE components include the corresponding Java card components: Java Card VM and Java Card API.
The key GlobalPlatform concept is Security Domains. Security Domains are privileged card applications that represent the card issuer and some external Application Provider. Security domains are able to establish secure communication channels with the respective application providers using the secret keys stored on the card, as well as manage the card content (procedures for loading, installing, extraditing and deleting card applications). GP card applications can associate with certain security domains and use their services. Conversely, a security domain can receive information from an application associated with it. Thus,
There are three main types of security domains:
- Issuer Security Domain. Among the application providers, there is the most privileged one called the card issuer. Domain Issuer Security Domain is a mandatory requisite of a GP card, representing its issuer on it. The Issuer Security Domain has the privilege of downloading, installing, extraditing and removing any card application;
- Supplementary Security Domain (SSD). Intended for use by application providers other than the card issuer;
- Domain Controlling Authority Security Domain (special type Supplementary Security Domain). It can be used (if present on the card and has the Mandated 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.
- GlobalPlatform Environment (OPEN);
- Issuer Security Domain;
- services for verification of the cardholder (Cardholder Verification Methods).
- providing card applications with an open API application programming interface. In fact, for a Java card, the OPEN environment is an extension of the Java Card API designed to implement functions for managing card applications;
- execution of the application selection procedure;
- distribution of commands arriving on the card by card applications;
- management of logical channels (optional);
- support for card content management (Card Content Management), ie, download, installation, extradition and removal of applications;
- management of APDU-commands.
All communications of the card with the outside world are organized through the OPEN environment. The commands (APDUs) first enter the OPEN environment, which distributes them to the card applications for which they are intended (for example, other applications or security domains).
In addition, OPEN performs various procedures for managing the content of the card (for example, verification of the application code). Everywhere below, the content of the card is understood as a set of the file container (Executable Load File), which consists of executable modules of applications (Executable Module), and its descriptive file (Application Information), which defines the parameters for managing the container files for RTE (for example, the requirements for installation on the card executable modules).
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 of the above functions, the OPEN environment has access to the relevant card information: lifecycles
Rice. 2.17. 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 the Card Registry. Only required to change the contents of the Card Registry by the card issuer, the OPEN environment, or an authorized application. The main administrator and owner of the Card Registry is OPEN.
Another component of Card Manager is the Issuer Security Domain. As noted earlier, the Issuer Security Domain is responsible for managing the content of the card and organizing a secure channel between the card and the external system in the process of personalizing the card and executing its applications. This domain has the privilege of downloading, installing, extraditing and deleting any card application, regardless of who the provider of that application is.
Finally, the third component of Card Manager is holder verification services. It provides verification of the cardholder. The most common here is the Global PIN service, which is available to applications that have the appropriate privilege. Individual cardholder verification services can be in different states (blocked, available). Services have strong controls over the situations in which they can be used.
MasterCard to J
The GPCS specification defines the lifecycle stages of a GP card. According to the GPCS, a GP card can be in one of the following states.
The OP_READY state determines the fact 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. RTE is ready to work, applets in the ROM card are available and the initialization keys required for communication between the issuer and the card are loaded.
INITIALIZED state. The definition of this state is outside the scope of the GPCS specification and can be specified by the card manufacturer, its issuer, or subject to the terms of the card implementation. The state allows some additional data (for example, keys) to be loaded onto the card, but the card cannot yet be issued to its holder. The INITIALIZED state can only be reached from the OP_READY state without the possibility of going back.
SECURED state. In this state, all Security Domains of the card contain the sets of keys required for personalization of the card, including in the post-issuance mode, that is, after the card is issued to its holder. The SECURED state can only be accessed from the INITIALIZED state without the ability to go back.
CARD_LOCKED state. In this state, the card issuer blocks all applications on the card with the exception of the Card Manager. The CARD_LOCKED state can only be entered 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 the Card Manager or by another application privileged to perform this function. Returning to the SECURED state is possible only at the initiative of the Card Manager.
TERMINATED state. In this state, all functions of the card are disabled (the card only responds to the GET DATA command). The transition to the TERMINATED state is possible only at the command of the Card Manager or a privileged application, it is irreversible and is used in case of detection of serious threats to the security of the card, as well as when it expires.
The application can be downloaded, installed, or uninstalled only if the card is not in the CARDJLOCKED and TERMINATED states.
The GPCS specification defines the lifecycle stages of a GP card application. According to the GPCS, a GP card application can be in one of the following states.
The INSTALLED state. The application is associated with one of the security domains, memory is allocated for application data and for its functioning, the application is included in the Card Registry of the card.
SELECTABLE state. In this state, the application is able to receive APDU commands. Sometimes the SELECTABLE state is combined with the INSTALLED state. The transition to the SELECTABLE state can be initiated either by the Card Manager or by the security domain to which the application is associated. The transition is irreversible.
PERSONALIZED state. In this state, the application has all the data and keys necessary for normal functioning. The PERSONALIZED state can only be reached from the SELECTABLE state. This transition is initiated by the application itself and is irreversible.
BLOCKED state. In this state, the behavior of the application is limited and is determined by the application itself. The transition to this state is initiated by the application when it detects an internal or external threat to its security. An application can enter the BLOCKED state from the SELECTABLE and PERSONALIZED states. At the decision of the application, it is possible to return it to the state from which it got into the BLOCKED state.
LOCKED state. In this state, the application is completely inoperable. The transition to the LOCKED state is only possible from the BLOCKED state and can only be initiated by the Card Manager. At the initiative of the Card Manager, it is possible to return the application to the BLOCKED state.
2.7.2. Card content management
Card content management is one of the core functions of the GlobalPlatform. The function is critical because errors in its execution can lead to serious card security problems. The function is so important for managing the content of a multi-application card that it has also been standardized within ISO 7816-13 "Commands for application management in multi-application environment" without regard to the operating environment of the card applications, ie not only for GP cards.
Loading card content allows an external system to add an application or application data to the card through its representative on the card (for example, Application Provider Security Domain or Issuer Security Domain).
The following provisions are basic for content uploading:
- content loading is not allowed when the card is in a locked state (CARD_LOCKED or TERMINATED);
- The Load File file loaded onto the card consists of the Load File Data Block and, in general, several DAP (Data Authentication Pattern) Blocks. Each DAP block contains a Load File Data Block Signature signed by one of the application providers whose program modules are contained in the Load File Data Block. To create the Load File Data Block Signature, the Load File Data Block Hash value, which is a hash function of the Load File Data Block, and the application provider key are used. Load File Data Block Signatures are further used by the security domains of the respective application providers to authenticate the sources of program modules and ensure the integrity of the loaded data;
- Load File Data Block contains all information (application software modules and Application Information files) required by the RTE to create a card application on the card. Examples of Load File Data Blocks are Java Card CAP files and Windows OPL files for Smart Cards.
Content is loaded onto the card using two commands:
- the INSTALL [for load] command is a request to load a file and defines the loading requirements;
- LOAD command used to transport the Load File to the EEPROM of the card.
Load File
Mutable Persistent Memory
Rice. 2.18. Scheme of creating applications on a GP-card
If the file is loaded, then OPEN checks whether the specified security domain exists on the card, whether it has the necessary privileges to load the file, and whether the security domain is in a valid state for file loading. Finally, if all checks are successful, OPEN extracts the Load File Data Block Hash from the INSTALL [for load] data and passes it to the security domain for DAP verification.
Obviously, loading a Load File generally requires several LOAD commands. Microprocessor cards usually have a communication buffer for receiving information from the outside in the size of 100-250 bytes. Therefore, to load a Load File with a size of, for example, 2 KB, several LOAD commands are required. Whenever a new LOAD command is received by means of OPEN, a check is performed for the availability of free memory necessary to save the received information.
After receiving the last LOAD command, the OPEN environment determines if additional checks on the loaded data (DAP verification) are required. The security domain must have special privilege to perform DAP verification. There is such a privilege in GlobalPlatform as Mandated DAP Privilege. Typically Issuer Security Domain and Controlling Authority Security Domain can have this privilege. If a domain with the Mandated DAP Privilege exists on the card, then all applications loaded on the card must pass DAP verification.
After the successful completion of loading the content of the card, the Executable Load File appears in the EEPROM of the card, ready for the process of its installation. In this case, the executable modules Executable Module are registered
g an
MasterCard
^? 9
in the Card Registry card. Installation of executable modules can be performed at any time. For example, an Executable Load File can be loaded into ROM at the time of card manufacturing, and its associated Executable Modules will be installed when the card is issued to the card holder.
The file is installed using the INSTALL [for install] command. Upon receipt of this command, OPEN checks for memory to install the application, associates the application with the appropriate security domain, instantiates the application executable, and enters the required application installation records into the Card Registry.
The GlobalPlatform supports a very useful and widely used Delegated Management Model. This model allows the card issuer to provide application providers with the ability to independently download, install, and uninstall their applications when delegated to them by the card issuer. Content management in this case is performed by the security domain of the application provider.
In the Delegated Management Model, the issuer still indirectly retains control over the management of the card's content. It happens in the following way. The application provider pre-negotiates with the card issuer that it will be able to perform some of the card content management functions associated with its applications. These functions include downloading, installing, extracting (binding the application to some security domain), and uninstalling the vendor application. The issuer may allow the supplier to perform all of the listed functions or only some of them. The issuer's permission (pre-authorization) is made by transferring the corresponding digital tokens to the application supplier: Load Token, Install Token, Extradition Token and Delete Token. Each of the listed tokens is a signature of the card issuer. The issuer signs some critical parameters of the application provider command to perform one of the card content management functions. The command must contain the token computed for it. Successful validation of the token by the security domain is a prerequisite for the command to run.
For example, in the case of using 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 the security domain on the card, the Security Domain AID of which is specified in the command, and for the security domain to have the Token Verification Privilege privilege. If all checks are successful, OPEN sends the Load Token to the application provider's security domain for verification. If the Load Token verification fails, LOAD commands to load the corresponding Load File Data Block will not be sent 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 - confirmation of successful application download.
The GlobalPlatform behaves in a similar way when the card performs other card content management functions (installation, extradition, uninstallation of an application).
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 content of the card, but also managing the application life cycle and updating the Card Registry. For example, after successful verification of the Selectable Token token, the security domain of the application provider can put the application in the SELECTABLE state, and after successful verification of the Registry Update Token, it can update the Card Registry associated with loading the application.
The GlobalPlatform Card Specification v.2.2 proposes a new business model for card content management, in which service providers have the ability to fully control the content of the card in the dedicated memory area of the card (the so-called Authorized Mode).
2.7.3. Secure Channel Protocol
To interact with the outside world (for example, in order 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 of information received by the card (that is, proof of the fact that the information received by the card comes from a previously authenticated external system), the integrity of the information received by the card (that is, proof of the fact that the information has not been modified) and the correctness of the sequence of information blocks received by the card ( that is, proof that the blocks are received by the card in the same sequence as they were sent by the external system);
- confidentiality of information received by the card.
It is assumed that the external system has previously selected the card's security domain using the SELECT command (security domain is the selectable card application). Then the external system sends the INITIALIZE UPDATE command to the card, the data of which contains a random number of host challenge generated by the external system.
The card generates its own random number card challenge and, using the card challenge, host challenge and secret keys stored on the card and shared by the card with the external system, creates session keys to generate a cryptogram, 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.
The external system checks the cryptogram and generates its own version of the cryptogram, in which the same data (card challenge, host challenge) are signed in a different sequence.
The external system is authenticated using the EXTERNAL AUTHENTICATE command, in the data field of which the cryptogram of the external system is placed.
The card verifies the cryptogram, sends a response to the EXTERNAL AUTHENTICATE command, thereby 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 using the MAC (Message Authentication Code) value, calculated from the data transmitted to the card using the session keys generated at the stage of mutual authentication of the card and the external system.
The correctness of the 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 at the stage of mutual authentication 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 controller of the personalization machine and the card.
