KR20130049097A - 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

PURPOSE: A security domain authorization transfer control method of a server, a security domain authorization transfer method of a smart card, a security domain authorization transfer method of a terminal, a server, a smart card and a terminal are provided to open a terminal including an embedded UICC(Universal Integrated Circuit Card) without being restricted by a mobile communication service provider. CONSTITUTION: An SM-SR(Subscription Manager-Secure Routing)(600) includes a super ISD(Issuer Security Domain) key storage unit(610), an ISD index storage unit(620), an SM-DP(Subscription Manager-Data Preparation) interface(630), and a UICC interface(640). The super ISD key storage unit stores a key shared with a first security domain of a smart card. The ISD index storage unit stores an index of a second security domain of a smart card corresponding to a network service provider. The SM-DP interface requests key data of the second security domain to the network service provider and receives the key data of the second security domain from the network service provider. The UICC interface transmits the index and key data of the second security domain to the first security domain and receives a response signal. [Reference numerals] (610) Super ISD key storage unit; (620) ISD index storage unit; (630) SM-DP interface; (640) UICC interface

Description

Security domain authority transfer control method of a server, security domain authority transfer method of a smart card, security domain authority transfer method of a terminal, server, smart card, and terminal {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}

The present invention relates to the transfer of authority of a security domain of a smart card, and more particularly, a server for managing authority transfer of a security domain, a smart card for transferring authority of a security domain, a terminal equipped with the smart card, and It relates to the transfer of 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 may 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 in the case of the Global System for Mobile communications (GSM) scheme, and a Universal Subscriber Identity Module (USIM) card in the case of the Wideband Code Division Multiple Access (WCDMA) scheme.

When the user mounts the UICC on the user's 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 replaces the terminal, the user can easily replace the terminal by mounting the UICC removed from the existing terminal to a 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 mobile operators and terminal manufacturers ordering terminals have no choice but to pay attention to product inventory, which leads to a problem that product prices rise. 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 UICC includes a security domain (SD) for security of an application, and in particular, the Issuer Security Domain (ISD) is a card manager, stores a secret key of an issuer, and a mobile network (MNO). It may be in charge of authentication for CCM (Card Content Management) in the Operator area. However, the ISD is an entity that is dependent on the mobile carrier, and the ISD may be a problem when the user opens the terminal regardless of the mobile carrier.

An object of the present invention is to provide a method and apparatus for opening a terminal including a built-in UICC without regard to a mobile communication provider.

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

Another embodiment of the present invention provides a security domain authorization transfer that is 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 operator. A method comprising: 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 operator.

Another embodiment of the present invention 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 at least one second security domain sharing a key with a network operator. CLAIMS What is claimed is: 1. A security domain authority transfer method, comprising: 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 operator.

Another embodiment of the present invention, 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 a network operator; A first interface for requesting key information of the second security domain from the network operator and receiving key information of the second security domain from the network operator; And a second interface for transmitting the index and key information of the second security domain to the first security domain and receiving a response signal for the transmission.

Another embodiment of the present invention, the key storage unit for storing the key information of the security domain of the smart card corresponding to the network operator; It provides a server including an interface for receiving the key information request signal of the security domain from the external server in communication with the smart card, and transmits the key information of the security domain to the external server.

Another embodiment of the present invention includes a first secure domain for sharing a key with a management server managing a smart card; One or more second secure domains that share a key with the network operator; And receive index and key information of the second security domain through the first security domain, input the key information into a corresponding second security domain, and secure domain from the first security domain to the second security domain. It provides a smart card including a control unit for changing the.

Another embodiment of the present invention includes a smart card mounted therein, wherein the smart card comprises: a first security domain sharing a key with a management server managing the smart card; One or more second secure domains that share a key with the network operator; And receive index and key information of the second security domain through the first security domain, input the key information into a corresponding second security domain, and secure domain from the first security domain to the second security domain. It provides a terminal comprising a control unit for changing the.

