JP7202543B2 - eUICC and eUICC provisioning methods - Google Patents

Description

The present invention relates to a technology for provisioning an eUICC (abbreviation for Embedded Universal Integrated Circuit Card) incorporated inside a mobile device having a mobile communication function.

UICCs (abbreviations for Universal Integrated Circuit Cards) installed inside mobile devices with mobile communication functions are owned by mobile network operators (hereinafter referred to as MNOs. MNO stands for Mobile Network Operator). Necessary information is provisioned to use the mobile communication system. A conventional UICC is a card-type medium, and information related to a specific MNO is provisioned at the time of manufacture. It is necessary to replace it with another card-type UICC in which information related to the MNO is provisioned.

If the card-type UICC installed inside the mobile device needs to be replaced in order to change the MNO, the consumer does not obtain the card-type UICC provisioned with information related to the MNO to be changed. There is a problem that the consumer cannot easily change the MNO. Moreover, from the standpoint of the MNO, there is a demerit such as the cost associated with the inventory management of the card-type UICC provisioned with the company's own information.

In order to solve this problem, specifications related to eUICC (abbreviation of embedded UICC), which is an embedded UICC that supports remote provisioning by OTA (abbreviation of Over The Air), have been standardized (for example, non-patent literature 1).

FIG. 10 is a diagram for explaining the architecture of the eUICC 6. The architecture of the eUICC 6 illustrated in FIG. 10 is based on Non-Patent Document 1. Here, the architecture of the eUICC 6 is simply described, and for details of the architecture of the eUICC 6, please refer to documents such as Non-Patent Document 1.

As illustrated in FIG. 10, the eUICC 6 uses ISD-R60 (abbreviation for Issuer Security Domain Root), ECASD 62 (eUICC Controlling Authority Security Domain) and at least one ISD-P61 (Issuer Security Domain Profile) are stored in memory.

ISD-R60 and ECSAD62 are SDs issued to the eUICC 6 when the mobile device is manufactured. The ISD-R60 is an issuer's SD serving as the root of the SD stored in the eUICC 6, and has functions such as generating ISD-P61. The ECSAD 62 has the function of securely generating the encryption key used by the ISD-P 61 generated by the ISD-R 60 . The ISD-P61 is an issuer's SD that stores a profile 610, which is data that collects information for using a mobile communication system operated by an MNO.

Profile 610 stored in ISD-P 61 includes at least MNO SD 611, NAA 614 (abbreviation for Network Access Application), POL1_612 (abbreviation for Policy 1), and file system 613. In FIG. Security Domain) and applications 616 .

Profile MNO-SD 611 has a function of constructing a secure channel with a provisioning system corresponding to MNO-SD 611, a function of generating SSD 615, a function of deleting SSD 615, and the like. POL1_612 includes policy rules indicating permission to invalidate a profile, permission to delete a profile, and the like. NAA 614 is an application for using a mobile communication system, such as the USIM application standardized by ETSI TS 131 102, for example. The file system 613 has contents disclosed in documents such as ETSI TS 102 221.

eUICC 6 can store applications other than NAA 614 . This application can include an application 616 related to services provided by the MNO to consumers (for example, call control), and furthermore, service providers (SPs) that have business alliances with the MNO provide to consumers. An application 616 related to services (eg, M-commerce) may be included. The application 616 related to the SP is stored in the profile while being associated with the SSD 615, which is the SD of the SP that has a business tie-up with the MNO.

In the eUICC 6, multiple profiles 610 are permitted to be stored, but the number of profiles 610 that can be set as valid is limited to one, and the MNO corresponding to the profile 610 set as valid uses the eUICC 6. Become an available MNO. In FIG. 10, the profile 610a is shown with a solid line and the profile 610n with a dashed line, which indicates that the profile 610a is valid and the profile 610n is invalid. In the case of mobile devices for consumers (for example, smart devices), the change of the profile 610 to be valid in the eUICC 6 is performed by the operation of the consumer, and in the case of mobile devices related to IoT (for example, heavy equipment), the instructions of the MNO performed by

In this way, in the eUICC 6 that supports remote provisioning, consumers can change the profile 610, but if the profile 610 is changed, the application 616 included in the profile 610 before the change is also invalidated. Application 616 cannot be carried over to profile 610 after change. In particular, in the case of the application 616 related to the SP, the MNO installs the application 616 and the SP issues the application 616 to generate an instance. The fact that it cannot be handed over to 610 is a factor that makes it difficult for consumers to change MNOs easily.

