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

Abstract

More particularly, the present invention relates to a server for managing the handover of the security domain, a smart card for transferring rights of the security domain, a terminal equipped with the smart card, And how to transfer the authority.

Description

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

More particularly, the present invention relates to a server for managing the handover of the security domain, a smart card for transferring rights of the security domain, a terminal equipped with the smart card, And how to transfer 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, the ISD is an entity subject to the mobile communication service provider, and the ISD may become a problem when the user opens the terminal regardless of the mobile communication service provider.

It is an object of the present invention to provide a method and an apparatus for enabling a terminal including a built-in UICC to be opened without being restricted by a mobile communication service provider.

According to an embodiment of the present invention, there is provided a security domain rights transfer control method executed in a server accessible to a first security domain set in a smart card, the method comprising: receiving an authorization transfer request signal from a terminal equipped with the smart card; Requesting a specific network operator for key information of a second security domain; Receiving key information of the second security domain from the specific network operator; And transmitting the index and key information of the second security domain through the first security domain.

Another embodiment of the present invention is a security domain authorization transfer executed in a smart card including a first security domain sharing a key with a management server managing a smart card and at least one second security domain sharing a key with a network carrier Receiving, from the management server, index and key information of a second security domain corresponding to a network operator to which the smart card is subscribed, through the first security domain; Inputting key information of a second security domain received in a second security domain corresponding to the network operator; And changing a security domain from the first security domain to a second security domain corresponding to the network provider.

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 one or more second security domains sharing a key with a network carrier A method of transferring security domain rights, comprising: receiving index and key information of a second security domain corresponding to a network operator to which the smart card is subscribed, from the management server through the first security domain; Inputting key information of a second security domain received in a second security domain corresponding to the network operator; And changing a security domain from the first security domain to a second security domain corresponding to the network provider.

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 second security domain of the smart card corresponding to a network operator; A first interface requesting the network operator for key information of the second security domain and receiving key information of the second security domain from the network provider; And a second interface for transmitting index and key information 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; One or more second security domains sharing a key with a network operator; And receiving index and key information of the second security domain through the first security domain, inputting the key information into the corresponding second security domain, and transmitting security information from the first security domain to the second security domain, And a control unit for changing the operation mode of the smart card.

Another embodiment of the present invention includes an internally mounted smart card, wherein the smart card includes: a first security domain sharing a key with a management server managing the smart card; One or more second security domains sharing a key with a network operator; And receiving index and key information of the second security domain through the first security domain, inputting the key information into the corresponding second security domain, and transmitting security information from the first security domain to the second security domain, And a control unit for changing the state of the terminal.

According to the present invention described above, a terminal including a built-in UICC can be opened without regard to 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 illustrates a pre-provisioning method of an eUICC according to an embodiment of the present invention.
FIG. 5 is a flowchart of a method for a security posture changeover (MNO) target domain through a change from a super ISD to an ISD 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 can not be 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 Figure 2,

In eUICC, the software hierarchy includes the hardware layer, the chip OS layer above the hardware layer, the Java card platform layer above the chip OS layer, and the global platform (GP) layer above the 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 illustrates a pre-provisioning method of an eUICC according to an embodiment of the present invention.

Referring to FIG. 4, initially, the SM-SR associated with a particular MNO or 3rd TSM manages a list of ISD indexes for a plurality of MNOs.

The UICC vendor (or UICC SM) forwards the produced UICC to the device vendor, and the device vendor loads the UICC to the device (terminal) (S401). The terminal (or the device SM) requests the loaded UICC to pre-provide the SM-DP of the specific MNO among the plurality of MNOs (S402). At this time, the information provided by the terminal may include a model of the apparatus and UICC information.

The SM-DP requests information for initial provision to the SM-SR (S403). The SM-SR requests information for providing the initial UICC to the UICC vendor, and the UICC vendor responds to the information request for providing the initial UICC (S404). The information for providing includes an Integrated Circuit Card Identifier (ICCID), an International Mobile Subscriber Identity (IMSI), an OPi, a Ki, an MSISDN (Mobile Subscriber Integrated Services Digital Network Number), and the like.