According to the present invention described above, the terminal including the built-in UICC can be opened without being tied to the mobile communication provider.

1 shows the structure of a system to which embodiments of the present invention can be applied.
2 is a software hierarchy structure in an eUICC according to an embodiment of the present invention.
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 illustrating a method for transferring MNO target security domain rights through a change from super ISD to ISD according to an embodiment of the present invention.
6 is a block diagram illustrating 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. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are used to refer to the same components as much as possible even if displayed on 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.

The Universal Integrated Circuit Card (UICC) is a smart card used for a mobile terminal in a Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), and Code Division Multiple Access (CDMA) networks. In a GSM network, the 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. UICC consists of CPU, ROM, RAM, EEPROM and I / O circuits.

M2M (Machine-to-Machine) terminal, which is actively discussed in the GSMA (GSM Association), should be small in size.In case of using the existing UICC, a module for mounting the UICC must be separately inserted into the M2M terminal. When manufacturing the M2M terminal in a removable structure, it is difficult to miniaturize the M2M terminal.

Therefore, an embedded UICC (hereinafter referred to as an eUICC) (or an embedded SIM (eSIM)) structure, in which a UICC is not detachable, is discussed. In this case, a movement using a corresponding UICC for an embedded UICC mounted on an M2M terminal is discussed. Mobile Network Operator (MNO) information should be stored in the UICC in the form of International Mobile Subscriber Identity (IMSI).

However, since the terminal manufactured from the time of manufacturing the M2M terminal can be assigned IMSI in the built-in UICC only if the premise that the terminal is used only in a specific MNO is established, both the M2M terminal or the MNO ordering the UICC or the M2M manufacturer manufacturing the M2M terminal have a lot of product inventory. There is a problem that the allocation of nerves and product prices will rise, which is a serious obstacle to the expansion of M2M terminals.

Unlike conventional removable UICC, the eUICC, which is integrally mounted on the terminal, has many problems due to differences in its physical structure such as opening authority, additional service business initiative, and subscriber information security. In particular, since the UICC is soldered to the board of the terminal, a remote provisioning management on the software is required in order to handle the existing subscription opening, authorization, and subscription change.

To this end, international standardization bodies such as the GSMA and the European Telecommunications Standards Institute (ETSI) are conducting standardization activities on relevant elements, including top-level structures, with relevant companies such as carriers, manufacturers and UICC vendors. In addition, GP (GlobalPlatform) is in the process of standardizing the infrastructure for the development, deployment and management of smart cards. At the heart of the issue as the eUICC is discussed through standardization bodies is the entity (or function / role) called Subscriber Manager (hereinafter referred to as 'SM'), where SM is the operator's information (Operator Credential, MNO Credential, Profile, eUICC). It issues overall management of eUICC by issuing Profile, Profile Package, etc.) to eUICC and handling the process of subscription change.

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

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

Referring to FIG. 1, a system to which the present invention may be applied includes a subscription manager (SM) 110, a UICC vendor 120, a device vendor 130, and a service provider ( 140) and a plurality of carriers (MNO1 to MNO3) (150a ~ 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 a process for changing a subscription.

The role of the SM 110 is to generate service provider information, which is classified as a subscription manager-data preparation (SM-DP) and a subscription manager-secure routing (SM-SR) that directly carries the service provider information to the eUICC. Can be. The SM-DP may play a role of safely generating service provider information (IMSI, K, OPc, additional service application, additional service data, etc.) to form a credential package. SM-SR can securely download the credential package generated by SM-DP to eUICC through UICC remote management technology such as OTA (Over-The-Air) or GP Secure Communication Protocol (CP SCP).

More specifically, the SM-DP is responsible for secure preparation of a package to be delivered to the eUICC, and works with the SM-SR for actual transmission. Key features of the SM-DP include 1) managing the functional characteristics and certification levels of the eUICC, 2) MNO credentials (e.g., one or more of IMSI, K, supplementary service applications, supplementary service data, Some of these can potentially be encrypted by the MNO), 3) calculate the OTA package for download by the SM-SR, etc. Additional functionality may be added later.