As an invention that allows the application 616 in the profile 610 before change to be transferred to the profile 610 after change, an invention that enables data related to the application 616 to be transferred from the profile 610 before change to the profile 610 after change is disclosed in Patent Document 1. disclosed in

Japanese Patent Publication No. 2018-503313

Remote Provisioning Architecture for Embedded UICC Technical Specification Version 3.2 27 June 2017

According to Patent Document 1, the SD that performs the process of migrating the data related to the application from the profile before the change to the profile after the change is the ISD-R, but the SD that installs the application is the MNO-SD. ISD-R may perform processing beyond the authority given to the person.

SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to enable an application in a pre-change profile to be used in a post-change profile without migrating application-related data from the pre-change profile to the post-change profile.

The first invention to solve the above-mentioned problems is an operating system having a common area API for setting a common area that can be commonly used by mobile communication carriers in NVM and accessing the common area; a root security domain having a function of managing a profile security domain storing a profile including a user security domain, said root security domain having a function of generating said profile security domain in an NVM area not set in said common area and the mobile communication carrier security domain has a function of installing an application related to the mobile communication carrier in the common area using the common area API eUICC. According to the first invention described above, the common area is not included in the area managed by the root security domain for the profile security domain. Therefore, even if the root security domain invalidates or deletes the profile security domain, the application installed in the common area is not invalidated or deleted, and the application in the pre-change profile can be used in the post-change profile.

Furthermore, the second invention is the eUICC described in the first invention, wherein the profile includes a security domain of a service provider that has a business tie-up with a mobile communication carrier, and the security domain of the service provider is the common area. It is characterized by having a function of writing issued data of the application related to the service provider to the common area by using an API. According to the second invention described above, even if the root security domain invalidates or deletes the profile security domain, the instance of the application installed in the common area is not invalidated or deleted, and the application in the profile before the change is invalidated or deleted. instance is available in the modified profile.

Furthermore, the third invention sets a common area that can be commonly used by mobile communication carriers in NVM, and includes an operating system having a common area API for accessing the common area, and a mobile communication carrier security domain. A method for provisioning an eUICC with a root security domain having a function of managing a profile security domain storing profiles including profiles, wherein the root security domain is configured in an area of NVM not set in the common area to provide the profile security domain. a generating a domain; and b, the mobile operator security domain using the common area API to install an application associated with the mobile operator into the common area. This is an eUICC provisioning method. The effects of the third invention are the same as those of the first invention.

Furthermore, a fourth invention is the eUICC provisioning method described in the third invention, wherein the profile includes a security domain of a service provider that has a business tie-up with a mobile communication carrier, and the security domain of the service provider is It is characterized by including a step c of writing issued data of the application related to the service provider to the common area using the common area API. The effects of the fourth invention are the same as those of the second invention.

In this way, according to the present invention described above, the application in the pre-change profile can be used in the post-change profile without migrating data related to the application from the pre-change profile to the post-change profile.

FIG. 2 is a diagram simply explaining an architecture related to remote provisioning; The schematic block diagram of eUICC. The figure explaining the structure of a profile. FIG. 4 is a diagram for explaining a memory map of NVM that the eUICC has; The figure explaining the installation procedure of a profile. FIG. 4 is a diagram for explaining a memory map of NVM before profile installation; FIG. 4 is a diagram for explaining a memory map of NVM after profile installation; The figure explaining the issuing procedure of an application. FIG. 5 is a diagram for explaining a memory map of NVM after changing the profile; The figure explaining architecture of eUICC.

Embodiments according to the present invention will now be described. This embodiment is intended to facilitate understanding of the present invention, and the present invention is not limited to this embodiment. In addition, unless otherwise specified, the drawings are schematic diagrams drawn to facilitate understanding of the present invention.

FIG. 1 is a diagram simply explaining an architecture 1 related to remote provisioning. The architecture 1 related to remote provisioning illustrated in FIG. (short for Trusted Service Manager).

The mobile device 5 in which the eUICC 2 is incorporated is a device that performs mobile communication. , not only smart devices 5b such as smartphones and smart watches, but also heavy machinery 5c that performs mobile communication of work videos and the like to a predetermined server.

The provisioning system 3 stores a profile 23 that is aggregated data for using a mobile communication system operated by a mobile communication operator (hereinafter referred to as MNO. MNO stands for Mobile Network Operator). It is a system that executes provisioning to write to eUICC2 remotely. The provisioning system 3 illustrated in FIG. 1 includes an MNO-TSM 30 that is an MNO server and an SM (abbreviation for Subscription Manager) corresponding to the MNO, and the SM corresponding to the MNO stores the profile 23 of the MNO. SM-DP 32 (abbreviation for Data Preparation), which is the target of remote provisioning, and SM-SR 31 (abbreviation for Secure Routing) that constructs a secure channel between the eUICC 2 that is the target of remote provisioning.

