KR101896869B1 - Security Domain Authority Change Control Method of Server, Security Domain Authority Change Method of Smart Card, Security Domain Authority Change Method of User Equipment, Server, Smart Card, and User Equipment - Google Patents

Abstract

More particularly, the present invention relates to a server for managing rights change of a security domain, a smart card for changing a right of a security domain, a terminal equipped with the smart card, And a method for changing the authority.

Description

A security domain authority change control method of a server, a security domain authority change method of a smart card, a security domain authority change method of a smart card, a security domain permission change method of a terminal, a server, a smart card, Card, Security Domain Authority Change Method of User Equipment, Server, Smart Card, and User Equipment}

More particularly, the present invention relates to a server for managing rights change of a security domain, a smart card for changing a right of a security domain, a terminal equipped with the smart card, And a method for changing the authority.

A UICC (Universal Integrated Circuit Card) is a smart card inserted in a terminal and can be used as a module for user authentication. The UICC can store the user's personal information and the carrier information of the mobile communication carrier to which the user subscribes. For example, the UICC may include an International Mobile Subscriber Identity (IMSI) for identifying a user. The UICC is also called a Subscriber Identity Module (SIM) card for Global System for Mobile communications (GSM) and a Universal Subscriber Identity Module (USIM) card for a Wideband Code Division Multiple Access (WCDMA) scheme.

When the user attaches the UICC to the user terminal, the user is automatically authenticated using the information stored in the UICC, so that the user can conveniently use the terminal. In addition, when the user changes the terminal, the user can easily replace the terminal by attaching the UICC removed from the existing terminal to the new terminal.

When a terminal requiring miniaturization, for example, a machine to machine (Machine to Machine, M2M) communication, is manufactured with a structure capable of detaching and removing the UICC, miniaturization of the terminal becomes difficult. Thus, a built-in UICC (Embedded UICC) structure, which is a non-removable UICC, has been proposed. The embedded UICC shall record the user information using the corresponding UICC in the form of IMSI.

The existing UICC can be attached to / detached from the terminal, and the user can open the terminal without being concerned with the type of terminal or the mobile communication provider. However, the IMSI in the built-in UICC can be allocated only when a terminal manufactured from the manufacturing of the terminal is used only for a specific mobile communication provider. Both the mobile communication service provider and the terminal manufacturer ordering the terminal are forced to pay attention to the product inventory and the product price is raised. The user is inconvenient that the mobile communication company can not be changed with respect to the terminal. Therefore, even in the case of the built-in UICC, a method by which the user can open the terminal without being bound to the mobile communication service provider is required.

The Issuer Security Domain (ISD) is a card manager that stores the secret key of the issuer and is used for the Mobile Network (MNO) (CardMessage Management) of the CCM (Operator) area. However, ISD is an entity subject to the mobile communication service provider, and ISD may be a problem in changing the mobile communication service provider.

It is an object of the present invention to provide a method and an apparatus for allowing a terminal including a built-in UICC to change a mobile communication provider.

One embodiment of the present invention is a security domain permission change control method executed in a server accessible to a first security domain set in a smart card, the method comprising: receiving a security domain change request signal from a terminal equipped with the smart card ; Transmitting a signal requesting to change a currently active second security domain among the plurality of second security domains to the locked state through the first security domain; And transmitting index information of a second security domain to be activated among the plurality of second security domains through the first security domain.

Another embodiment of the present invention is a security domain authorization change executed on a smart card including a first security domain sharing a key with a management server managing a smart card and a plurality of second security domains sharing a key with a network carrier The method comprising: receiving a signal from the management server requesting to change a currently active second security domain among the plurality of second security domains through the first security domain to a locked state; Changing the currently activated second security domain to a locked state; Receiving index information of a second security domain to be activated from among a plurality of second security domains through the first security domain from the management server; And activating a second security domain to activate the smart card.

Another embodiment of the present invention is a method for managing a smart card, which is executed in a terminal equipped with a smart card including a first security domain sharing a key with a management server managing a smart card and a plurality of second security domains sharing a key with a network carrier A method for changing a security domain authority, comprising: receiving a signal from the management server requesting to change a currently active second security domain among a plurality of second security domains through the first security domain to a locked state; Changing the currently activated second security domain to a locked state; Receiving index information of a second security domain to be activated from among a plurality of second security domains through the first security domain from the management server; And activating a second security domain to be activated by the second security domain.