The SM-DP may be provided by a specific MNO or may be provided by a third TSM (hereinafter referred to as a 3rd TSM). Security and trust relationships become important when provided by 3rd TSM. In addition to real-time provisioning, SM-DP can have a significant amount of background processing, 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. Key features of the SM-SR include: 1) managing eUICC and OTA communication through an encrypted virtual private network (VPN); and 2) managing communication with other SM-SRs to form an end-to-end to the eUICC. 3) managing eUICC data used for SM-SR OTA communication provided by the eUICC provider; and 4) protecting communication with the eUICC by filtering only allowed entities (firewall functions).

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

Meanwhile, the GSMA proposes a structure called the Circle of Trust to establish an end-to-end trust relationship between the MNO and the eUICC through the overlap of trust relationships between similar entities. Suggested. 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 forms a trust relationship with the SM-DP, the SM-DP forms a trust relationship with the Device SM, and the Device SM forms a trust relationship with the terminal, whereby the MNO and the terminal can form a trust relationship. have. Hereinafter, a flow between the MNO, the eUICC, and the terminal may 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 bonded to the terminal by the device vendor 130. The terminal with the embedded eUICC may be provided to the service provider 140.

For provisioning, the UICC vendor 120 and the SM 110 may exchange eUICC identifiers and key data for encryption. For subscription, the service provider 140 and the SM 110 may exchange credentials, and the SM 110 and the MNOs 150a through 150c may exchange credentials. When the subscription is completed, the service provider 140 and the MNOs 150a-150c may maintain the telecom service.

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

The card architecture by the global platform consists of a number of components to ensure the application and off-card management system a hardware- and vendor-neutral interface. Such components may include one or more card issuer applications, one or more applications for the card issuer's business partners (ie, application providers), one or more applications for providing global services (eg, CSM services) to other applications. have.

All applications are implemented within a secure runtime environment that includes a hardware-neutral application programming interface (API) that supports application mobility. The global platform is not limited to any particular runtime environment technology, but is a major card component in which the card manager acts as the central manager. A security management application called a particular 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 surrogate of the off-card authority. SD can be classified into three types by reflecting three types of off-card institutions recognized by the card.

First, the ISD is a major and essential on-card delegate for a card administrator, who is usually the card issuer.

Secondly, the Supplementary SD acts as an additional and optional on-card delegate for the card issuer or application provider or their agent.

As a third type, Control Authority Security Domains (SD) is a special form of secondary SD, which serves to enforce a security policy applied on all application code 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 institution SD.

In general, all three types may simply be referred to as SDs, which are security services such as key handling, encryption, decryption, digital signature generation and verification for their providers (card issuers, application providers, or control authorities, etc.). Support. Each SD is set up on behalf of the card issuer, application provider, or controller when the off-card entities request to use keys that are completely isolated from each other.

There may be one or more global service applications within the card to provide services such as the Cardholder Verification Method (CVM) to other applications on the card.

The global platform is intended to run on a secure, multi-application card runtime environment, which provides secure storage and execution space for the application as well as hardware-neutral APIs for the application, separating each application code and data from other applications. To keep it stable. The runtime environment of the card also provides a communication service between the card and the offcard entity.

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

2,

In eUICC, the software hierarchy includes a hardware layer, a chip OS layer above the hardware layer, a Java card platform layer above the chip OS layer, and a global platform (GP) layer above the Java platform layer.

If the SIM / UICC Application Programming Interface (API) layer exists above the GP layer, and the USIM Application Toolkit (USAT) application framework layer exists above the SIM / UICC API layer, the application layer (App5, App6) above the USAT application framework layer. This exists.