FIG. 2 is a schematic configuration diagram of the eUICC2. The eUICC 2 has an operating system 20 (hereinafter referred to as OS, which stands for Operating System) that directly operates on the hardware 25 and a security domain (hereinafter referred to as SD) that operates based on the OS 20 . SD is an abbreviation for Security Domain and includes ISD-R21, ECASD24 (abbreviation for eUICC Controlling Authority Security Domain) and at least one ISD-P22. ISD-R21 is an SD functioning as a root security domain according to the present invention, and stands for Issuer Security Domain Root. Also, ISD-P22 is an SD that functions as a profile security domain according to the present invention, and is an abbreviation for Issuer Security Domain Profile.

In the hardware configuration illustrated in FIG. 2, a CPU 250 (abbreviation of Central Processing Unit) is connected to a RAM 252 (abbreviation of Random Access Memory), a ROM 251 (abbreviation of Read Only Memory), and an NVM 26 (abbreviation of Non-volatile memory) via a bus. ), UART 255 (abbreviation of Universal Asynchronous Receiver/Transmitter), timer 254 and accelerator 253 are connected. The RAM 252 is a volatile memory that serves as the main memory of the eUICC 2, and the ROM 251 is an electrically non-rewritable non-volatile memory. The NVM 26 is an electrically rewritable nonvolatile memory. The UART 255 is a circuit for controlling communication with the mobile device 5 in which the eUICC 2 is incorporated, the timer 254 is a circuit for measuring time, and the accelerator 253 is a circuit for increasing the processing speed of cryptographic operations.

The OS 20 of the eUICC 2 is software that provides a runtime environment necessary for executing a computer program written in a specific programming language (eg, JAVA (registered trademark)).

The OS 20 provides an API (Application Program Interface) for using the hardware 25 to software that operates based on the OS 20 . APIs provided by the OS 20 include APIs related to cryptographic operations using the accelerator 253, but FIG. ing. The common area 260 is an area that can be used in common by the MNO, and the OS 20 allocates a part of the NVM 26 to the common area 260 .

An SD that operates based on the OS 20 will be described. Note that the ECASD 24 illustrated in FIG. 1 is an SD that is not used in the description of the present invention, so a detailed description of the ECASD 24 is omitted here.

ISD-R21 is the issuer's SD and is generated at the time of manufacture of the eUICC2. The number of ISD-R21s that can be generated in the eUICC2 is limited to one. The ISD-R21 has a function of building a secure channel with the provisioning system 3 and a function of managing the ISD-P22. The function of managing ISD-P22 includes the function of creating or deleting ISD-P22 and the function of setting the status of ISD-P22 to invalid or valid.

FIG. 3 is a diagram for explaining the structure of the profile 23. As shown in FIG. The ISD-P22 is an SD that stores the MNO profile 23 corresponding to the ISD-P22. As illustrated in FIG. 3, the profile 23 stored by the ISD-P 22 includes MNO-SD 230, NAA 235 (abbreviation for Network Access Application), POL 1233 (abbreviation for Network Access Application), file system 234 and SSD 231 (abbreviation for Supplementary Security Domain). ), and in FIG. 3, an application 232 .

The application 232 can include an application 232a related to services provided by the MNO to consumers, and furthermore, a service provider (hereinafter referred to as SP, SP is an abbreviation for Service Provider) that has a business alliance with the MNO. Applications 232b may be included that relate to services provided to consumers. The application 232b related to the SP is stored in the profile 23 in a state associated with the SSD 231, which is the SD of the SP that has a business tie-up with the MNO.

The SP's application 232b is the application 232 corresponding to the service provided by the SP to the consumer. The services provided by the SP to the consumer generally change depending on the mobile device 5 on which the eUICC2 is implemented. If the mobile device 5 on which the eUICC 2 is installed is a smart device 5b, this service is, for example, M-commerce or transportation tickets.

Generation of an instance of the application 232 requires installation of the application 232 and issue of the application 232 . In this embodiment, the SD that installs the application 232 is the MNO-SD 230, and the MNO-SD 230 uses the common area API 200 to install the application 232 to be included in the profile 23 in the common area 260. . The SD that issues the application 232 is the SSD 231 , and the SSD 231 has a function of writing data issued by the application 232 (for example, personal data) to the common area 260 using the common area API 200 .