According to another aspect of the present invention, there is provided a smart card system including a key storage unit for storing a key shared with a first security domain of a smart card; An index storage unit for storing an index of a plurality of second security domains of the smart card corresponding to a network operator; And a first interface for transmitting a status change request signal of the second security domain to the first security domain and receiving a response signal for transmission.

According to another aspect of the present invention, there is provided a smart card system including a key storage unit for storing key information of a security domain of a smart card corresponding to a network operator; And an interface for receiving a key information request signal of the secure domain from an external server communicating with the smart card and transmitting the key information of the secure domain to the external server.

Another embodiment of the present invention is a security management system comprising: a first security domain sharing a key with a management server managing a smart card; A plurality of second security domains sharing a key with a network operator; And a controller for controlling activation of a status of a corresponding second security domain based on a status change request signal of a second security domain received through the first security domain.

Another embodiment of the present invention includes an internally mounted smart card, the smart card comprising: a first security domain for sharing a key with a management server managing a smart card; A plurality of second security domains sharing a key with a network operator; And a control unit for controlling activation of a state of the corresponding second security domain based on a state change request signal of a second security domain received through the first security domain.

According to the present invention described above, a terminal including a built-in UICC can change a mobile communication service provider.

1 shows a structure of a system to which embodiments of the present invention can be applied.
2 is a software hierarchical structure in an eUICC according to an embodiment of the present invention.
FIG. 3 illustrates a life cycle structure according to an embodiment of the present invention.
4 and 5 are flowcharts of a MNO changing method according to an embodiment of the present invention.
6 is a block diagram showing a configuration of an SM-SR according to an embodiment of the present invention.
7 is a block diagram showing a configuration of an SM-DP according to an embodiment of the present invention.
8 is a block diagram showing the configuration of a terminal according to an embodiment of the present invention.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. It should be noted that, in adding reference numerals to the constituent elements of the drawings, the same constituent elements are denoted by the same reference symbols as possible even if they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

UICC (Universal Integrated Circuit Card) is a smart card used in mobile terminals in GSM (Global System for Mobile Communications), UMTS (Universal Mobile Telecommunications System) and CDMA (Code Division Multiple Access) networks. In a GSM network, a UICC includes a Subscriber Identity Module (SIM) application, a Universal Subscriber Identity Module (USIM) application in a UMTS network, and a CDMA Subscriber Identity Module (CSIM) application in a CDMA network. The UICC consists of CPU, ROM, RAM, EEPROM and I / O circuits.

A M2M (Machine-to-Machine) terminal actively discussed in GSMA (GSM Association) is required to be small in size. When using a conventional UICC, a module for mounting a UICC must be separately inserted in the M2M terminal. If the M2M terminal is manufactured in a detachable structure, miniaturization of the M2M terminal becomes difficult.

Therefore, an embedded UICC (hereinafter also referred to as an eSICC) (or an embedded SIM (eSIM)) structure in which a UICC can not be detached is discussed. In this case, a built- Information of a mobile network operator (MNO) must be stored in the UICC in the form of an International Mobile Subscriber Identity (IMSI).

However, since the IMSI in the built-in UICC can be allocated only when the terminal manufactured from the manufacturing of the M2M terminal is used only in the specific MNO, the MNO or the M2M manufacturer that orders the M2M terminal or the UICC, There is a problem that the price of the product is inevitably increased due to the inevitable assignment of the nerve, which is a big obstacle to the expansion of the M2M terminal.

Unlike the existing detachable UICC, eUICC, which is integrated in the terminal, has many problems such as opening authority, initiative of supplementary service business, security of subscriber information due to its physical structure difference. In particular, since the UICC is soldered to the terminal board, remote provisioning management is required in order to handle the existing subscription opening, authorization, and subscription change.

To this end, international standardization organizations such as the GSMA and ETSI (European Telecommunications Standards Institute) are conducting standardization activities on related elements such as telecommunication carriers, manufacturers, UICC vendors and other necessary elements including top-level structure. In addition, GP (GlobalPlatform) is developing standardization infrastructure for smart card development, distribution and management. As eUICC is discussed through standardization bodies, the core of the issue is the entity (or its function / role) called the Subscriber Manager (SM). SM is the Operator Credential, MNO Credential, Profile, eUICC Profile, Profile Package, etc.) to the eUICC and processes the subscription change process.