In addition, a super issuer security domain (ISD) layer exists on the GP layer, and an issuer security domain (ISD) layer (ISD1, ISD2) designated for each MNO exists on the super ISD layer. A security domain layer exists above each ISD layer, and application layers App1 to App4 exist above each security domain layer.

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

Each security domain is a privileged application, and may store a security key, provide encryption services to an associated application, and provide a secure channel protocol (SCP).

Each application and each executable load file is associated with a security domain, and the application can use the cryptographic services of the associated security domain.

The secure domain is responsible for its own key management, which allows applications and data from different application providers to coexist on the same card without violating the privacy and integrity of each application provider. In addition, in an embodiment of the present invention, the ISD is responsible for its own key management, whereby applications and data from different MNOs can coexist on the same card without violating the privacy and integrity of each MNO. have.

Keys and associated cryptographic operations for all secure domains can provide secure communication support while personalizing an application provider's application, and enable secure communication during runtime of applications that do not include their own secure messaging keys.

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

The super ISD may select or change a plurality of card managers (ie, ISDs), store a secret key of the ISD, manage its index, and be responsible for authentication for the CCM of the SM-DP area.

Referring to FIG. 2, the super ISD may be in charge of managing the '210' area, and the ISD1 and ISD2 selected according to each MNO may be in charge of managing the '220a' and '220b' areas, respectively.

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

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

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

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

Replacing a 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 old key is no longer valid.

In one embodiment of the present invention, the super ISD key is an eUICC platform connection credential, which is a key that may have authority to access the platform of the eUICC. Even in the eUICC environment, value added services of existing MNOs must be maintained. When the profile is loaded when initially provisioning or when changing the MNO, authorization should be obtained using the eUICC platform access credentials, in which case the super ISD can be used. The GP may provide the capability to accommodate super ISD.

The super ISD may have a key information and key attribute structure similar to the key information and key attribute structure of the ISD. However, the specific key ID and key version number may be allocated exclusively for the purpose of the super ISD key. In the super ISD base, there may be one or more card life cycles in one or more ISD regions.

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

Referring to FIG. 3, the super card life cycle of the UICC managed by the SM-SR in association with the super ISD may have OP_READY, INITIALIZED, SECURED, CARD_LOCKED, and TERMINATED states. The OP_READY state is that the execution environment is available and the super ISD is ready to receive, execute, and react to APDU (Application Protocol Data Unit) commands. The INITIALIZED state is a card creation state. The INITIALIZED state cannot return to the OP_READY state. The SECURED state is a state where card issuance is completed, and the card security is stable. The SECURED state cannot return to the INITIALIZED state. The CARD_LOCKED state is temporarily locked. The contents of the card cannot be changed. The CARD_LOCKED state may return to the SECURED state. The TERMINATED state means that the card is discarded. The contents of the card cannot be changed. The TERMINATED state cannot be returned to another state.

The card life cycle managed by the SM-DP in association with the ISD may have INSTALLED, SECURED, TERMINATED, and CARD_LOCKED states. The INSTALLED state is where the ISD becomes an entity in the GP registry, and that entity can connect to authenticated external entities. The SECURED state is a state where card security is stable. The TERMINATED state is the state in which the ISD associated with a particular MNO is deleted or deactivated. The CARD_LOCKED state is a temporary lock.

There may be more than one such card life cycle in one super card life cycle. That is, when the MNO associated with the terminal 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 these card life cycles are all within the super card life cycle. exist.

The life cycle of an application can have states INSTALLED, SELECTABLE, Applet specific, and LOCKED. The INSTALLED state is where the application executable code is properly linked and the necessary memory allocation has been made. The SELECTABLE state allows the application to receive commands from external entities. The applet specific state is the state in which the behavior of the application is determined by the application itself. The LOCKED state is a temporary lock.