FIG. 4 is a diagram for explaining the memory map of the NVM 26 that the eUICC 2 has. The NVM 26 of the eUICC 2 is divided by the OS 20 into an OS use area 26a used by the OS 20 and an SD use area 26b used by the SD. include.

A part of the program code of the OS 20 and data of the OS 20 are stored in the OS use area 26a. Note that most of the program code of the OS 20 is stored in the ROM 251 . The SD area 26b stores ISD-R21, ECASD24 and ISD-P22.

When generating the ISD-P 22, the ISD-R 21 generates a profile area 26c in the area of the SD use area 26b that is not set in the common area 260, and stores the profile 23 in this profile area. 26c to install. The ISD-R 21 is not authorized to use the common area 260 of the NVM 26, and the area subject to deletion/invalidation of the ISD-P 22 is limited to the profile area 26c. In FIG. 4, a profile area 26c corresponding to one ISD-P 22 is generated in the NVM 26, and the profile 23 stored by the ISD-P 22 is arranged in the profile area 26c.

As illustrated in FIG. 3, the profile 23 stored by the ISD-P 22 includes MNO-SD 230, NAA 235, POL1 233, file system 234, SSD 231 and application 232. The MNO-SD 230 is an SD functioning as a mobile communication carrier security domain according to the present invention.

The area for storing the MNO-SD 230, NAA 235, POL 1233, file system 234 and SSD 231 is always the profile area 26c. It can be placed in the common area 260 using the common area API 200 of the OS 20 . Since the target area when the ISD-R21 disables or deletes the ISD-P22 is the profile area 26c, by placing the application 232 in the common area 260, the ISD-R21 disables or deletes the ISD-P22. application 232 is not disabled or deleted.

In this way, if the common area 260 is provided in the NVM of the eUICC 2 and the application 232 can be installed in the common area 260 using the common area API 200 provided by the OS 20, the MNO is changed and the profile 23 is changed. Even in this case, the application 232 in the common area 260 in the state before the profile 23 is changed can be used with the changed profile 23 without reinstalling the application 232 .

When the application 232 is installed in the common area 260, if the installation information of the application 232 is stored in the common area 260, the application 232 in the common area 260 can be accessed even if the profile 23 is changed.

From here, the method of provisioning the eUICC2 will be described. FIG. 5 is a diagram for explaining the installation procedure of the profile 23 in the eUICC 2 provisioning method.

The steps involved in the profile 23 installation procedure are briefly described with reference to FIG. When the provisioning system 3 (becoming SM-SR 31) receives a trigger related to the installation of the profile 23 from an external device (S1), it first constructs a secure channel with the ISD-R 21 of the eUICC 2, and performs the installation. A request for generating the ISD-P 22 storing the profile 23 to be processed is sent to the ISD-R 21 (S2). The ISD-R 21 of the eUICC 2, which has received the ISD-P22 generation request, generates this ISD-P22 in the NVM 26 (S3). By generating the ISD-P 22 in the NVM 26, a profile area 26c for arranging the profile 23 to be installed is secured in the NVM 26. FIG.

Next, the provisioning system 3 (to become SM-DP 32) builds a secure channel with the ISD-P22 generated in the eUICC 2, and sends an installation request for the profile 23 stored in the ISD-P22 to the ISD-P22. Then (S4), the ISD-P 22 installs the profile 23 in the profile area 26c by writing the profile 23 included in the installation request into the profile area 26c (S5).

Since the profile 23 is disabled at the time of installation, the provisioning system 3 (becoming SM-SR 31) sends a request to enable the installed profile 23 to the ISD-R 21 of the eUICC 2 (S6), The ISD-R 21 of the eUICC 2 sets the status of the ISD-P 22 storing the installed profile 23 to valid (S7), and the procedure of FIG. 5 ends.

FIG. 6 is a diagram explaining the memory map of the NVM 26 before the profile 23 is installed, and FIG. 7 is a diagram explaining the memory map of the NVM 26 after the profile 23 is installed. As shown in FIG. 6, before the profile 23 is installed, the ISD-P 22 storing the profile 23 is not generated in the NVM 26, and the procedure of FIG. is generated in NVM 26. Since the MNO-SD 230 has the authority to install the application 232, the application 232 is not included in the profile 23 when the profile 23 is installed.

Next, the steps included in the issuing procedure of the application 232 will be briefly described. FIG. 8 is a diagram for explaining the procedure for issuing the application 232 in the eUICC2 provisioning method.

