Today, the cell phone is the most widespread electronic device in the hands of the population of our planet. The number of cell phones in the world is more than 2.5 times the number of Internet users and about 3 times the number of television devices.
In addition, a cell phone is a general purpose networked (mobile) computing device. It has its own processor, memory, display, keyboard, and supports a variety of communications (various variations of the GSM / UMTS protocols, as well as Wi-Fi, IrDA, Bluetooth and others). The phone may contain other microcircuits (SIM / UICC-card, memory card and other SE (Secure Elements)) that use the phone's capabilities to perform various useful functions.
The computing and communication capabilities of the telephone, clearly superior to those of the modern microprocessor card, led to the idea of using the telephone as a payment card. Due to the presence of a keyboard and a display, the phone adds an element of interactivity and visualization to the properties of a conventional plastic card (choosing an application / service, entering the details required to make a payment, displaying the results of the operation, logos and brands of issuers / payment systems, etc.). The client's phone can be used as a universal electronic wallet for storing applications from various issuers and even different payment systems, which is convenient for the client. Finally, when using the phone as a payment card, the issuer of the application has the ability to remotely control its application,
The idea of using the phone as a payment card acquired concrete meaning in connection with the emergence and spread of NFC (Near Field Communication) technology. NFC technology is formalized within the ISO 18092 standard (ECMA 340, NFCIP-1), which describes a protocol for interaction between two devices via a radio interface. The main characteristics of the NFC protocol are shown below.
The protocol allows two devices, located at a distance of no more than 10 cm from each other, to exchange data via the radio interface using the same carrier with a frequency of 13.56 MHz ± 7 KHz as in the case of the ISO 14443 protocol discussed above. speeds of 106 Kbps, 212 Kbps and 424 Kbps. Higher data rates are available as an option (eg 848 Kbps).
When transferring data at a speed of 106 Kbps, the already familiar ISO 14443 Type A protocol is used. At higher data rates, the FeliCa protocol, developed by Sony specialists, is used. In the forward and reverse channels of the FeliCa protocol, 10% amplitude modulation is used, and the Manchester code is used to encode the information bits. The subcarrier is not used for modulating the signal on the reverse channel. In fig. 7.12 shows the appearance of signals in the forward and reverse channels of the FeliCa protocol.
For the certification of radio devices for compliance with the ISO 18092 standard, the ISO 10373-6 protocol has been developed.
A distinctive feature of the FeliCa protocol is the existence of a symmetric mode of interaction between two radio devices. When using this mode, both devices are sources of magnetic
Rice. 7.12. Appearance of signals in the forward and reverse channels of the FeliCa protocol
Chapter?. CONTACTLESS CARDS of the 549th field (or they say, are active) and therefore can initiate a data exchange dialogue, and also do not need the magnetic field of the second participant in the dialogue if necessary to transfer their data to him. Therefore, when using a symmetric mode, after the completion of data transmission, the active device turns off the generation of its magnetic field and begins to work only to receive information.
The NFC protocol as a means of communication is increasingly used in cell phones, PDAs, laptops, digital cameras. According to the latest forecasts from ABI Research, the critical mass of phones (half a billion devices) that support the NFC standard will be reached by 2012.
The key issue for converting an NFC cell phone into a plastic card is where the payment application should be stored on the phone. The obvious contender for the custodian of the payment application is the SIM / UICC card. Of course, the application can be stored on other secure elements of the card (for example, a memory card). However, not all phones have such elements. In addition, the variety of SE elements and how they are used in the phone makes this choice more difficult to implement and therefore less attractive.
In this regard, the largest association of cellular operators GSMA (GSM Association), which has more than 700 mobile operators in its ranks, adopted the so-called SIM-centric model, in accordance with which the central role (the role of the application guardian) when using NFC for secure applications SIM / UICC card must play. In addition, the model assumes the presence of a separate NFC chip on the card, which plays the role of a communication processor (establishes an NFC connection with an external device) and supports the SWP / HCI interface between the SIM / UICC card and the NFC chip, as well as the HCI interface with all other safe elements of the phone.
The SWP (Single Wire Protocol, ETSI TS 102 613) standard was approved by the ETSI (European Telecommunications Standards Institute) in October 2007. It defines the OSI physical and link layer protocols for high-speed full-duplex connections using the C6 (ISO 7816) SIM / UICC cards. The standard was created on the basis of the HDLC standard (ISO 13239), which describes the link layer protocol (used in the X.25 protocol).
The HCI protocol (Host Controller Interface, ETSI TS 102 622) was approved by ETSI at the end of February 2008. It is a transport layer protocol between the various SE elements of the phone and the NFC chip. The approval of the ETSITS 102 622 standard has raised a storm of passion in the community of cellular operators and handset manufacturers. This was due to the fact that the standard allows you to organize the interaction of external systems with the SE elements of the phone in such a way that, as a result of communication for downloading data to the SE, they are under the control of the SIM card. This state of affairs did not suit some phone manufacturers who wanted to download their own software to the phone without the control of the cellular operator.
As a result of the emergence of the SWP and HCI standards, all technical issues related to the implementation of NFC on the phone were considered resolved. Now, from a technical point of view, everything is ready to start mass production of NFC devices.
Obviously, the issuer of the SIM / UICC card is a mobile operator (Mobile Network Operator, or MNO). Therefore, when using the SIM-centric model, a conflict immediately arises between cellular operators and issuers of applications of other service providers. Indeed, it is usually the cellular operators that manage the content of the SIM / UICC card. Obviously, for security reasons, this state of affairs does not suit issuers of other applications (for example, banks). Banks want to be sure that the payment application loaded on the SIM / UICC card was not modified during the download process, was correctly installed, activated, or, conversely, was removed during the download. It also raises the question of the confidentiality and integrity of the app personalization data.
In this regard, the GSMA, meeting the needs of the banking community, adopted the GSMA Pay-Bye-Mobile initiative, according to which a new member appears in the NFC infrastructure designed for using a cell phone to implement secure applications - Trusted Service Manager (TSM) ...
The following players (managers) participate in the NFC ecosystem:
The variation in technical functions of TSM is great. To the maximum extent, TSM functions include key management, download, installation, uninstallation, personalization of service provider applications, quality control of services provided by the cellular operator.
To perform the functions of secure content management of a SIM / UICC card, the use of the previously discussed GlobalPlatform platform is most suitable (see section 2.7). Today, it is recommended to use the GlobalPlatform Card Specification v.2.2 and GlobalPlatform UICC Configuration v.1.0 to implement SIM / UICC card content management. The latest specification provides guidance for the implementation of the GlobalPlatform Card Specification v.2.2 in the field of mobile communications and for 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 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).
The GlobalPlatform Confidential Card Content Management - Card Specification v.2.2 - Amendment A v.1.0 provides standard mechanisms for card content management, including:
The first clarification has to do with the addition of a Controlling Authority role with two functions:
The second addition relates to the introduction of the SSD Manager role, which provides the Supplementary Security Domain (SSD) channel management function and the security domain key storage function. The SSD Manager role cannot be played by the card issuer.
Remote downloading of data to a SIM / UICC card is traditionally performed using the widespread OTA (Over-the-Air) technology defined in the GSM 03.48 / 3GPP TS 23.048 standards. In these standards, data download security is implemented at the level of SMS packets, which provide transport between the data source host and the SIM / UICC card. Within GlobalPlatform, data security is ensured at the APDU level. There are a number of discrepancies between the GSM 03.48 / 3GPP TS 23.048 and GlobalPlatform standards. To address these discrepancies, the GlobalPlatform consortium has updated the GSM 03.48 / 3GPP TS 23.048 specifications and as a result, the ETSI TS 102.225 (OTA Security) and ETSI TS 102.226 (OTA Management) standards have emerged. Based on the ETSI TS 102.225 standard, within the GlobalPlatform, a secure data transmission channel SCP80 has been defined.
Another kind of secure channel that can be supported by a security domain is SCP02. The protocol underlying this channel was described by us earlier in section 2.7. This channel is used to transmit data over a contact interface, and can also be encapsulated in an SCP80 channel to transmit data over a contactless interface.
As defined in the GlobalPlatform UICC Configuration v.1.0 specification, each Application Provider Security Domain (APSD) and TSM Security Domain is capable of supporting either SCP80, SCP02, or both.
To implement the function of secure loading of initial keys into security domains in accordance with Chapter 11 “Confidential Setup of Initial Secure Channel Keys” of the GlobalPlatform UICC Configuration v.1.0 specification, the keys and certificates of the CASD domain must be loaded onto the SIM / UICC card at the stage of card production ( by Card Manufacture). The responsibility of the Controlling Authority role is so high that the manager who implements it, for example, SKEA, must be a trusted third party for the manager whose OTA platform is used to download data (most often for MNOs and TSMs) and the manager responsible for personalization. applications (most often for TSM and SP). Indeed, knowing the initial keys of the security domains, the SKEA manager is able to control the card content management performed through these domains. CKLA functions can be performed by a card manufacturer or a well-known key certification authority. The reputation responsibility of these companies determines their existence, and therefore they enjoy the necessary trust in the market.
There are the following models of SIM / UICC-card content management:
Simple Mode model. Scenario 1:
The main elements of this model are shown in Fig. 7.13. In the figure, SM (Simple Mode), APSD denotes a service provider's security domain that does not manage the content of the card. The figure shows that the content management of the card in this case is implemented by the ISD (Issuer Security Domain) domain. The ISD loads and installs the SM APSD application on the card. Further, after downloading the initial domain keys to SM APSD by SKEA, the service provider application is downloaded and installed via ISD. When registering an application with the Card Registry, the ISD domain indicates that the personalization of the service provider application (receiving and processing APDU scripts) is done by the SM APSD domain. As a result, all commands of personalization scripts in accordance with GlobalPlatform Messaging will be sent to the service provider application.
Entity owning the UICC SD hierarchy
Rice. 7.13. Basic elements of the Simple Mode model. Scenario 1
MN0
Application loading and personalization
Personalization data is loaded into the application using the SCP02 'MNO OTA-domain SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel established between the OTA MNO and ISD. This ensures the confidentiality of the data loaded into the application (the keys of the SCP02 channel are not known to the card issuer) for the card issuer. At the same time, the card issuer has complete control over the content management of the SIM / UICC card.
Simple Mode model. Scenario 2:
Entity owning the
SD keys
Authority
UICC SD hierarchy
TSM
SSernicer
Provider
Rice. 7.14. Basic elements of the Simple Mode model. Scenario 2
Application loading
Application personalization
OTA Link uploads the initial keys of these security domains to SM TSD and SM APSD by SKEA, the service provider application is downloaded and installed via ISD. When registering an application in the Card Registry, the ISD domain indicates that the application is personalized (receiving and processing APDU scripts) by the SM APSD domain. As a result, all personalization script commands in accordance with GlobalPlatform Messaging will be sent to the service provider application using the SCP02 channel of the APSD SM domain.
Personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel established between the OTA MNO and the TSD SM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to TSM) for the card issuer is ensured. At the same time, the card issuer continues to fully control the content management of the SIM / UICC card.
Delegated Mode model. Scenario 1:
MNO
OTA Link
SSernicer
Provider
UICC SD hierarchy
MNO
TSM
CKL Authority
TSM
OTA Lir
Management Token
Application loading and personalization
-DI
Rice. 7.15. The main elements of the Delegated Mode model. Scenario 1
the SM APSD application) and SM APSD using CKLA of the initial keys of these security domains, the service provider application is downloaded and installed via DM TSD. When registering an application in the Card Registry, the DM TSD domain indicates that the application is personalized (receiving and processing APDU scripts) by either the DM TSD domain or the SM APSD domain. As a result, all personalization script commands in accordance with GlobalPlatform Messaging will be sent to the service provider application using the SCP80 channel of the DM TSD domain or the SCP02 channel of the APSD SM domain.
When personalizing the application through the SM APSD domain, the personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel organized between the OTA TSM and the TSD DM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to TSM) for the card issuer is ensured. At the same time, the card issuer continues to fully control the content management of the SIM / UICC card.
Delegated Mode model. Scenario 2 (the application is personalized by the service provider):
Entity owning the SD keys
MN0
OTA Lil
MNO
CKL Authority
SSernicer
Provider
UICC SD hierarchy
TSM
OTA Lir
Management Token
Application loading and personalization
Rice. 7.16. The main elements of the Delegated Mode model. Scenario 2
service provider application. When registering an application in the Card Registry, the DM TSD domain indicates that the application is personalized (receiving and processing APDU scripts) by the SM APSD domain. As a result, all personalization script commands in accordance with GlobalPlatform Messaging will be sent to the service provider application using the SCP02 channel of the APSD SM domain.
When personalizing the application through the SM APSD domain, the personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel organized between the OTA TSM and the TSD DM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to the SP) is ensured for the card issuer and TSM. At the same time, TSM continues to control the content management of the SIM / UICC card in terms of service providers.
Authorization Mode model. Scenario 1:
Entity owning the
UICC SD hierarchy
MNO
OTA Link
Application loading and personalization
Rice. 7.17. The main elements of the Authorization Mode model. Scenario 1
personalization of the service provider application (receiving and processing APDU scripts) is performed either by the AM TSD domain or by the SM APSD domain. As a result, all personalization script commands in accordance with GlobalPlatform Messaging will be sent to the service provider application using the SCP80 channel of the AM TSD domain or the SCP02 channel of the APSD SM domain.
When personalizing an application through the SM APSD domain, the personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel organized between the OTA TSM and the TSD AM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to TSM) for the card issuer is ensured. At the same time, the card issuer continues to fully control the content management of the SIM / UICC card.
Authorization Mode model. Scenario 2 (the application is personalized by the service provider):
• The service provider delegates the management of its TSM application. This delegation covers APSD domain creation and application loading.
Entity owning the
SD keys
TSM
SSernicer
Provider
UICC SD hierarchy
MNO OTA Link
Application loading and personalization
Rice. 7.18. The main elements of the Authorization Mode model. Scenario 2
GlobalPlatform Messaging will be routed to the service provider application using the SCP02 channel of the APSD SM domain.
When personalizing an application through the SM APSD domain, the personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel organized between the OTA TSM and the TSD AM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to the SP) is ensured for the card issuer and TSM. At the same time, TSM continues to control the content management of the SIM / UICC card in terms of service providers.
In addition, a cell phone is a general purpose networked (mobile) computing device. It has its own processor, memory, display, keyboard, and supports a variety of communications (various variations of the GSM / UMTS protocols, as well as Wi-Fi, IrDA, Bluetooth and others). The phone may contain other microcircuits (SIM / UICC-card, memory card and other SE (Secure Elements)) that use the phone's capabilities to perform various useful functions.
The computing and communication capabilities of the telephone, clearly superior to those of the modern microprocessor card, led to the idea of using the telephone as a payment card. Due to the presence of a keyboard and a display, the phone adds an element of interactivity and visualization to the properties of a conventional plastic card (choosing an application / service, entering the details required to make a payment, displaying the results of the operation, logos and brands of issuers / payment systems, etc.). The client's phone can be used as a universal electronic wallet for storing applications from various issuers and even different payment systems, which is convenient for the client. Finally, when using the phone as a payment card, the issuer of the application has the ability to remotely control its application,
The idea of using the phone as a payment card acquired concrete meaning in connection with the emergence and spread of NFC (Near Field Communication) technology. NFC technology is formalized within the ISO 18092 standard (ECMA 340, NFCIP-1), which describes a protocol for interaction between two devices via a radio interface. The main characteristics of the NFC protocol are shown below.
The protocol allows two devices, located at a distance of no more than 10 cm from each other, to exchange data via the radio interface using the same carrier with a frequency of 13.56 MHz ± 7 KHz as in the case of the ISO 14443 protocol discussed above. speeds of 106 Kbps, 212 Kbps and 424 Kbps. Higher data rates are available as an option (eg 848 Kbps).
When transferring data at a speed of 106 Kbps, the already familiar ISO 14443 Type A protocol is used. At higher data rates, the FeliCa protocol, developed by Sony specialists, is used. In the forward and reverse channels of the FeliCa protocol, 10% amplitude modulation is used, and the Manchester code is used to encode the information bits. The subcarrier is not used for modulating the signal on the reverse channel. In fig. 7.12 shows the appearance of signals in the forward and reverse channels of the FeliCa protocol.
For the certification of radio devices for compliance with the ISO 18092 standard, the ISO 10373-6 protocol has been developed.
A distinctive feature of the FeliCa protocol is the existence of a symmetric mode of interaction between two radio devices. When using this mode, both devices are sources of magnetic
Rice. 7.12. Appearance of signals in the forward and reverse channels of the FeliCa protocol
Chapter?. CONTACTLESS CARDS of the 549th field (or they say, are active) and therefore can initiate a data exchange dialogue, and also do not need the magnetic field of the second participant in the dialogue if necessary to transfer their data to him. Therefore, when using a symmetric mode, after the completion of data transmission, the active device turns off the generation of its magnetic field and begins to work only to receive information.
The NFC protocol as a means of communication is increasingly used in cell phones, PDAs, laptops, digital cameras. According to the latest forecasts from ABI Research, the critical mass of phones (half a billion devices) that support the NFC standard will be reached by 2012.
The key issue for converting an NFC cell phone into a plastic card is where the payment application should be stored on the phone. The obvious contender for the custodian of the payment application is the SIM / UICC card. Of course, the application can be stored on other secure elements of the card (for example, a memory card). However, not all phones have such elements. In addition, the variety of SE elements and how they are used in the phone makes this choice more difficult to implement and therefore less attractive.
In this regard, the largest association of cellular operators GSMA (GSM Association), which has more than 700 mobile operators in its ranks, adopted the so-called SIM-centric model, in accordance with which the central role (the role of the application guardian) when using NFC for secure applications SIM / UICC card must play. In addition, the model assumes the presence of a separate NFC chip on the card, which plays the role of a communication processor (establishes an NFC connection with an external device) and supports the SWP / HCI interface between the SIM / UICC card and the NFC chip, as well as the HCI interface with all other safe elements of the phone.
The SWP (Single Wire Protocol, ETSI TS 102 613) standard was approved by the ETSI (European Telecommunications Standards Institute) in October 2007. It defines the OSI physical and link layer protocols for high-speed full-duplex connections using the C6 (ISO 7816) SIM / UICC cards. The standard was created on the basis of the HDLC standard (ISO 13239), which describes the link layer protocol (used in the X.25 protocol).
The HCI protocol (Host Controller Interface, ETSI TS 102 622) was approved by ETSI at the end of February 2008. It is a transport layer protocol between the various SE elements of the phone and the NFC chip. The approval of the ETSITS 102 622 standard has raised a storm of passion in the community of cellular operators and handset manufacturers. This was due to the fact that the standard allows you to organize the interaction of external systems with the SE elements of the phone in such a way that, as a result of communication for downloading data to the SE, they are under the control of the SIM card. This state of affairs did not suit some phone manufacturers who wanted to download their own software to the phone without the control of the cellular operator.
As a result of the emergence of the SWP and HCI standards, all technical issues related to the implementation of NFC on the phone were considered resolved. Now, from a technical point of view, everything is ready to start mass production of NFC devices.
Obviously, the issuer of the SIM / UICC card is a mobile operator (Mobile Network Operator, or MNO). Therefore, when using the SIM-centric model, a conflict immediately arises between cellular operators and issuers of applications of other service providers. Indeed, it is usually the cellular operators that manage the content of the SIM / UICC card. Obviously, for security reasons, this state of affairs does not suit issuers of other applications (for example, banks). Banks want to be sure that the payment application loaded on the SIM / UICC card was not modified during the download process, was correctly installed, activated, or, conversely, was removed during the download. It also raises the question of the confidentiality and integrity of the app personalization data.
In this regard, the GSMA, meeting the needs of the banking community, adopted the GSMA Pay-Bye-Mobile initiative, according to which a new member appears in the NFC infrastructure designed for using a cell phone to implement secure applications - Trusted Service Manager (TSM) ...
The following players (managers) participate in the NFC ecosystem:
- mobile operators (MNO);
- service providers (Service Provider, or SP), for example, banks, transport companies, merchants, etc .;
- trusted representative of TSM service providers;
- Confidential Key Loading Authority (CKLA) - the authority responsible for loading the initialization keys of some privileged applications onto the SIM / UICC-card.
The variation in technical functions of TSM is great. To the maximum extent, TSM functions include key management, download, installation, uninstallation, personalization of service provider applications, quality control of services provided by the cellular operator.
To perform the functions of secure content management of a SIM / UICC card, the use of the previously discussed GlobalPlatform platform is most suitable (see section 2.7). Today, it is recommended to use the GlobalPlatform Card Specification v.2.2 and GlobalPlatform UICC Configuration v.1.0 to implement SIM / UICC card content management. The latest specification provides guidance for the implementation of the GlobalPlatform Card Specification v.2.2 in the field of mobile communications and for 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 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).
The GlobalPlatform Confidential Card Content Management - Card Specification v.2.2 - Amendment A v.1.0 provides standard mechanisms for card content management, including:
- - secure loading of the initial keys of the security domain by a third party;
- - secure download of application code;
- - secure transmission of scripts of APDU commands to a certain security domain for the purpose of personalizing the application associated with this domain, or managing the content of the card.
The first clarification has to do with the addition of a Controlling Authority role with two functions:
- - domain control Controlling Authority Security Domain (CASD), which provides secure loading of the initial keys of the card's security domains;
- - control of a special security domain that performs the function of mandatory verification of the signature of the downloaded Mandated DAP application code.
The second addition relates to the introduction of the SSD Manager role, which provides the Supplementary Security Domain (SSD) channel management function and the security domain key storage function. The SSD Manager role cannot be played by the card issuer.
Remote downloading of data to a SIM / UICC card is traditionally performed using the widespread OTA (Over-the-Air) technology defined in the GSM 03.48 / 3GPP TS 23.048 standards. In these standards, data download security is implemented at the level of SMS packets, which provide transport between the data source host and the SIM / UICC card. Within GlobalPlatform, data security is ensured at the APDU level. There are a number of discrepancies between the GSM 03.48 / 3GPP TS 23.048 and GlobalPlatform standards. To address these discrepancies, the GlobalPlatform consortium has updated the GSM 03.48 / 3GPP TS 23.048 specifications and as a result, the ETSI TS 102.225 (OTA Security) and ETSI TS 102.226 (OTA Management) standards have emerged. Based on the ETSI TS 102.225 standard, within the GlobalPlatform, a secure data transmission channel SCP80 has been defined.
Another kind of secure channel that can be supported by a security domain is SCP02. The protocol underlying this channel was described by us earlier in section 2.7. This channel is used to transmit data over a contact interface, and can also be encapsulated in an SCP80 channel to transmit data over a contactless interface.
As defined in the GlobalPlatform UICC Configuration v.1.0 specification, each Application Provider Security Domain (APSD) and TSM Security Domain is capable of supporting either SCP80, SCP02, or both.
To implement the function of secure loading of initial keys into security domains in accordance with Chapter 11 “Confidential Setup of Initial Secure Channel Keys” of the GlobalPlatform UICC Configuration v.1.0 specification, the keys and certificates of the CASD domain must be loaded onto the SIM / UICC card at the stage of card production ( by Card Manufacture). The responsibility of the Controlling Authority role is so high that the manager who implements it, for example, SKEA, must be a trusted third party for the manager whose OTA platform is used to download data (most often for MNOs and TSMs) and the manager responsible for personalization. applications (most often for TSM and SP). Indeed, knowing the initial keys of the security domains, the SKEA manager is able to control the card content management performed through these domains. CKLA functions can be performed by a card manufacturer or a well-known key certification authority. The reputation responsibility of these companies determines their existence, and therefore they enjoy the necessary trust in the market.
There are the following models of SIM / UICC-card content management:
- - Simple Mode: the content of the SIM / UICC card is managed using the mobile operator's OTA platform (OTA MNO) and the cellular operator's (card issuer's) security domain. In this case, the personalization of downloaded applications can be performed by TSM through the TSM OTA platform.
- - Delegated Mode: management of the content of the SIM / UICC-card is transferred by the cellular operator through the pre-authorization procedure to the TSD domain - the TSM security domain.
- - Authorized Mode: SIM / UICC-card content management is completely transferred by the TSM cellular operator inside the SIM / UICC-card memory area allocated by the cellular operator.
Simple Mode model. Scenario 1:
- The service provider delegates all management functions of its TSM application. This delegation covers creating the APSD domain, downloading the application, and personalizing it.
- TSM uses the OTA MNO platform to create an APSD domain, download and personalize a service provider application.
The main elements of this model are shown in Fig. 7.13. In the figure, SM (Simple Mode), APSD denotes a service provider's security domain that does not manage the content of the card. The figure shows that the content management of the card in this case is implemented by the ISD (Issuer Security Domain) domain. The ISD loads and installs the SM APSD application on the card. Further, after downloading the initial domain keys to SM APSD by SKEA, the service provider application is downloaded and installed via ISD. When registering an application with the Card Registry, the ISD domain indicates that the personalization of the service provider application (receiving and processing APDU scripts) is done by the SM APSD domain. As a result, all commands of personalization scripts in accordance with GlobalPlatform Messaging will be sent to the service provider application.
Entity owning the UICC SD hierarchy
Rice. 7.13. Basic elements of the Simple Mode model. Scenario 1
MN0
Application loading and personalization
Personalization data is loaded into the application using the SCP02 'MNO OTA-domain SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel established between the OTA MNO and ISD. This ensures the confidentiality of the data loaded into the application (the keys of the SCP02 channel are not known to the card issuer) for the card issuer. At the same time, the card issuer has complete control over the content management of the SIM / UICC card.
Simple Mode model. Scenario 2:
- The service provider delegates all management functions of its TSM application. This delegation covers creating the APSD domain, downloading the application, and personalizing it.
- TSM uses the OTA MNO platform to create APSD and download the application. To personalize the application, TSM uses its own OTA TSM platform.
- APSD domain keys are generated and revoked by TSM in the manner described in Chapter 11 “Confidential Setup of Initial Secure Channel Keys” of the GlobalPlatform UICC Configuration v.1.0 specification.
Entity owning the
SD keys
Authority
UICC SD hierarchy
TSM
SSernicer
Provider
Rice. 7.14. Basic elements of the Simple Mode model. Scenario 2
Application loading
Application personalization
OTA Link uploads the initial keys of these security domains to SM TSD and SM APSD by SKEA, the service provider application is downloaded and installed via ISD. When registering an application in the Card Registry, the ISD domain indicates that the application is personalized (receiving and processing APDU scripts) by the SM APSD domain. As a result, all personalization script commands in accordance with GlobalPlatform Messaging will be sent to the service provider application using the SCP02 channel of the APSD SM domain.
Personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel established between the OTA MNO and the TSD SM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to TSM) for the card issuer is ensured. At the same time, the card issuer continues to fully control the content management of the SIM / UICC card.
Delegated Mode model. Scenario 1:
- The service provider delegates all management functions of its TSM application. This delegation covers creating the APSD domain, downloading the application, and personalizing it.
- TSM uses its own MNO TSM platform to create APSD, download and personalize the application in Delegated Management mode defined by the GlobalPlatform. In accordance with this mode, for each content management procedure (download, installation, extradition, uninstallation of the application) TSM pre-receives from the MNO special digital tokens, which represent the signature of the card issuer, verified by TSD prior to the execution of the listed procedures.
- APSD domain keys are generated and revoked by TSM in the manner described in Chapter 11 “Confidential Setup of Initial Secure Channel Keys” of the GlobalPlatform UICC Configuration v.1.0 specification.
MNO
OTA Link
SSernicer
Provider
UICC SD hierarchy
MNO
TSM
CKL Authority
TSM
OTA Lir
Management Token
Application loading and personalization
-DI
Rice. 7.15. The main elements of the Delegated Mode model. Scenario 1
the SM APSD application) and SM APSD using CKLA of the initial keys of these security domains, the service provider application is downloaded and installed via DM TSD. When registering an application in the Card Registry, the DM TSD domain indicates that the application is personalized (receiving and processing APDU scripts) by either the DM TSD domain or the SM APSD domain. As a result, all personalization script commands in accordance with GlobalPlatform Messaging will be sent to the service provider application using the SCP80 channel of the DM TSD domain or the SCP02 channel of the APSD SM domain.
When personalizing the application through the SM APSD domain, the personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel organized between the OTA TSM and the TSD DM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to TSM) for the card issuer is ensured. At the same time, the card issuer continues to fully control the content management of the SIM / UICC card.
Delegated Mode model. Scenario 2 (the application is personalized by the service provider):
- The service provider delegates the management of its TSM application. This delegation covers APSD domain creation and application loading.
- TSM uses its own MNO TSM platform to create APSD, load and personalize the application in Delegated Management mode defined by the GlobalPlatform, as described above.
- APSD domain keys are generated and revoked by the SP in the manner described in Chapter 11 “Confidential Setup of Initial Secure Channel Keys” of the GlobalPlatform UICC Configuration v.1.0 specification.
- The service provider prepares personalization scripts for uploading them to the card via the OTA TSM platform.
Entity owning the SD keys
MN0
OTA Lil
MNO
CKL Authority
SSernicer
Provider
UICC SD hierarchy
TSM
OTA Lir
Management Token
Application loading and personalization
Rice. 7.16. The main elements of the Delegated Mode model. Scenario 2
service provider application. When registering an application in the Card Registry, the DM TSD domain indicates that the application is personalized (receiving and processing APDU scripts) by the SM APSD domain. As a result, all personalization script commands in accordance with GlobalPlatform Messaging will be sent to the service provider application using the SCP02 channel of the APSD SM domain.
When personalizing the application through the SM APSD domain, the personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel organized between the OTA TSM and the TSD DM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to the SP) is ensured for the card issuer and TSM. At the same time, TSM continues to control the content management of the SIM / UICC card in terms of service providers.
Authorization Mode model. Scenario 1:
- The service provider delegates all management functions of its TSM application. This delegation covers creating the APSD domain, downloading the application, and personalizing it.
- TSM uses its own MNO TSM platform to create APSD, download and personalize the application in a mode where the authorization of the cellular operator (card issuer) may be required if a specific area of the card memory is allocated by the card issuer for applications downloaded through TSD.
- APSD domain keys are generated and revoked by TSM in the manner described in Chapter 11 “Confidential Setup of Initial Secure Channel Keys” of the GlobalPlatform UICC Configuration v.1.0 specification.
Entity owning the
UICC SD hierarchy
MNO
OTA Link
Application loading and personalization
Rice. 7.17. The main elements of the Authorization Mode model. Scenario 1
personalization of the service provider application (receiving and processing APDU scripts) is performed either by the AM TSD domain or by the SM APSD domain. As a result, all personalization script commands in accordance with GlobalPlatform Messaging will be sent to the service provider application using the SCP80 channel of the AM TSD domain or the SCP02 channel of the APSD SM domain.
When personalizing an application through the SM APSD domain, the personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel organized between the OTA TSM and the TSD AM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to TSM) for the card issuer is ensured. At the same time, the card issuer continues to fully control the content management of the SIM / UICC card.
Authorization Mode model. Scenario 2 (the application is personalized by the service provider):
• The service provider delegates the management of its TSM application. This delegation covers APSD domain creation and application loading.
- TSM uses its proprietary MNO TSM platform to create APSDs, download and personalize applications in the issuer's designated memory area of the card.
- APSD domain keys are generated and revoked by the SP in the manner described in Chapter 11 “Confidential Setup of Initial Secure Channel Keys” of the GlobalPlatform UICC Configuration v.1.0 specification.
- The service provider prepares personalization scripts for uploading them to the card via the OTA TSM platform.
Entity owning the
SD keys
| ? | MNO |
| CKL Authority |
TSM
SSernicer
Provider
UICC SD hierarchy
MNO OTA Link
Application loading and personalization
Rice. 7.18. The main elements of the Authorization Mode model. Scenario 2
GlobalPlatform Messaging will be routed to the service provider application using the SCP02 channel of the APSD SM domain.
When personalizing an application through the SM APSD domain, the personalization data is loaded into the application using the SCP02 'MNO TSM-SM APSD' channel, the data packets of which are encapsulated in the SCP80 channel organized between the OTA TSM and the TSD AM. Thus, the confidentiality of the data loaded into the application (the keys of the SCP02 channel are known only to the SP) is ensured for the card issuer and TSM. At the same time, TSM continues to control the content management of the SIM / UICC card in terms of service providers.