The life cycle of a secure domain can have states INSTALLED, SELECTABLE, PERSONALIZED, and LOCKED. The INSTALLED state is where the security domain becomes an object in the GP Registry and these objects can connect to authenticated external objects. The SELECTABLE state allows the security domain to receive commands from external entities. The PERSONALIZED state is where the security domain has all the necessary personalization data and keys for execution. The LOCKED state is a temporary lock.

4 illustrates a pre-provisioning method of an eUICC according to an embodiment of the present invention.

Referring to FIG. 4, initially, an SM-SR related to a specific MNO or 3rd TSM is in a state of managing ISD index lists for a plurality of MNOs.

The UICC vendor (or UICC SM) delivers the produced UICC to the device vendor, and the device vendor mounts the UICC on the device (terminal) (S401). The terminal (or device SM) requests preliminary provision of the mounted UICC to the SM-DP of a specific MNO among a plurality of MNOs (S402). In this case, the information provided by the terminal may include a model of the device and UICC information.

The SM-DP requests information for initial provision from the SM-SR (S403). The SM-SR requests information for providing an initial UICC from 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, Ki, and a mobile subscriber integrated services digital network number (MSSIS).

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

Once this process is complete, the SM-SR is pre-provisioned for the UICC of the particular MNO. In addition, SM-DP and Device SM are pre-provisioned with a network of a specific MNO (for example, 3G network. Currently, UICC is a right that only SM-SR which receives information from UICC vendor can access through Super ISD. The M-NO's SM-DP does not have this authority.

FIG. 5 is a flowchart illustrating a method for transferring MNO target security domain rights through a change from super ISD to ISD according to an embodiment of the present invention. This process may be performed in the opening process of the terminal.

The UICC includes a SKM (Super Key Manager) object for managing super keys. The SKM may have a super ISD region, a plurality of ISD regions (1st ISD, 2nd ISD, etc.), and an SKM application region. The plurality of ISDs (1st ISD, 2nd ISD, etc.) corresponds to the plurality of MNOs. The SM-DP shown in FIG. 5 is an entity corresponding to 1st ISD.

The terminal equipped with the UICC may have a device SM application.

In the initial state, the SM-SR is a Pre-Provision state for the UICC of a particular MNO. SM-DP is pre-provisioned in the network of a specific MNO. Super ISD, 1st ISD, and 2nd ISD in SKM in UICC are in a Pre-Issuance state in the super card life cycle shown in FIG. 3. In addition, the SKM application and device SM application are pre-provisioned in the network of a particular MNO.

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

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

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

The SM-SR transfers the ISD index and ISD key information of a specific MNO to the super ISD to make a put key request (S507). The ISD index and / or ISD key information of a specific MNO may be encrypted using a key shared between the SM-SR and the super ISD. The super ISD requests the SKM application to inject the ISD index and ISD key information of a 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 the specific MNO using the ISD key information of the specific MNO based on the ISD index (S509). The 1st ISD notifies the SM-SR of the generated result 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 a specific MNO (S511). The SKM application instructs the 1st ISD to change the security domain state to the ISD of the specific MNO (S512), and also to the super ISD to change the security domain state to the ISD of the specific MNO (S513). The super ISD responds with the Put Key result together with the changed security domain state (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) can access the 1st ISD using a key shared between itself and the UICC.

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

At the time of completion, the SM-SR and SM-DP have completed changing the security rights to a particular MNO, and the MNO can access the UICC. The 1st ISD is post-distributed in the card life cycle, i.e. in the SECURED state.

6 is a block diagram illustrating 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 610, an ISD index storage 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 the UICC vendor.

The ISD index storage unit 620 stores the 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 may request 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 an authentication procedure with the super ISD of the UICC. The UICC interface 640 may transmit index and key information of the ISD corresponding to the MNO to the super ISD of the UICC, and may receive a response thereto.

7 is a block diagram illustrating a configuration of the 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 mounted on the terminal opened in the MNO. Thus, the MNO can provide services through the eUICC.

The SM-SR interface 720 may receive a key information request signal from the SM-SR and transmit key information to the SM-SR.

8 is a block diagram showing the 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) 810.

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