The SM-SR transmits initial provision information to the SM-DP (S405). The SM-DP performs the allowed pre-provision using the received initial provision information (S406). The SM-DP transmits a message to the SM-SR indicating that the initial provision of the UICC is completed (S407).

Once this process is complete, the SM-SR is pre-provisioned for the UICC of a particular MNO. Currently, SM-DP and Device SM are pre-provisioned to a specific MNO network (for example, 3G network. Currently, UICC is only authorized SM-SR that receives information from UICC vendor via Super ISD And the SM-DP of the MNO does not have such authority.

FIG. 5 is a flowchart of a method for a security posture changeover (MNO) target domain through a change from a super ISD to an ISD according to an embodiment of the present invention. This process can be executed in the process of opening the terminal.

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. 5 is an entity corresponding to the 1st ISD.

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

In its initial state, the SM-SR is a pre-provisioned state for the UICC of a particular MNO. SM-DP is pre-provisioned in the network of a specific MNO. In the SKM in the UICC, the super ISD, the 1st ISD, and the 2nd ISD are in a pre-release state in the super card lifecycle shown in FIG. In addition, the SKM application and the device SM application are pre-provisioned in the network of a specific MNO.

When opening the terminal, the SKM application in the UICC requests the UICC post-deployment (Post-Issuance) to the device (S501). The device requests UICC post-deployment to the SM-SR (S502). At this time, the request message from the device to the SM-SR may include the memory capacity and other information of the UICC.

The SM-SR performs the authentication procedure using the super ISD in the UICC (S503). The authentication procedure can be performed using a key shared by the SM-SR and the super ISD. When the authentication operation is completed, the SM-SR activates the ISD index of the specific MNO (S504).

The SM-SR requests the SM-DP for the ISD key information (keyset) of the specific MNO (S505). The ISD key information request may be used for the ISD index of the specific MNO activated in step S504. The SM-DP transmits the ISD key information of the specific MNO to the SM-SR (S506).

The SM-SR transmits the ISD index and the ISD key information of the specific MNO to the super ISD to request a put key (S507). The ISD index and / or the ISD key information of a particular MNO 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 the ISD key information of the specific MNO (S508). If the ISD index and / or ISD key information of a particular MNO is encrypted by the SM-SR, the super ISD may decrypt the encrypted information. The SKM application generates a 1st ISD corresponding to a specific MNO using the ISD key information of a specific MNO based on the ISD index (S509). The 1st ISD notifies the generated result to the SM-SR and responds to the Put Key result (S510). The response message may include an ISD index.

The SKM application changes the security domain from the super ISD to the ISD (1st ISD) of the specific MNO (S511). The SKM application instructs the 1st ISD to change the security domain status to the ISD of the specific MNO (S512), and instructs the super ISD to change the security domain status to the ISD of the specific MNO (S513). The super ISD responds with the changed security domain status and the result of the put key (S514). The response message may include the ISD of the MNO.

When this process is completed, the ISD of the specific MNO is activated (S515, S516). Thus, a particular MNO (or SM-DP) will be able to access the 1st ISD using the key shared by itself and the UICC.

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

Upon completion, the SM-SR and the SM-DP have completed changing the security right to a specific MNO, and the MNO becomes able to access the UICC. The 1st ISD is in the post-distribution state, i.e., the SECURED state, in the card life cycle.

6 is a block diagram showing a configuration of an SM-SR 600 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. In the example of FIG. 4, the key shared with the super ISD can be obtained from a UICC vendor.

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 from 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 can transmit the index and key information of the ISD corresponding to the MNO to the super ISD of the UICC and receive a response thereto.

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

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

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.

8 is a block diagram showing a configuration of a terminal 800 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. The super ISD 812 may receive index and key information of the ISDs 814 and 816 to be activated from the SM-SR 812. Before the ISDs 814, 816 are activated, the super ISD 812 may operate as a secure domain. 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.

The control unit 818 can input key information to the ISDs 814 and 816 corresponding to a specific MNO using the index and key information of the ISD received via the super ISD 812. [ In addition, the control unit 818 may change the security domain from the super ISD 812 to the corresponding ISD 814, 816.

The eUICC distributed without assigning the MNO through the above-described method can be subscribed and opened to the specific MNO on 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 (21)

A subscriber management server for communicating the network carrier information to a smart card in cooperation with Subscription Manager-Data Preparation (SM-DP) for generating network carrier information, As a domain authority transfer control method,
Receiving an authorization transfer request signal from a terminal equipped with the smart card;
Requesting a specific network operator for key information of a second security domain through the SM-DP;
Receiving key information of the second security domain from the specific network operator; And
Transmitting the index and key information of the second security domain through the first security domain,
The server is a Subscription Manager-Secure Routing (SM-SR) that shares a key with the first security domain,
Wherein the first security domain and the second security domain are on-card agents of an off-card authority that is a card manager. The method according to claim 1,
Further comprising the step of performing an authentication procedure with the first security domain after the step of receiving the authorization transfer request signal. The method according to claim 1,
Further comprising the step of activating an index of the second security domain after receiving the authorization transfer request signal. The method according to claim 1,
Wherein the second security domain is an Issuer Security Domain (ISD). (Subscriber Manager-Data Preparation) which generates a first security domain that shares a key with the Subscriber Manager-Secure Routing (SM-SR) that manages a smart card, and a Subscriber Manager-Data Preparation A security domain rights transfer method executed on a smart card including a secure domain,
Receiving index and key information of a second security domain corresponding to a network operator to which the smart card is subscribed from the SM-SR through the first security domain;
Inputting key information of a second security domain received in a second security domain corresponding to the network operator; And
Changing a security domain from the first security domain to a second security domain corresponding to the network operator,
Wherein the first security domain and the second security domain are on-card agents of an off-card organization that is a card manager. 6. The method of claim 5,
Further comprising the step of performing an authentication procedure with the SM-SR through the first security domain. 6. The method of claim 5,
Wherein the second security domain is an Issuer Security Domain (ISD). delete delete delete A server which is capable of accessing a first security domain set in the smart card by transmitting the network operator information to a smart card in cooperation with an SM-DP (Subscription Manager-Data Preparation) for generating network operator information,
A key storage unit for storing a key shared with the first security domain of the smart card;
An index storage unit for storing an index of a second security domain of the smart card corresponding to the SM-DP;
A first interface for requesting the network operator for key information of the second security domain through the SM-DP and for receiving key information of the second security domain from the network operator; And
And a second interface for transmitting index and key information of the second security domain to the first security domain and receiving a response signal for transmission,
The server is an SM-SR (Subscription Manager-Secure Routing)
Wherein the first secure domain and the second secure domain are on-card representatives of off-card entities that are card administrators. 12. The method of claim 11,
Wherein the server performs the authentication procedure with the first security domain. 12. The method of claim 11,
Wherein the second security domain is an Issuer Security Domain (ISD). delete delete A first security domain sharing a key with Subscription Manager-Secure Routing (SM-SR) managing a smart card;
One or more second security domains sharing a key with Subscription Manager-Data Preparation (SM-DP) generating network carrier information; And
Receiving the index and key information of the second security domain through the first security domain, inputting the key information into the corresponding second security domain, and transmitting the security domain from the first security domain to the second security domain And a control unit for changing the operation mode
Wherein the first security domain and the second security domain are on-card representatives of off-card organizations that are card administrators. 17. The method of claim 16,
And performs the authentication procedure with the SM-SR through the first security domain. 17. The method of claim 16,
Wherein the second security domain is an Issuer Security Domain (ISD). And a smart card mounted inside,
The smart card includes:
A first security domain sharing a key with an SM-SR (Subscription Manager-Secure Routing) managing the smart card;
One or more second security domains sharing a key with Subscription Manager-Data Preparation (SM-DP) generating network carrier information; And
Receiving the index and key information of the second security domain through the first security domain, inputting the key information into the corresponding second security domain, and transmitting the security domain from the first security domain to the second security domain And a control unit for changing the operation mode
Wherein the first secure domain and the second secure domain are on-card representatives of an off-card agency that is a card manager. 20. The method of claim 19,
And performs the authentication procedure with the SM-SR through the first secure domain. 20. The method of claim 19,
Wherein the second security domain is an Issuer Security Domain (ISD).

Images