WO2013065982A1 - Method for transferring rights to security domain for smartcard, and server, smartcard, and terminal for same - Google Patents

Method for transferring rights to security domain for smartcard, and server, smartcard, and terminal for same Download PDF

Info

Publication number
WO2013065982A1
WO2013065982A1 PCT/KR2012/008678 KR2012008678W WO2013065982A1 WO 2013065982 A1 WO2013065982 A1 WO 2013065982A1 KR 2012008678 W KR2012008678 W KR 2012008678W WO 2013065982 A1 WO2013065982 A1 WO 2013065982A1
Authority
WO
WIPO (PCT)
Prior art keywords
security domain
key
isd
sm
smart card
Prior art date
Application number
PCT/KR2012/008678
Other languages
French (fr)
Korean (ko)
Inventor
허국
이진형
윤여민
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to KR1020110114149A priority Critical patent/KR101937486B1/en
Priority to KR10-2011-0114149 priority
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Publication of WO2013065982A1 publication Critical patent/WO2013065982A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0853Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using an additional device, e.g. smartcard, SIM or a different communication terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements, e.g. access security or fraud detection; Authentication, e.g. verifying user identity or authorisation; Protecting privacy or anonymity ; Protecting confidentiality; Key management; Integrity; Mobile application security; Using identity modules; Secure pairing of devices; Context aware security; Lawful interception
    • H04W12/002Mobile device security; Mobile application security
    • H04W12/0023Protecting application or service provisioning, e.g. securing SIM application provisioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements, e.g. access security or fraud detection; Authentication, e.g. verifying user identity or authorisation; Protecting privacy or anonymity ; Protecting confidentiality; Key management; Integrity; Mobile application security; Using identity modules; Secure pairing of devices; Context aware security; Lawful interception
    • H04W12/04Key management, e.g. by generic bootstrapping architecture [GBA]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/18Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Abstract

The present invention relates to transferring rights to a security domain for a smartcard, and more specifically, to a server for managing the transferring of rights to a security domain, a smartcard for the transferring of rights to the security domain, a terminal which is loaded with the smartcard, and to a method for the transferring of rights.

Description

Method of transferring security domain authority of smart card and server, smart card, and terminal for it

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 that can be inserted into a terminal and used as a module for user authentication. The UICC may store the personal information of the user and the operator information on the mobile communication provider 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.

Terminals requiring miniaturization, for example, terminals for machine-to-machine (M2M) communication, have difficulty in miniaturization of terminals when manufactured in a structure capable of detachable UICC. Thus, an embedded UICC (Embedded UICC) structure has been proposed, which is a removable UICC. In the built-in UICC, user information using the UICC should be recorded in IMSI format.

The existing UICC can be attached to or detached from the terminal, and the user can open the terminal regardless of the type of terminal or the mobile communication provider. However, from the time of manufacturing the terminal, the manufactured terminal can be assigned an IMSI in the embedded UICC only when the premise that the terminal is used only for a specific mobile communication provider is satisfied. 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 to change the mobile operator for the terminal. Therefore, even in the case of the built-in UICC, a method for allowing a user to open the terminal regardless of the mobile communication 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.

One embodiment of the present invention, the transfer of security domain rights executed in a smart card including a first security domain sharing a key with a management server managing the 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, 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 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 illustrating a 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 the accompanying drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are assigned to the same components as much as possible even though they are shown in different drawings. In addition, in describing the present invention, when it is determined that the detailed description of the related well-known configuration or function may obscure the gist of the present invention, the detailed description thereof will be omitted.

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 manufacturing M2M manufacturer have a lot of 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 specific 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 an embedded form, and thus has advantages.

The above description is merely illustrative of the technical idea of the present invention, and those skilled in the art to which the present invention pertains may make various modifications and changes without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are not intended to limit the technical idea of the present invention but to describe the present invention, and the scope of the technical idea of the present invention is not limited thereto. 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.

CROSS-REFERENCE TO RELATED APPLICATION

This patent application claims priority under No. 10 (2011) 141 (a) (35 USC § 119 (a)) of the Patent Application No. 10-2011-0114149 filed to Korea on 3 November 2011. All content is incorporated by reference in this patent application. In addition, if this patent application claims priority for the same reason for countries other than the United States, all its contents are incorporated into this patent application by reference.

Claims (12)

  1. 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.
  2. The method of claim 1,
    Smart card, characterized in that for performing the authentication procedure with the management server through the first secure domain.
  3. The method of claim 1,
    The second security domain is an smart card, characterized in that the Issuer Security Domain (ISD).
  4. 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.
  5. The method of claim 4, wherein
    And performing an authentication procedure with the management server through the first security domain.
  6. The method of claim 4, wherein
    And the second security domain is an issuer security domain (ISD).
  7. 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.
  8. The method of claim 7, wherein
    And the server performs an authentication procedure with the first secure domain.
  9. The method of claim 7, wherein
    And the second security domain is an Issuer Security Domain (ISD).
  10. 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 one or more second security domains sharing a key with a carrier.
    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 a security domain from the first security domain to a second security domain corresponding to the network operator.
  11. The method of claim 10,
    And performing an authentication procedure with the management server through the first security domain.
  12. The method of claim 10,
    And the second security domain is an Issuer Security Domain (ISD).