When the profile 23 is installed in the eUICC 2, the mobile device 5 incorporating the eUICC 2 confirms the application 232 included in the installed profile 23 (S10). The mobile device 5 incorporating the eUICC 2 branches the processing according to the confirmation result of the application 232 (S11). If the application 232 used in the mobile device 5 is not included in this profile 23, the SP-TSM 4 corresponding to the application 232 is sent a trigger related to the installation of the SP application 232 (S12). If this application 232 is included, the procedure ends (S11a). If the mobile device 5 that incorporates the eUICC 2 is a smart device, the user interface (UI: User Interface) is used.

The SP-TSM 4, having received the trigger related to the installation of the application 232, instructs the provisioning system 3 (here, the MNO-TSM 30) to install the application 232 (S13). The provisioning system 3 (here, MNO-TSM 30) builds a secure channel with the MNO-SD 230 included in the profile 23 (becomes the installed profile 23) set to a valid state at this point. , an installation request for the application 232 is sent to the MNO-SD 230 (S14), and the MNO-SD 230 writes the application 232 received from the provisioning system 3 (here, the MNO-TSM 30) to the NVM 26, and installs the application 232 to the eUICC 2. (S15). It should be noted that, in this embodiment, the area in which the application 232 is to be placed can be designated by the installation request for the application 232 . When the area where the application 232 is placed is specified in the common area 260 in the request for installing the application 232, the MNO-SD 230 uses the common area API 200 provided by the OS 20 to install the application 232 in the common area 260. . By executing the above procedure, the application 232 is installed in the common area 260 as shown in FIG.

When the installation of the application 232 is completed, the MNO-SD 230 notifies the provisioning system 3 (here, the MNO-TSM 30) of the installation completion of the application 232 (S16), and the provisioning system 3 (here, the MNO-TSM 30) The installation completion of the application 232 is transferred to the SP-TSM 4 (S17). The SP-TSM 4 establishes a secure channel with the SSD 231 included in the profile 23 set to a valid state at this time, and transmits a request for issuing the application 232 to the SSD 231 (S18). The SSD 231 writes the issue data included in the issue request for the application 232 received from the SP-TSM 4 to the NVM 26 to issue the application 232 (S19), and the procedure in FIG. 8 ends. Note that when the application 232 is installed in the common area 260 , the SSD 231 writes the issue data included in the issue request of the application 232 to the common area 260 and an instance of the application 232 is created in the common area 260 .

FIG. 9 is a diagram for explaining the memory map of the NVM 26 after changing the profile 23. As shown in FIG. In FIG. 9, the profile 23a and the profile 23b are installed, and the profile 23b installed after the profile 23a is valid. Since the application 232 was already installed in the common area 260 when the profile 23a was installed, the application 232 included in the profile 23a can be used as is in the changed profile 23b without reinstalling the application 232. available in the state of

1 Architecture related to remote provisioning 2 eUICC
20 operating system 20
21 ISD-R
22 ISD-P
23 Profile 230 MNO-SD
231 SSD
232 Applications 26 NVM
260 common area 3 provisioning system 30 MNO-TSM
31 SM-SR
32 SM-DP
4 SP-TSM
5 Mobile devices

Claims (4)

An operating system having a common area API for setting a common area that can be commonly used by mobile communication carriers in NVM, and having a common area API for accessing said common area; Equipped with a root security domain that has a function to manage the domain,
The root security domain has a function of generating the profile security domain in an NVM area that is not set in the common area,
The mobile communication operator security domain has a function of installing an application related to the mobile communication operator into the common area using the common area API.
An eUICC characterized by: The profile includes a security domain of a service provider that has a business tie-up with a mobile communication carrier, and the security domain of the service provider uses the common domain API to issue data of the application related to the service provider. 2. The eUICC according to claim 1, further comprising a function of writing to said common area. An operating system having a common area API for setting a common area that can be commonly used by mobile communication carriers in NVM, and having a common area API for accessing said common area; A method for provisioning an eUICC with a root security domain having the ability to manage the domain, comprising:
creating the profile security domain in an area of NVM where the root security domain is not set in the common area;
a step b in which the mobile operator security domain uses the common area API to install an application related to the mobile operator into the common area;
A method for provisioning an eUICC, comprising: The profile includes a security domain of a service provider that has a business alliance with a mobile communication carrier, and the security domain of the service provider uses the common domain API to issue data of the application related to the service provider. 4. The eUICC provisioning method according to claim 3, characterized in that it includes a step c of writing to said common area.

Images