Accordingly, the relationship between the eUICC structure and the SM may need to be taken to accommodate additional services of a mobile network operator (MNO) as it is.

1 shows a structure of a system to which embodiments of the present invention can be applied.

1, a system to which the present invention can be applied includes a Subscription Manager (SM) 110, a UICC Vendor 120, a Device Vendor 130, a Service Provider 140 and a plurality of communication providers (MNO1 to MNO3) 150a to 150c.

The SM 110 plays an overall management role for the eUICC by issuing operator information (Operator Credential, MNO Credential, Profile, eUICC Profile, Profile Package, etc.) to the eUICC and processing the process of subscription change.

The role of the SM 110 is classified as subscription manager-data preparation (SM-DP) for creating the provider information and Subscription Manager-Secure Routing (SM-SR) for carrying the carrier information directly to the eUICC . The SM-DP can securely generate business information (IMSI, K, OPc, supplementary service application, supplementary service data, etc.) and make it into a credential package. The SM-SR can securely download the SM-DP-generated credential package to the eUICC through UICC remote management technology such as over-the-air (OTA) or GP SCP (Secure Communication Protocol).

More specifically, the SM-DP is responsible for the secure preparation of the package to be delivered to the eUICC, and works with the SM-SR for actual transmission. The key functions of the SM-DP are: 1) to manage the functional characteristics and certification level of the eUICC, and 2) to manage the MNO credential (for example, IMSI, K, supplementary service application, Some of which may potentially be encrypted by the MNO), and 3) computing the OTA package for downloading by the SM-SR, etc., and additional functionality may be added in the future.

The SM-DP may be provided by a specific MNO or may be provided by a third TSM (3rd Trusted Service Manager, hereinafter referred to as 3rd TSM). When provided by 3rd TSM, security and trust relationships become important. In addition to real-time provisioning, SM-DP can have a significant amount of background processing capability, and requirements for performance, scalability, and reliability can be important.

SM-SR is responsible for securely routing and delivering the credential package to the corresponding eUICC. The core functions of SM-SR are: 1) managing eUICC and OTA communication through an encrypted VPN (Virtual Private Network), and 2) managing communication with other SM-SRs to form an end-to- , 3) managing the eUICC data used for SM-SR OTA communication provided by the eUICC provider, and 4) protecting the communication with the eUICC by filtering only the allowed objects (firewall function).

The SM-SR database may be provided by the eUICC vendor 120, the device vendor 130, the MNOs 150a-150c and may be used by the MNOs 150a-150c via the SM-SR mesh network.

Meanwhile, GSMA proposed a structure called "Circle of Trust", and the concept of establishing an end-to-end trust relationship between the MNO and the eUICC through overlapping of trust relationships between each similar entity The For example, MNO establishes a trust relationship with SM-DP, SM-DP establishes a trust relationship with UICC SM, and UICC SM establishes a trust relationship with eUICC, whereby MNO and eUICC form a trust relationship can do.

In addition, the MNO establishes a trust relationship with the SM-DP, the SM-DP establishes a trust relationship with the Device SM, and the Device SM establishes a trust relationship with the UE, thereby establishing a trust relationship with the MNO have. Hereinafter, a flow between the MNO, the eUICC, and the terminals can be expressed as a flow between the SM-DP, the UICC SM, and the Device SM.

The UICC vendor 120 is an entity that produces an eUICC chip. The eUICC chip produced by the UICC vendor 120 is connected to the terminal by the device vendor 130. A terminal with an embedded eUICC may be provided to the service provider 140.

For provisioning, UICC vendor 120 and SM 110 may exchange key data for eUICC identifier and encryption. The service provider 140 and the SM 110 can exchange credentials and the SM 110 and the MNOs 150a to 150c can exchange credentials for joining. Upon completion of the subscription, the service provider 140 and the MNOs 150a-150c can maintain the telecom service.

2 is a software hierarchical structure in an eUICC according to an embodiment of the present invention.

The global platform-based card architecture consists of a number of components to ensure hardware and vendor-neutral interfaces to application and off-card management systems. These components include one or more applications for one or more card issuers, one or more applications for the card issuer's business partners (i.e., application providers), one or more applications for providing global services (e.g., CSM services) have.