PCT/KR2012/008678 2011-11-03 2012-10-22 Method for transferring rights to security domain for smartcard, and server, smartcard, and terminal for same WO2013065982A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020110114149A KR101937486B1 (en) 2011-11-03 2011-11-03 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
KR10-2011-0114149 2011-11-03

Publications (1)

Publication Number Publication Date
WO2013065982A1 true WO2013065982A1 (en) 2013-05-10

Family

ID=48192289

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/008678 WO2013065982A1 (en) 2011-11-03 2012-10-22 Method for transferring rights to security domain for smartcard, and server, smartcard, and terminal for same

Country Status (2)

Country Link
KR (1) KR101937486B1 (en)
WO (1) WO2013065982A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100437513B1 (en) * 2004-02-09 2004-06-16 주식회사 하이스마텍 Smart card for containing plural Issuer Security Domain and Method for installing plural Issuer Security Domain in a smart card
KR20090026901A (en) * 2007-09-11 2009-03-16 주식회사 케이티프리텔 System for managing smart card and method thereof
KR20100028922A (en) * 2008-09-05 2010-03-15 에스케이 텔레콤주식회사 System and method for managing multi smart card web server
WO2010123890A1 (en) * 2009-04-20 2010-10-28 Interdigital Patent Holdings, Inc. System of multiple domains and domain ownership
KR20100121038A (en) * 2009-05-08 2010-11-17 주식회사 하이스마텍 Smart card having multi-scws, method thereof and mobile equipment using the same

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100437513B1 (en) * 2004-02-09 2004-06-16 주식회사 하이스마텍 Smart card for containing plural Issuer Security Domain and Method for installing plural Issuer Security Domain in a smart card
KR20090026901A (en) * 2007-09-11 2009-03-16 주식회사 케이티프리텔 System for managing smart card and method thereof
KR20100028922A (en) * 2008-09-05 2010-03-15 에스케이 텔레콤주식회사 System and method for managing multi smart card web server
WO2010123890A1 (en) * 2009-04-20 2010-10-28 Interdigital Patent Holdings, Inc. System of multiple domains and domain ownership
KR20100121038A (en) * 2009-05-08 2010-11-17 주식회사 하이스마텍 Smart card having multi-scws, method thereof and mobile equipment using the same

Also Published As

Publication number Publication date
KR101937486B1 (en) 2019-01-11
KR20130049097A (en) 2013-05-13

Similar Documents

Publication Publication Date Title
JP5942011B2 (en) System for managing a plurality of subscriber information in UICC
CN102204299B (en) Method for securely changing mobile device from old owner to new owner
US8156231B2 (en) Remote access system and method for enabling a user to remotely access terminal equipment from a subscriber terminal
EP1687953B1 (en) Method for the authentication of applications
KR101500825B1 (en) Wireless network authentication apparatus and methods
US9100810B2 (en) Management systems for multiple access control entities
US9419970B2 (en) Electronic access client distribution apparatus and methods
FI108769B (en) Connecting an access point in a wireless communication system
US8983543B2 (en) Methods and apparatus for managing data within a secure element
US9043898B2 (en) Access management system
RU2507710C2 (en) Method of receiving access control client, method of modifying device operating system, wireless device and network device
US20090253409A1 (en) Method of Authenticating Home Operator for Over-the-Air Provisioning of a Wireless Device
US7644272B2 (en) Systems and methods for providing security to different functions
US9451459B2 (en) Certification method using an embedded UICC certificate, provisioning and MNO changing methods using the certification method, embedded UICC therefor, MNO system, and recording medium
KR20120005411A (en) Method of performing a secure application in an nfc device
US9049597B2 (en) Telecommunications device security
KR101374810B1 (en) Virtual subscriber identity module
US9098714B2 (en) Policy-based techniques for managing access control
RU2391796C2 (en) Limited access to functional sets of mobile terminal
US20060089123A1 (en) Use of information on smartcards for authentication and encryption
EP2341659B1 (en) Key distribution method and system
KR101527550B1 (en) Personalizing a sim by means of a unique personalized master sim
US7860486B2 (en) Key revocation in a mobile device
JP4570620B2 (en) Method and system for registration of licensing modules in a mobile device
EP2741548B1 (en) Method for changing mno in embedded sim on basis of dynamic key generation and embedded sim and recording medium therefor

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12845485

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12845485

Country of ref document: EP

Kind code of ref document: A1