The super ISD 812 may 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. Super ISD 812 can act as a secure domain before ISD 814 and 816 are activated. The super ISD 812 may receive index and key information of an ISD to be activated corresponding to a specific MNO from the SM-SR.

ISDs 814 and 816 may be activated corresponding to specific MNOs. The activated ISDs 814 and 816 can receive service from the MNO using the keys of the ISD.

The controller 818 may input key information into the ISDs 814 and 816 corresponding to the specific MNO using the index and key information of the ISD received through the super ISD 812. In addition, the controller 818 may change the security domain from the super ISD 812 to the corresponding ISDs 814 and 816.

The eUICC distributed without specifying the MNO in the above-described manner may be subscribed to a specific MNO through software.

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

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 protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of the present invention.

Claims (21)

A security domain rights transfer control method executed in a server that can access a first security domain set in a smart card,
Receiving an authority transfer request signal from a terminal equipped with the smart card;
Requesting key information of a second security domain from a specific network operator;
Receiving key information of the second security domain from the specific network operator; And
And transmitting index and key information of the second security domain through the first security domain. The method of claim 1,
And after the receiving of the authority transfer request signal, performing an authentication procedure with the first security domain. The method of claim 1,
And after receiving the authority transfer request signal, activating an index of the second security domain. The method of claim 1,
And the second security domain is an Issuer Security Domain (ISD). A security domain delegation method 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 operator.
Receiving 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 from the management server;
Inputting key information of a second security domain received in a second security domain corresponding to the network operator; And
Changing the security domain from the first security domain to a second security domain corresponding to the network operator. The method of claim 5, wherein
And performing an authentication procedure with the management server through the first security domain. The method of claim 5, wherein
And the second security domain is an Issuer Security Domain (ISD). A security domain rights transfer method 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 at least one second security domain sharing a key with a network operator.
Receiving 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 from the management server;
Inputting key information of a second security domain received in a second security domain corresponding to the network operator; And
And changing the security domain from the first security domain to a second security domain corresponding to the network operator. The method of claim 8,
And performing an authentication procedure with the management server through the first security domain. The method of claim 8,
The second security domain is an ISD (Issuer Security Domain) characterized in that the security domain authority transfer method of the terminal. 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 a network operator;
A first interface for requesting key information of the second security domain from the network operator and 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 method of claim 11,
And the server performs an authentication procedure with the first secure domain. The method of claim 11,
And wherein the second security domain is an Issuer Security Domain (ISD). A key storage unit for storing key information of a security domain of a smart card corresponding to a network operator;
And an interface configured to receive a key information request signal of the security domain from an external server communicating with the smart card and to transmit key information of the security domain to the external server. 15. The method of claim 14,
The security domain is a server, characterized in that the Issuer Security Domain (ISD). A first secure domain for sharing a key with a management server managing a smart card;
One or more second secure domains that share a key with the network operator; And
Receive index and key information of the second security domain through the first security domain, input the key information into a corresponding second security domain, and secure the security domain from the first security domain to the second security domain. Smart card including a control unit for changing. 17. The method of claim 16,
Smart card, characterized in that for performing the authentication procedure with the management server through the first secure domain. 17. The method of claim 16,
The second security domain is an smart card, characterized in that the Issuer Security Domain (ISD). Includes a smart card mounted inside,
The smart card,
A first security domain sharing a key with a management server managing the smart card;
One or more second secure domains that share a key with the network operator; And
Receive index and key information of the second security domain through the first security domain, input the key information into a corresponding second security domain, and secure the security domain from the first security domain to the second security domain. And a control unit for changing the terminal. The method of claim 19,
And performing an authentication procedure with the management server through the first security domain. The method of claim 19,
And wherein the second security domain is an Issuer Security Domain (ISD).

Images