All applications are implemented in a secure runtime environment that includes a hardware-neutral API (Application Programming Interface) that supports application mobility. The global platform is not limited to a particular runtime environment technology, but is a major card component that acts as a central manager of the card manager. A security management application called a specific key and security domain (hereinafter referred to as SD) is created to ensure that the keys are completely separated between the card issuer and a number of other SD providers.

The SD acts as an on-card agent for the off-card authority. SD can be roughly classified into three types, reflecting three types of off-card institutions recognized by the card.

First, ISD is the primary but essential on-card delegate for the card administrator who is usually the issuer of the card.

Second, Supplementary SD (SD) serves as an optional and optional on-card agent for card issuers or application providers or their agents.

As a third type, the Controlling Authority Security Domains (SD) is a special form of assisted SD, which enforces a security policy that is applied on all application codes loaded into the card. The control authority may also use this form of SD as its on-card agent to provide this functionality. There may be more than one such control organ SD.

In general, all three types are simply referred to as SD, and SD is a security service such as key handling, encryption, decryption, digital signature generation and verification for its provider (card issuer, application provider, or control authority) . Each SD is established on behalf of the card issuer, application provider, or control authority when the off-card entity requests to use a key that is completely isolated from each other.

There may be one or more global service applications in the card, so that other applications on the card can provide services such as a Cardholder Verification Method (CVM).

The global platform is intended to operate in a secure multi-application card runtime environment, which provides secure storage and application execution space as well as hardware-neutral APIs for applications, so that each application code and data is separated from other applications So that it is stably maintained. The runtime environment of the card also provides communication services between cards and off-card entities.

The global platform card may also include one or more Trusted Frameworks, which provide inter-application communication between applications. The trust framework is not an application or SD, and may exist as an extension or a part of a card runtime environment.

Referring to FIG. 2, the software layer structure in the eUICC includes a hardware layer, a chip OS layer on a hardware layer, a Java card platform layer on a chip OS layer, and a global platform (GP) layer on a Java platform layer.

Above the GP layer, a SIM / UICC API (Application Programming Interface) layer exists. If USAT Application Toolkit (USAT) application framework layer exists on the SIM / UICC API layer, application layers (App5, App6) Lt; / RTI >

On the GP layer, there is a Super Issuer Security Domain (ISD) layer. On the super ISD layer, ISD (ISD1, ISD2) specified for each MNO exists. A security domain layer exists on each ISD layer, and application layers (App1 ~ App4) exist on each security domain layer.

A secure domain is a privileged application that holds cryptographic keys used to support secure channel protocol operations or to authenticate card content management functions.

Each security domain, as a privileged application, can store a secret key, provide cryptographic services to associated applications, and provide Secure Channel Protocol (SCP).

Each application and each executable load file is associated with a secure domain, and the application can use the encryption service of the associated secure domain.

The security domain is responsible for managing its own key so that applications and data from several different application providers may coexist in the same card without violating the privacy and integrity of each application provider. Also, in the embodiment of the present invention, the ISD is responsible for its own key management, so that applications and data from different MNOs can coexist within the same card without violating the privacy and integrity of each MNO have.

The keys and associated cryptographic operations for all secure domains can provide secure communications support while personalizing the application provider's application and enable secure communications during run time of applications that do not include their secure messaging keys.

Each ISD is a card manager, which stores the secret key of the issuer and is responsible for authentication for CCM (Card Content Management) of the MNO area.

The super ISD can select or change a plurality of card managers (ISD), store the ISD's secret key, manage its index, and perform authorization for CCM in the SM-DP area.

Referring to FIG. 2, the super ISD can manage the '210' area, and the ISD1 and ISD2 selected according to each MNO can manage the '220a' and '220b' areas, respectively.

The information of the secure domain key may be composed of a key ID, a key version, an encryption algorithm, a length of an encryption algorithm, a connection condition, and the like.

For example, according to the GP-card standard, a security domain can manage keys as follows:

The key ID and key version number uniquely identify each key in the card object. In other words, each combination of key ID and key version number identifies a unique key slot within the entity.

Adding a key is equivalent to assigning a new key slot with a new key value, a new key ID, or a new key version number.

Replacing the key involves updating the key slot with the value of the new key and the associated key version number. The key ID remains the same. The previous key is no longer valid.

In one embodiment of the present invention, the super ISD key is an eUICC platform access credential, which is a key that can have access to the platform of the eUICC. In eUICC environment, Value Added Service of existing MNO should continue. If the profile is mounted when initially provisioning or when changing the MNO, the eUICC platform access credential must be used to obtain the privilege, and in this case the super ISD can be used. The GP can provide the capability to accommodate super ISDs.

The super ISD may have key information and key attribute structures similar to the ISD's key information and key attribute structures. However, the specific key ID and the key version number can be allocated and allocated for super ISD key use. On a super ISD base, there may be more than one card life cycle in more than one ISD region.

FIG. 3 illustrates a life cycle structure according to an embodiment of the present invention.

Referring to FIG. 3, the super card lifecycle of the UICC managed by the SM-SR in association with the super ISD may have the OP_READY, INITIALIZED, SECURED, CARD_LOCKED, and TERMINATED states. The OP_READY state is ready for the execution environment and the super ISD is ready to receive, execute, and respond to APDU (Application Protocol Data Unit) commands. The INITIALIZED state is the card creation state. The INITIALIZED state can not return to the OP_READY state. In the SECURED state, the card issuance is completed, and the card security is stable. The SECURED state can not return to the INITIALIZED state. The CARD_LOCKED state is the moment when the card is locked. The contents of the card can not be changed. The CARD_LOCKED state can return to the SECURED state. The TERMINATED state indicates that the card has been discarded. The contents of the card can not be changed. The TERMINATED state can not be returned to any other state.

The card lifecycle managed by SM-DP in conjunction with ISD can have INSTALLED, SECURED, TERMINATED, and CARD_LOCKED states. The INSTALLED state means that the ISD is an object in the GP Registry and these objects can be accessed as authenticated external objects. In the SECURED state, the card security is stable. The TERMINATED state indicates that the ISD associated with a particular MNO has been deleted or disabled. The CARD_LOCKED state is a temporary lock state.

There can be more than one card lifecycle within a single card life cycle. That is, if the MNO associated with the UE equipped with the eUICC is changed, the card life cycle associated with the previous MNO is terminated, but the card life cycle associated with the new MNO may be newly started and all of these card life cycles may be within the super card life cycle exist.

An application's lifecycle can have INSTALLED, SELECTABLE, Applet specific, and LOCKED states. The INSTALLED state is where the application executable code is properly linked and the required memory allocation is made. The SELECTABLE state is a state in which an application can receive an instruction from an external entity. The Applet specific state is the state in which the operation of the application is determined by the application itself. The LOCKED state is a temporary lock state.

The lifecycle of a secure domain can have INSTALLED, SELECTABLE, PERSONALIZED, and LOCKED states. In the INSTALLED state, the security domain becomes an object in the GP registry and these objects can access the authenticated external object. The SELECTABLE state is a state in which the security domain can receive commands from external entities. The PERSONALIZED state is where the security domain has all the necessary personalization data and keys for its execution. The LOCKED state is a temporary lock state.

4 and 5 are flowcharts of a MNO changing method according to an embodiment of the present invention. However, the method shown in Figs. 4 and 5 can not be applied only when the MNO is changed, but the method shown in Fig. 4 can be applied to proceeding with the termination procedure or the pause procedure for a specific MNO, May also be applied to the proceeding of a subscription or re-entry procedure for a particular MNO.

The UICC includes an SKM (Super Key Manager) entity for managing a super key. The SKM may have a super ISD area, a plurality of ISD (1st ISD, 2nd ISD, etc.) area, and an SKM application area. A plurality of ISDs (1st ISD, 2nd ISD, etc.) correspond to a plurality of MNOs. The SM-DP shown in FIG. 4 is an entity including information on at least the 1st ISD, and the SM-DP shown in FIG. 5 is an entity including information on at least the 2nd ISD, It may be another entity.

A terminal equipped with a UICC can have a device SM application.

In the initial state, the SM-SR and the SM-DP have completed the change of the security right to the specific MNO (MNO1).

In the SKM in the UICC, the 1st ISD is the post-issuance state in the card life cycle, the 2nd ISD is the pre-release state in the card life cycle, the 1st ISD is activated and the 2nd ISD is activated . This state may occur when the UE changes the MNO from the MNO (MNO1) corresponding to the 1st ISD to the MNO (MNO2) that has not joined so far.

Alternatively, the 2nd ISD may not be activated as a CARD-LOCKED state in the card life cycle. This state may occur when the UE has previously changed the MNO from the MNO (MNO2) corresponding to the 2nd ISD to the MNO (MNO1) corresponding to the 1st ISD currently activated and then re-changed the MNO from the MNO1 to the MNO2 .

On the other hand, in the initial state, the SM-SR and the SM-DP are in a state in which the security right is changed to a specific MNO (MNO1).

Referring to FIG. 4, when the MNO is changed, the SKM application in the UICC requests the device to change the MNO Post-Issuance to another MNO (S401). The device requests the SM-SR to change the MNO post-deployment to another MNO in the SM-SR (S402).

The SM-SR performs the authentication procedure using the super-ISD in the UICC (S403). The authentication procedure can be performed using a key shared by the SM-SR and the super-ISD.

When the authentication procedure is completed, the SM-SR requests the SM-DP to change the 1st ISD from the card life cycle to the CARD-LOCKED state (S403). A CARD-LOCKED request from SM-SR to SM-DP may contain index information of the corresponding ISD (1st ISD). The SM-DP requests CARD-LOCKED of the 1st ISD to the super-ISD (S404). A CARD-LOCKED request from the SM-DP to the super-ISD may include index information of the corresponding ISD (1st ISD). At the same time, the SM-SR performs the authentication procedure with the 1st ISD (S405).

The super-ISD receiving the CARD-LOCKED request signal of the 1st ISD from the SM-DP requests CARD-LOCKED of the 1st ISD to the SKM application (S406). Only the Super-ISD has the authority to request the status change of the SKM application in the life cycle of ISD (1st ISD, 2nd ISD, etc.). Upon receiving the CARD-LOCKED request signal from the super-ISD, the SKM application sets the state of 1st ISD to CARD-LOCKED (S407). In step S408, the 1st ISD reports setting information including the index and the CARD-LOCKED state of the ISD to the SM-SR.

When the step S408 is completed, the 1st ISD is in the CARD-LOCKED state in the card life cycle.

The above-described steps S401 to S408 may also be performed when the MNO1 is in the process of terminating or suspending the MNO1. In this case, the message transmitted in steps S401 and S402 may be a revocation or suspension request message instead of the MNO change request message. Then, all the procedures can be completed in step S408.

FIG. 5 shows the steps after step S408 in FIG. 4 in the MNO changing method.

Referring to FIG. 5, the SM-SR receiving the setting status information from the 1st ISD changes the ISD index of the MNO from the index of the 1st ISD corresponding to the MNO1 to the index of the 2nd ISD corresponding to the MNO2 (S409).

The SM-SR requests the SM-DP for the ISD key information (keyset) of the MNO2 (S410). The ISD key information request can be used in the step S409 to change the ISD index of the MNO2. The SM-DP transmits the ISD key information of the MNO2 to the SM-SR (S411).

The SM-SR transmits the ISD index and the ISD key information to the super ISD to request a put key (S412). The ISD index and / or ISD key information may be encrypted using a key shared by the SM-SR and the super ISD. The super ISD requests the SKM application to inject the ISD index and ISD key information (S413). If the ISD index and / or ISD key information is encrypted by the SM-SR, the super ISD can decrypt the encrypted information. The SKM application inputs the key of the second ISD corresponding to the specific MNO (MNO2) using the ISD key information of the specific MNO (MNO2) based on the ISD index (S414). The 2nd ISD notifies the generated result to the SM-SR and responds to the Put key result (S415). The response message may include an ISD index.

On the other hand, there may be a case where the 2nd ISD stores key information or key in advance. For example, the 2nd ISD was previously activated, and the subsequently activated security domain was changed from the 2nd ISD to the 1st ISD, so that the current 2nd ISD may be in the CARD-LOCKED state. In this case, steps S410 and S411 for the SM-SR to fetch the key information from the SM-DP may be omitted. Steps S412 to S414 may include the ISD index but not the ISD key information.

The SKM application changes the security domain from 1st ISD corresponding to MNO1 to 2nd ISD corresponding to MNO2 (S416). The SKM application instructs the super ISD to change the security domain state to the 2nd ISD of MNO2 (S417). The super ISD responds with the changed security domain status and the result of the put key (S418). The response message may include the ISD of the MNO.

When this process is completed, the ISD of MNO2 is activated (S419, S420). Thus, the MNO2 (or SM-DP) can access the UICC (2nd ISD) using the key shared by itself and the UICC (2nd ISD).

The SM-SR finally responds to the device with the post-deployment result (S421), and the device responds to the SKM application (S422).

Upon completion, the SM-SR and the SM-DP have completed changing the security right to the MNO2, and the MNO2 can access the UICC. The 2nd ISD is in a post-distribution state, i.e., SECURED, in the card life cycle.

On the other hand, if a revocation procedure or a suspension procedure is performed for a specific MNO, steps S401 to S408 of FIG. 4 and steps S421 and S422 of FIG. 5 may be executed. The card lifecycle is post-issuance status for one MNO and the card life cycle is pre-release (CARD-LOCKED) for another MNO, The card lifecycle for all MNOs will be pre-deployed or CARD-LOCKED.

Alternatively, in the case of performing the opening or re-opening procedure for the terminated or suspended terminal, steps S401 and S402 of FIG. 4 and steps S409 and S422 of FIG. 5 may be executed. Card life cycle is pre-distributed or CARD-LOCKED for all MNOs before proceeding, and card life cycle is post-distribution state for one MNO after proceeding and pre-distribution or CARD- LOCKED state.

6 is a block diagram showing a configuration of an SM-SR according to an embodiment of the present invention.

Referring to FIG. 6, the SM-SR 600 includes a super ISD key storage unit 610, an ISD index storage unit 620, an SM-DP interface 630, and a UICC interface 640.

The super ISD key storage unit 610 stores a key shared with the super ISD of the UICC. Keys shared with Super ISD can be obtained from a UICC vendor that made the UICC in advance.

The ISD index storage unit 620 stores an index of the ISD corresponding to each MNO.

The SM-DP interface 630 is an interface for communicating with the SM-DP. The SM-DP interface 630 can request the key information of the ISD corresponding to the MNO to the SM-DP and receive it from the SM-DP.

The UICC interface 640 is an interface for communicating with the UICC. The UICC interface 640 may perform the authentication procedure with the super ISD of the UICC. The UICC interface 640 may send a request signal to change the life cycle status of the ISD corresponding to each MNO through the super ISD of the UICC. For example, the UICC interface 640 may send a request signal to change the life cycle status of each ISD from a pre-deployment to a post-deployment state, from a post-deployment state to a CARD-LOCKED state, or from a CARD-LOCKED state to a post deployment state Super ISD can be transmitted. When changing the MNO from MNO1 to MNO2, the UICC interface 640 sends a request to change the 1st ISD corresponding to MNO1 from the post-deployment state to the CARD-LOCKED state and the 2nd ISD corresponding to MNO2 to the pre-distribution state or CARD-LOCKED State to post-deployment.

7 is a block diagram showing a configuration of an SM-DP according to an embodiment of the present invention.

Referring to FIG. 7, the SM-DP 700 includes an ISD key storage unit 710, an SM-SR interface 720, and a UICC interface 730.

The ISD key storage unit 710 stores a key shared with the ISD of the eUICC installed in the terminal opened to the MNO. Thus, the MNO can provide services through the eUICC.

The SM-SR interface 720 receives the key information request signal from the SM-SR and can transmit the key information to the SM-SR.

The UICC interface 730 may provide a service to a corresponding ISD in the eUICC using a key shared with the ISU of the eUICC. As an example, the UICC interface 730 may perform the authentication procedure with the corresponding ISD in the eUICC.

8 is a block diagram showing the configuration of a terminal according to an embodiment of the present invention.

Referring to FIG. 8, the terminal 800 includes an embedded UICC (eUICC)

The eUICC 810 includes a super ISD 812, one or more ISDs (ISD1 814, ISD2 816), and a control unit 818. [

The super ISD 812 can share a key with the SM-SR. Using this, the super ISD 812 can proceed with the authentication procedure with the SM-SR.

In addition, the super ISD 812 may receive a lifecycle status change request signal from each of the ISDs 814 and 816 from the SM-SR. For example, the super ISD 812 may change the life cycle state of each ISD 814, 816 from a pre-release state to a post-release state, a post-deployment state to a CARD-LOCKED state, , Or a signal requesting the SM-SR to change the CARD LOCKED state to the post-deployment state. That is, the super ISD 812 may receive a signal from the SM-SR requesting the ISDs 814 and 816 in an active state without being activated, or in an activated state in an activated state. With this, when changing the MNO, it is possible to receive a signal to change the activated security domain.

In addition, the super ISD 812 may receive index and key information of the ISD to be activated corresponding to a specific MNO from the SM-SR.

ISDs 814 and 816 may be activated in response to a particular MNO. The activated ISDs 814, 816 can be serviced by the MNO using the keys of the ISD. In addition, ISDs 814 and 816 may proceed with the authentication process with SM-DP.

The control unit 818 may change the life cycle states of the respective ISDs 814 and 816 based on the ISD lifecycle status change request signal received via the super ISD 812. [ For example, the control unit 818 changes the life cycle state of each ISD 814 and 816 from a pre-release state to a post-release state, a post-deployment state to a CARD-LOCKED state, Or change the CARD LOCKED state to a post-deployment state. That is, the control unit 818 can change the state of the ISDs 814 and 816 to an active state without being activated, or to an active state. Using this, the control unit 818 can change the activated security domain when changing the MNO.

Also, the controller 8181 can input the key information to the ISDs 814 and 816 corresponding to the specific MNO using the index and key information of the ISD received via the super ISD 812.

In the manner described above, the eUICC may change the MNO subscribed to the software.

Although the above embodiment has been described by exemplifying the eUICC embedded in the M2M terminal, the present invention is not limited thereto, but can be applied to other IC-cards. In addition, the present invention is applicable to an integrated IC-card such as a standard Plug-In SIM (2FF), Mini-SIM (3FF), and SMD SIM (4FF). However, it is advantageous because it is especially useful in the M2M field where USIM is basically applied as a built-in form.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas within the scope of equivalents should be construed as falling within the scope of the present invention.

Claims (14)

A smart card for communicating with a Subscription Manager (SM) for managing a smart card and a plurality of MNOs,
A first security domain sharing a key with Subscription Manager-Secure Routing (SM-SR);
A plurality of second security domains sharing keys with Subscription Manager-Data Preparation (SM-DP); And
The smart card controlling the second security domain according to a signal received via a first security domain,
Wherein the first security domain and the second security domain are surrogates for an off-card authority. The method according to claim 1,
Wherein the state of the smart card is managed by the SM-SR in association with the first security domain and is managed by the SM-DP in conjunction with the second security domain. The method according to claim 1,
Wherein the state of the second security domain comprises:
Wherein the smart card is controlled to one of an installed state, an active state, an inactive state, and a deleted state based on a signal received through the first security domain. The method according to claim 1,
Wherein the first security domain is a representative of an off-card entity managing or issuing the smart card. The method of claim 4,
And the off-card agency is the SM. The method according to claim 1,
And the second secure domain is a surrogate of an application provider. The method of claim 6,
Wherein the application provider is SM-DP. A security domain management method of a smart card communicating with a Subscription Manager (SM) managing a smart card and a plurality of mobile network operators (MNO)
Configuring a first security domain sharing a key with Subscription Manager-Secure Routing (SM-SR);
Configuring a plurality of second security domains sharing keys with Subscription Manager-Data Preparation (SM-DP); And
And controlling the second security domain according to a signal received via the first security domain,
Wherein the first security domain and the second security domain are surrogates for an off-card authority. The method of claim 8,
Wherein the state of the smart card is managed by the SM-SR in association with the first security domain and is managed by the SM-DP in conjunction with the second security domain. The method of claim 8,
Wherein the state of the second security domain comprises:
Wherein the control information is controlled to one of an installed state, an active state, an inactive state and a deleted state based on a signal received through the first security domain. The method of claim 8,
Wherein the first security domain is a surrogate of an off-card entity managing or issuing the smart card. The method of claim 11,
Wherein the off-card agency is an SM. The method of claim 8,
Wherein the second security domain is a surrogate of an application provider. 14. The method of claim 13,
Wherein the application provider is SM-DP.

Images