KR20200085260A - Method and apparatus for setting profile - Google Patents

Abstract

The present specification relates to a method and an apparatus for a setting profile. The method for setting the profile according to one embodiment of the specification includes: a step of receiving a profile transfer request which requests transfer of at least a part of a first profile from a first security module to a second security module; a step of transmitting a request message for requesting at least a part of the first profile to the first security module; a step of receiving at least a part of the first profile from the first security module; a step of configuring a second profile using at least a part of the received first profile; a step of transmitting the second profile to the second security module; a step of transmitting a message requesting to update a security value corresponding to the second profile to an authentication center (AuC), when the second profile is installed in the second security module; a step of transmitting a message requesting to delete the first profile when the AuC updates the security value corresponding to the second profile; a step of transmitting a message requesting to delete the second profile when the AuC fails to update the security value corresponding to the second profile; and a step of transmitting a message requesting the AuC to recover K to the value before the update when the AuC fails to update the security value corresponding to the second profile.

Description

Profile setting method and device {METHOD AND APPARATUS FOR SETTING PROFILE}

This specification relates to a method and apparatus for setting a profile stored in a terminal.

UICC (Universal Integrated Circuit Card) is a smart card that is inserted into a terminal and used. The UICC stores personal information such as network access authentication information of the mobile communication subscriber, phone book, and short message. When a terminal accesses a mobile communication network such as Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA), or Long Term Evolution (LTE), UICC performs subscriber authentication and traffic security key generation to use secure mobile communication. Makes it possible. UICC is equipped with communication applications such as Subscriber Identity Module (SIM), Universal Subscriber Identity Module (USIM), and IP Multimedia Services Identity Module (ISIM) according to the type of mobile communication network to which the subscriber accesses. In addition, UICC provides high-level security functions for loading various application applications such as e-wallets, ticketing, and e-passports.

The conventional UICC is manufactured as a dedicated card for the corresponding operator at the request of a specific mobile communication operator when the card is manufactured. In the conventional UICC, authentication information (eg, a USIM application, an International Mobile Subscriber Identity (IMSI), and a K (key) value) for network access of a corresponding operator is preloaded and shipped. Accordingly, the mobile communication provider receives the manufactured UICC and provides it to the subscriber, and then, if necessary, manages the installation, modification, and deletion of applications in the UICC by utilizing technologies such as OTA (Over The Air). The subscriber can use the mobile operator's network and application service by inserting the UICC in the owned terminal. When the subscriber replaces the terminal, the UICC is moved from the existing terminal to the new terminal, so that the authentication information stored in the corresponding UICC, mobile communication phone number, personal phone book, etc. can be used as it is in the new terminal.

The UICC maintains international compatibility by the European Telecommunications Standards Institute (ETSI) defining its physical shape and logical function. In terms of the form factor that defines the physical shape, from the most widely used mini SIMs to micro SIMs that have been in use a few years ago, to nano SIMs recently The size is getting smaller. Through this, it contributes a lot to the miniaturization of the terminal, but it is expected that the UICC card, which is smaller than the recently established Nano SIM, will be difficult to standardize due to the user's loss concerns, and is detachable from the terminal due to the nature of the removable UICC card. It is expected that further miniaturization is difficult because space is needed to mount the slot.

Also, in various installation environments such as intelligent home appliances, electricity/water meters, and CCTV (Closed Circuit Television) cameras, a removable UICC card is installed on M2M (Machine-to-Machine) devices that require access to a mobile communication data network without direct manipulation by a person. This is not suitable.

In order to solve this problem, a method of replacing a conventional removable UICC by embedding a security module performing a function of the UICC or a similar function into the terminal when manufacturing the terminal, is emerging. However, such a security module is mounted so that it is not detachable inside the terminal when manufacturing the terminal. Therefore, unless the terminal is manufactured as a terminal dedicated to a specific mobile operator, network connection authentication information of a specific mobile operator such as IMSI and K of USIM cannot be preloaded when the terminal is manufactured. In addition, the authentication information can be set only after the user who purchases the terminal subscribes to a specific mobile communication provider.

In addition, unlike the conventional UICC card, which was manufactured and distributed exclusively for a specific mobile communication operator, the newly introduced terminal built-in security module allows a user who purchases the terminal to subscribe to, cancel the subscription to, or other carrier. As a result of changing subscription, etc., it should be possible to safely and flexibly install and manage authentication information of various mobile communication providers. In addition, it should be possible to safely move installed authentication information and stored user data to a new terminal according to various usage scenarios, such as when a user purchases a new terminal.

Some embodiments of the present specification may provide an effective profile setting method.

According to an embodiment of the present disclosure, in the method performed by the profile server, a first message requesting to move some or all of the first profile from the first module of the first terminal to the second module of the second terminal Receiving from the first terminal; Creating a second profile using some or all of the first profile; And it may provide a method comprising the step of transmitting the second profile to the second terminal.

According to some embodiments of the present specification, a profile may be effectively set.

1 is a configuration diagram of a communication system according to an embodiment of the present specification.
2 is a flowchart of a profile setting process according to an embodiment of the present specification.
3 shows a data configuration in a terminal according to an embodiment of the present specification.
4 is a flowchart of a profile activation process according to an embodiment of the present specification.
5 is a flowchart of a profile setting process according to the first embodiment of the present specification.
6 is a flowchart of a profile setting process according to a second embodiment of the present specification.
7 is a block diagram of a profile provider according to some embodiments of the present specification.
8 is a block diagram of a profile manager according to some embodiments of the present specification.
9 is a block diagram of a terminal according to some embodiments of the present specification.

Hereinafter, embodiments of the present specification will be described in detail with reference to the accompanying drawings.

In describing the embodiments, descriptions of technical contents that are well known in the technical field to which this specification belongs and are not directly related to the specification will be omitted. This is to more clearly communicate the gist of the present specification by omitting unnecessary description.

For the same reason, some components in the accompanying drawings are exaggerated, omitted, or schematically illustrated. Also, the size of each component does not entirely reflect the actual size. The same reference numbers are assigned to the same or corresponding elements in each drawing.

1 is a configuration diagram of a communication system according to an embodiment of the present specification.

The communication system according to an embodiment of the present specification includes a terminal (105, 106), a terminal embedded security module (eSE) embedded in the terminal (105, 106) (107,108), a profile provider (Profile Provider) ( 102), Profile Managers (103, 104), and an address search server 111. According to an embodiment, the address search server 111 may be omitted.

The security modules 107 and 108 collectively refer to security modules that can be attached to the boards of the terminals 105 and 106 in a chip form or embedded in other ways, and the embedded UICC (eUICC) is also a type of security module embedded in the terminal. to be. Profiles 109 and 110 are installed in the software form in the terminal embedded security modules 107 and 108. The profiles 109 and 110 are software packages containing information corresponding to one or more existing removable UICCs. For example, the profile may be defined as a software package including all of user data information such as one or more applications and subscriber authentication information and a phone book contained in one existing UICC.

The profile provider 102 may be operated directly by a mobile network operator (MNO), or may be operated by another entity in full trust with the mobile operator. The profile provider 102 plays a role of generating and encrypting a profile for a subscriber who subscribes to the corresponding mobile operator, and delivering the encrypted profile to the profile managers 103 and 104. The profile provider 102 may be implemented, for example, in the form of a profile providing server.

The profile managers 103 and 104 perform profile management for specific terminal embedded security modules 107 and 108. Due to the technical characteristics of the security module based on the smart card, before the terminals 105 and 106 are sold to the user (usually when manufacturing the terminals 105 and 106), the same value of the security key information is on both sides (terminal built-in security module (105, 106) and the profile managers (103, 104), so the profile managers (103, 104) are expected to be operated by the manufacturer of the terminal embedded security modules (105, 106) or by the terminal manufacturer. . The profile managers 103 and 104 may be implemented, for example, in the form of a profile management server.

The profile managers 103 and 104 securely transmit the encrypted profile received from the profile provider 102 to the corresponding terminal embedded security modules 107 and 108 so that the corresponding profile is installed. After the decryption and installation of the profile in the security modules 107 and 108 is completed, the profile managers 103 and 104 may perform profile management roles such as activation, deactivation, backup, and removal of the profile. A plurality of profiles may be installed in one terminal built-in security module 107 or 108 depending on the status of the mobile terminal subscription of the terminal. In this case, any of the installed profiles when the terminals 105 or 106 access the mobile communication network Is selected and used.

2 is a flowchart of a profile setting process according to an embodiment of the present specification.

2, after receiving a request to move a profile from the first terminal embedded security module 107 to the second terminal embedded security module 108, the profile information of the first terminal embedded security module 107 is backed up, The profile is reconfigured so that it can be installed in the second terminal embedded security module 108, and the reconfigured profile is installed in the second terminal embedded security module 108, and accordingly according to the installation result and the AuC (Authentication Center) update result. Represents the process by which processing is executed.

In step 202, the profile provider 102 or the profile manager 103 receives a profile movement request from the user or user terminal. The profile movement request message may include an identifier of the first terminal 105 or the first terminal embedded security module 107 and an identifier of the second terminal 106 or the second terminal embedded security module 108. When a plurality of profiles exist in the first terminal embedded security module 107, the profile movement request message is a profile identifier, MSISDN (Mobile Subscriber Integrated Services Digital Network-Number; phone number), to indicate a specific profile to be moved, Or it may further include one or more of the Subscriber Authentication Module Identifier (IMSI). Thereafter, the profile-manager 103 transmits a profile backup request message to the first terminal 105.

Thereafter, in step 203, the first profile 109 installed in the first terminal embedded security module 107 is encrypted and transmitted to the profile providing server and backed up. At this time, the first terminal 105, for example, the first terminal embedded security module 107 may encrypt the first profile 109 using the public key of the profile provider 102 certificate. Alternatively, according to a modified example, the first terminal built-in security module 107 of the first terminal 105 directly generates a symmetric key for encryption/decryption and encrypts and transmits the first profile 109 using the symmetric key for encryption/decryption. Then, the symmetric key value for encryption/decryption may be encrypted with the public key of the profile provider 102 certificate and transmitted to the profile provider 102.

In this case, the first terminal 105 may encrypt and transmit the entire contents of the first profile 109. According to a modified example, the first terminal 105 may encrypt and transmit only user data, such as the phonebook, excluding values such as the authentication key (K) of the USIM, which is particularly sensitive to security, among the contents of the first profile 109. . In this case, the contents not transmitted can be added in step 204, which will be described later by the profile provider 102. According to another modified example, a user may select a target to be moved to the second terminal built-in security module 108 among applications and data included in the first profile 109, if necessary.

3 shows a data configuration in a terminal according to an embodiment of the present specification.

Referring to FIG. 3, the terminal 300 holds the terminal identifier 302. The eSE 310 embedded in the terminal 300 holds the eSE identifier 303. The eSE 310 stores the profile 320.

Profile 320 includes a profile identifier 304. The USIM 330 is stored in the profile 320. USIM 330 stores IMSI 307 and K 308. In addition, the profile 320 further includes additional values 305 and 306 so as not to operate when the corresponding profile 320 is abnormally copied/copied to another terminal embedded security module. First, the profile 320 may further include an identifier (eSE ID) 305 of the terminal embedded security module to which the user 320 will be installed. The terminal ID may be used instead of the eSE ID 305 or the terminal ID may be used together with the eSE ID 305. Also, a combination of the terminal identifier and the eSE ID 305 may be utilized. Hereinafter, an example in which only the eSE ID 305 is used for convenience of description will be described.

Profile 320 may also include a signature value 306. If the value of the terminal embedded security module identifier 305 is modulated by a third party or the USIM 330 is duplicated abnormally for abnormal duplication to another terminal embedded security module, the signature value 306 is immediately identified. This is possible. The signature value 306 is determined by the profile provider for the profile identifier 304, the terminal embedded security module identifier and/or terminal identifier value 305, the IMSI 307 and/or K 308 of the USIM 330. It can be created by performing a digital signature.

For example, the signature value 306 may be generated by the following equation.

<mathematical formula>

Signature value(306) = RSAwithSHA1( Profile ID(304) | eSE ID(305) | IMSI(307))

According to the method of utilizing all of the profile identifier 304, eSE ID 305, and IMSI 307 to generate the signature value 306, abnormal replication and USIM of the profile 320 through the signature value 306 check 330) can all be prevented.

According to a modified example, only the profile identifier 304 and the eSE ID 305 can be used to generate the signature value 306 for generating the signature value 306. For example, the signature value 306 may be generated by the following equation.

<mathematical formula>

Signature value (306) = RSAwithSHA1( Profile ID(304) | eSE ID(305))

In this case, the abnormal replication of the profile 320 can be prevented, but the abnormal replication of the USIM 330 cannot be prevented.

According to another variant, only the profile identifier 304 and the IMSI 307 can be utilized for generating the signature value 306 for generating the signature value 306. For example, the signature value 306 may be generated by the following equation.

<mathematical formula>

Signature value (306) = RSAwithSHA1(Profile ID(304) | IMSI(307))

In this case, the abnormal replication of the USIM 330 can be prevented, but the abnormal replication of the profile 320 cannot be prevented.

4 is a flowchart of a profile activation process according to an embodiment of the present specification. The terminal 300 activates the profile according to the process of FIG. 4, and detects an abnormal copy of the profile and/or the USIM according to the process.

In step 402, the terminal embedded security module 310 selects a profile. For example, when a user selects a specific profile using the touch screen or a keypad of the terminal, the terminal embedded security module 310 may select the profile accordingly. According to another example, the terminal built-in security module 310 may automatically select a profile after the terminal 300 is booted or switched from the airplane mode to a mode using communication. According to other methods, the terminal embedded security module 310 selects at least one of the stored profiles.

In step 403, the terminal embedded security module 310 verifies whether the value of the terminal embedded security module identifier in the selected profile is correct. As described above, the terminal identifier may be used instead of the terminal embedded security module identifier, or a combination of the terminal embedded security module identifier and the terminal identifier may be used.

As a result of the verification, if the security module identifier value in the terminal is incorrect, the process proceeds to step 404. In step 404, the terminal embedded security module 310 does not use the selected profile. The terminal embedded security module 310 may discard the selected profile. Subsequently, the terminal embedded security module 310 may repeat the same process by selecting a different profile. However, a profile with a wrong identifier is not used as a result of verification. As a result of the verification, if the security module identifier value in the terminal is correct, the process proceeds to step 405.

In step 405, the terminal embedded security module 310 verifies the signature value in the profile. If the signature value is verified to be correct, the process proceeds to step 406, where the terminal embedded security module 310 uses the corresponding profile. If it is determined that the signature value is wrong, the process proceeds to step 404. Similarly, the terminal embedded security module 310 may discard the corresponding profile without using it (404).

Returning to FIG. 2, in step 204, the profile provider 102 reconstructs the second profile 110 using the received data of the first profile 109.

When using the illegal copy prevention function described above with reference to FIGS. 3 and 4, the profile provider 102 identifies the identifier value of the first terminal embedded security module 107 of the first profile 190 for reconfiguring the profile of step 204 Is replaced with the identifier value of the second terminal built-in security module 108, and the signature value must also be re-generated with the appropriate value to reconstruct the profile.

In addition, when the reconfigured second profile 110 is successfully installed in the second terminal embedded security module 108, the first profile previously installed in the first terminal embedded security module 107 may not be deleted or used. Should be dealt with. If the first profile 109 is not deleted due to a technical error or malicious intention, in order to prevent abnormal use of the first profile 109, in step 204, the profile provider 102 has a second terminal built-in security module A second profile may be generated by using the USIM authentication key K value of the second profile 110 to be installed in. The K value of the second profile 110 may be different from the K value of the first profile 109. In addition, the profile provider 102 may transmit a request message requesting the AuC of the corresponding carrier to update the K value of the first profile 109 to the K value of the second profile 110. Accordingly, AuC can update the K value corresponding to the profile. Therefore, even if the first profile 109 installed in the first terminal built-in security module 107 is not deleted, the K value of AuC has been changed so that the first terminal 105 uses the USIM of the first profile 109. It becomes impossible to connect to the 3GPP network. When the AuC receives a request for permission to access based on the first profile 109 from the first terminal 105, it attempts authentication using the K value stored in the AuC, and in this case, the K value stored in the AuC is stored in the second profile 110. Although updated to a corresponding value, the first terminal 105 attempts to connect using a conventional K value, so the connection fails.

The second profile 110 reconstructed in step 205 is installed in the second terminal built-in security module 108. The installation results are delivered to the profile providers 102 and the profile managers 103 and 104.

If the installation result is unsuccessful, the process ends. Therefore, the first profile 109 installed in the first terminal 105 is maintained as it is and is maintained in a state before requesting to move the profile.

On the other hand, if the installation result of the second profile 110 is successful, the process proceeds to step 206. In step 206, the profile provider 102 sends a request to update the K value to the AuC. AuC performs K value update and provides the update result to the profile provider 102.

If the update result is successful, the process proceeds to step 208 where the profile provider 102 sends a message requesting the first terminal 105 to delete the first profile 109. Accordingly, the first terminal 105 deletes the first profile 109. As described above, even if the first profile 109 is not deleted due to an error or malicious intention in step 208, since the AuC completes the K value update in step 206, the first profile 109 is accessed. It is impossible.

On the other hand, if the AuC update process fails in step 206, the process proceeds to step 207. In step 207, the profile provider 102 transmits a message requesting the second terminal 106 to delete the second profile 110. Upon receiving this message, the second terminal 106 deletes the second profile 110 and returns to a state before the profile movement is requested. Also, even if the second profile 110 is not deleted from the second terminal 106 due to an error or malicious intention, the update process of AuC is not properly performed in step 206, so the communication network using the second profile 110 is not performed. It is impossible to connect to.

Through the above process, it is possible to safely move the profile from the first terminal 105 to the second terminal 106, and if a failure occurs at any one of the intermediate steps during the movement, it is returned to the original state again. Transaction processing is guaranteed.

5 is a flowchart of a profile setting process according to the first embodiment of the present specification.

The embodiment of FIG. 5 may be performed in the system of FIG. 1. In step 505, the MNO 502 receives a profile movement request message from the user 500. As described above with reference to FIG. 2, the profile movement request message is the identifier of the first terminal 105 or the first terminal embedded security module 107, the second terminal 106 or the second terminal embedded security module 108. It may include an identifier. When a plurality of profiles exist in the first terminal embedded security module 107, the profile movement request message may further include one or more of a profile identifier, MSISDN, or IMSI to indicate a specific profile to be moved.

In step 510, the MNO 502 and the user 500 perform user authentication. This is a procedure to block requests from invalid users. If the user authentication is successful, the subsequent process is performed.

In step 515, the MNO 502 delivers the received profile movement request message to the profile provider 102.

In step 520, the profile provider 102 searches the address search server 111 to search the address of the profile manager for the first terminal built-in security module 107 of the first terminal 105 where the profile to be moved is currently stored. ). Instead of the address search server 111, other types of address search interfaces or address storage devices may be used. The address search server 111 may be implemented in the form of a distributed server such as a Domain Name Service (DNS) server. A variation example in which the profile provider 102 directly stores and manages an address corresponding to each terminal embedded security module may be considered. In this case, the profile provider 102 can obtain the address of the first profile manager 103 without external communication. Here, the address may take the form of an IP address and/or a domain address, for example.

In step 525, the profile provider 102 sends a profile backup request message to the first profile manager 103 using the obtained address. The profile backup request message may include the identifier of the first profile 109 to be moved, the identifier of the first terminal embedded security module 107 (or the identifier of the first terminal 105), and the certificate of the profile provider 102. have. The certificate of the profile provider 102 includes an identifier of the MNO 502 in some fields, and a signature can be performed based on this.

In step 530, the first profile manager 103 transmits a profile backup request message to the first terminal 105. The first profile manager 103 may obtain the identifier of the destination first terminal 105 or the corresponding identifier of the first terminal built-in security module 107 from the received profile backup request message, through which the profile backup It is possible to identify the destination to which the request message will be delivered. In particular, when the MSISDN value is transmitted through step 515, a profile backup request message may be transmitted to the terminal using an SMS message. The profile backup request message delivered in step 530 may include the identifier of the first profile 109 and the certificate of the profile provider 102.

In step 535, the first terminal 105 encrypts the profile according to the received profile backup request message. The first terminal built-in security module 107 of the first terminal 105 may obtain the identifier of the target profile 109 from the received profile backup request message. The first terminal built-in security module 107 encrypts at least a part of the corresponding profile 109. The specific process of encrypting the profile is as described above with reference to FIG. 2.

In step 540, the first terminal 105 transmits the encrypted profile to the first profile manager 103. However, the encryption process of step 535 and the delivery process of step 540 will be performed only when the MNO identifier included in the profile manager's certificate and the MNO identifier included in the profile 109 are the same and the certificate is a valid certificate.

In step 545, the first profile manager 103 delivers the backed up profile to the profile provider 102.

In step 550, the profile provider 102 configures the second profile 110 using the received profile, a new K value, and the like. The configuration process of the second profile 110 is as described above with reference to FIGS. 2 to 4. In step 555, the profile provider 102 queries the address of the profile manager 104 corresponding to the second terminal embedded security module 108 to receive the second profile through the address search server. The address lookup process is similar to that of step 520. As in the process of step 520, when the profile provider 102 directly holds the address information, the address acquisition may be performed without external communication.

In step 560, the profile provider 102 installs the second profile 110 in the second terminal embedded security module 108 of the second terminal 106 through the second profile manager 104. The second profile 110 can be encrypted in a similar way to the first profile 109. If the installation is successful, the subsequent process is performed.

In step 565, the profile provider 102 sends a request message to the AuC of the MNO 502 requesting an update of the K value corresponding to the profile. In step 570, AuC notifies the profile provider 102 of the K value update result. If the K value update is successful, in step 575, the profile provider 102 sends a request message to the first terminal 105 to delete the first profile 109. If the K value update fails, the deletion procedure of the second profile 110 will be performed.

6 is a flowchart of a profile setting process according to a second embodiment of the present specification.

The embodiment of FIG. 6 is similar to the embodiment of FIG. 5, but differs in that a profile movement is triggered from the first terminal 105.

The first terminal 105 tries to move the first profile 109 to the second terminal built-in security module 108 of the second terminal 106 according to user input or other reasons. In step 605, the first terminal 105 searches the address of the profile manager corresponding to the first terminal embedded security module 107 through the address search server 111. As described above, when the first terminal 105 holds the corresponding address, the search process may be omitted.

In step 610, the first terminal transmits a profile movement request message to the first profile manager 103 using the obtained address. The profile movement request message is, for example, the identifier of the first terminal embedded security module 107, the identifier of the moving target profile (eg Profile ID, MSISDN, or IMSI), and the identifier of the second terminal embedded security module 108 It may include.

In step 615, the first profile manager 103 retrieves the address of the profile provider 102 corresponding to the first terminal embedded security module 107 through the address search server 111. As described above, when the first profile manager 103 holds the corresponding address, the search process may be omitted.

In step 620, the first profile manager 103 delivers the received profile movement request message to the profile provider 102.

Since steps 620 to 675 are the same as or similar to those of steps 520 to 575 of FIG. 5, detailed descriptions thereof will be omitted here.

7 is a block diagram of a profile provider according to some embodiments of the present specification.

The profile provider according to an embodiment of the present specification includes a communication unit 710 and a control unit 720.

The communication unit 710 transmits and receives signals necessary to perform at least some of the embodiments described with reference to FIGS. 1 to 6. For example, the communication unit 710 may receive a profile movement request message and transmit a profile backup request message. The communication unit 710 may transmit a message requesting the AuC to update the K value and receive a result message therefor. In addition, the communication unit 710 may transmit and receive an encrypted profile.

The control unit 720 controls each component to perform operations necessary to perform at least some of the embodiments described with reference to FIGS. 1 to 6 and to operate the profile provider according to at least some of the above-described embodiments. In particular, the control unit 720 may decrypt the encrypted profile or encrypt the profile before encryption. 8 is a block diagram of a profile manager according to some embodiments of the present specification.

The profile manager according to an embodiment of the present specification includes a communication unit 810 and a control unit 820.

The communication unit 810 transmits and receives a signal necessary to perform at least some of the embodiments described with reference to FIGS. 1 to 6. For example, the communication unit 810 may transmit and receive a profile movement request message and a profile backup request message. In addition, the communication unit 810 may transmit and receive an encrypted profile.

The control unit 820 controls each component to perform operations necessary to perform at least some of the embodiments described with reference to FIGS. 1 to 6 and to operate the profile manager according to at least some of the above-described embodiments.

9 is a block diagram of a terminal according to some embodiments of the present specification.

A terminal according to an embodiment of the present specification includes a communication unit 910 and a control unit 920. The control unit 920 may include a terminal embedded security module 930.

The communication unit 910 transmits and receives a signal necessary to perform at least some of the embodiments described with reference to FIGS. 1 to 6. For example, the communication unit 910 may transmit and receive a profile movement request message and a profile backup request message. In addition, the communication unit 910 may transmit and receive an encrypted profile.

The control unit 920 performs operations necessary to perform at least some of the embodiments described with reference to FIGS. 1 to 6 and controls each component so that the terminal operates according to at least some of the above-described embodiments. In particular, the control unit 920 may install or remove the profile in the terminal embedded security module 930. In addition, the control unit 920 may encrypt or decrypt the profile. Among the operations that the terminal embedded security module 930 may perform, an operation that may be performed outside the terminal embedded security module 930 may be performed outside the terminal embedded security module 930.

In the prior art using a removable UICC, when the first terminal is to be replaced with the second terminal, the purpose is achieved by removing the UICC from the first terminal and inserting it into the second terminal. There are no problems with inter-card duplication or redundancy.

On the other hand, in a usage environment in which a software profile corresponding to one existing UICC is moved between two different terminals and a built-in security module through a network, there is a problem of illegal copying or duplicate use of the profile between the two terminals. In addition, if a failure occurs in the middle of copying a profile from the first terminal to the second terminal and deleting the profile of the first terminal for software movement of the profile, the corresponding profile can be used in both terminals or This can lead to an error situation in which all are unavailable.

According to some embodiments of the present specification, when a user wants to purchase a new terminal or replace an existing terminal, the pre-subscribed profile can be safely moved from the first terminal to the second terminal. In addition, if the moving process is completed to the end, only the second profile of the second terminal can be used, and if a failure occurs at any one place before completion, it is restored to the original state and the transaction that enables only the first profile of the first terminal to be used again (All or Nothing) processing method is provided. In this case, the targets that can be moved include not only the applications that the mobile operator included in the initial installation of the profile, but also additionally installed applications (for example, NFC banking/card application, etc.), and data added by the user (for example, the phone book). can do. Unlike the existing removable hardware UICC, in which all data in the card is transferred with the card when the card is removed or inserted in the terminal, according to some embodiments of the present specification, the entire or selected part may be backed up and moved according to the user's choice. have.

The backed up first profile is reconfigured into a second profile by adding or changing contents by the profile providing server so that it can be installed in the second terminal built-in security module. When backing up, security information such as the K value of USIM is excluded from the backup, so security damage can be minimized even if the backed-up profile is leaked.

By updating the terminal embedded security module identifier field to the second terminal embedded security module identifier in the profile reconfiguration step, the newly generated second profile is operated only in the second terminal embedded security module to prevent abnormal copying of the profile, and also AuC It provides a security mechanism such as making it impossible to use abnormally even when the first profile is not deleted from the first terminal built-in security module by changing the K value managed by the user.

According to some embodiments of the present specification, security-sensitive information (for example, the K value of the USIM application) among the contents of the profile is minimized by adding a corresponding value when reconfiguring the profile in the profile providing server without backing up. can do. According to some embodiments of the present specification, a user or an administrator may set an application and data to be backed up/moved.

As described above, when the profile is successfully copied to the new terminal built-in security module when the profile is moved, the profile must be deleted from the existing terminal built-in security module, but the profile is not deleted due to an error or malicious operation. It is necessary to prepare for the case where two terminals exist in duplicate. According to some embodiments of the present specification, when the profile provider reconfigures the profile, the K value of the USIM is changed and reflected in the AuC, thereby preventing access to the communication network using the existing profile.

As described above, it is necessary to prevent the profile from being copied to another terminal embedded security module without permission.

According to some embodiments of the present specification, an identifier value (eSEID) of a terminal embedded security module to which a corresponding profile is to be installed in a profile and a signature value thereof are added, so that it is not installed and operated in another terminal embedded security module. . The purpose of the signature value is to prevent tampering with the identifier value, and the signature value connects the profile identifier (ProfileID) and the security module identifier (eSEID) value and important parameters in the profile, such as IMSI, and signs it with the certificate private key of the profile providing server. Can be created in a similar way, or similar. When moving a normal profile, the profile provider can re-sign after changing the value.

At this time, it will be understood that each block of the process flow chart diagrams and combinations of the flow chart diagrams can be performed by computer program instructions. These computer program instructions may be mounted on a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, so that instructions performed through a processor of a computer or other programmable data processing equipment are described in flowchart block(s). It creates a means to perform functions. These computer program instructions can also be stored in computer readable or computer readable memory that can be oriented to a computer or other programmable data processing equipment to implement a function in a particular way, so that computer readable or computer readable memory It is also possible for the instructions stored in to produce an article of manufacture containing instructions means for performing the functions described in the flowchart block(s). Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so a series of operational steps are performed on a computer or other programmable data processing equipment to create a process that is executed by the computer to generate a computer or other programmable data. It is also possible for instructions to perform processing equipment to provide steps for executing the functions described in the flowchart block(s).

Also, each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing the specified logical function(s). It should also be noted that in some alternative implementations, it is also possible that the functions mentioned in the blocks occur out of sequence. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or it is also possible that the blocks are sometimes executed in reverse order according to a corresponding function.

At this time, the term'~ unit' used in this embodiment means a hardware component such as software or an FPGA or an ASIC, and'~ unit' performs certain roles. However,'~bu' is not limited to software or hardware. The'~ unit' may be configured to be in an addressable storage medium or may be configured to reproduce one or more processors. Thus, as an example,'~ unit' refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, attributes, and procedures. , Subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, database, data structures, tables, arrays, and variables. The functions provided within components and'~units' may be combined into a smaller number of components and'~units', or further separated into additional components and'~units'. In addition, the components and'~ unit' may be implemented to play one or more CPUs in the device or secure multimedia card.

Those of ordinary skill in the art to which the present specification pertains will appreciate that the present specification may be implemented in other specific forms without changing its technical spirit or essential characteristics. Therefore, it should be understood that the embodiments described above are illustrative in all respects and not restrictive. The scope of the present specification is indicated by the scope of the claims, which will be described later, rather than the detailed description, and all modifications or variations derived from the meaning and scope of the claims and equivalent concepts thereof are included in the scope of the specification. Should be interpreted.

On the other hand, the present specification and drawings have been described with respect to preferred embodiments of the present specification, although specific terms have been used, they are merely used in a general sense to easily describe the technical contents of the present specification and to help understand the invention. It is not intended to limit the scope of the specification rights. It is obvious to those skilled in the art to which the present specification pertains that other modifications based on the technical spirit of the present specification can be implemented in addition to the embodiments disclosed herein.

Claims (22)

In the method performed by the profile server,
Receiving a first message from the first terminal requesting to move some or all of the first profile from the first module of the first terminal to the second module of the second terminal;
Creating a second profile using some or all of the first profile; And
And transmitting the second profile to the second terminal. According to claim 1,
Wherein the first message includes part or all of the first profile. According to claim 1,
Transmitting a second message requesting part or all of the first profile to the first terminal; And
And receiving part or all of the first profile from the first terminal. According to claim 1,
When the second profile is successfully installed in the second module, transmitting a third message to an authentication center (Auc) requesting update of authentication key information related to the second profile; And
And when the authentication key information is successfully updated, transmitting a fourth message requesting to delete the first profile to the first terminal. According to claim 1,
The first profile includes an identifier of the first module, an identifier of the first terminal, and a first signature,
The second profile includes the identifier of the second module, the identifier of the second terminal, and a second signature. According to claim 1,
And if the second profile is transmitted from the profile server to the second terminal and is successfully installed in the second module, transmitting a fifth message requesting the deletion of the first profile to the first terminal. Method characterized in that. On the profile server,
Transceiver; And
A first message requesting to move part or all of the first profile from the first module of the first terminal to the second module of the second terminal is received from the first terminal through the transceiver, and a part of the first profile Or a profile server comprising a control unit for generating a second profile using all, and controlling to transmit the second profile to the second terminal through the transceiver. The method of claim 7,
The first message is a profile server, characterized in that it includes a part or all of the first profile. The method of claim 7, wherein the control unit,
A profile characterized by transmitting a second message requesting part or all of the first profile to the first terminal through the transceiver and controlling to receive part or all of the first profile from the first terminal. server. The method of claim 7, wherein the control unit,
When the second profile is successfully installed in the second module through the transceiver, a third message requesting update of authentication key information related to the second profile is transmitted to an authentication center (AuC), and the authentication key information If is successfully updated, the profile server, characterized in that for controlling to transmit to the first terminal a fourth message requesting the deletion of the first profile. The method of claim 7,
The first profile includes an identifier of the first module, an identifier of the first terminal, and a first signature,
The second profile includes an identifier of the second module, an identifier of the second terminal, and a second signature. The method of claim 7, wherein the control unit,
When the second profile is transmitted from the profile server to the second terminal through the transceiver and is successfully installed in the second module, a fifth message requesting deletion of the first profile is transmitted to the first terminal Profile server, characterized in that to control. In the method performed by the first terminal,
Transmitting a first message to a profile server requesting to move some or all of the first profile from the first module of the first terminal to the second module of the second terminal;
Receiving a second message requesting deletion of the first profile from the profile server; And
And deleting the first profile from the first module based on the second message,
If the second profile generated based on part or all of the first profile is transmitted to the second terminal, and is successfully installed in the second module, receiving the second message from the profile server Way. The method of claim 13,
Wherein the first message includes part or all of the first profile. The method of claim 13,
Receiving a third message requesting a part or all of the first profile from the profile server; And
And transmitting part or all of the first profile to the profile server based on the third message. The method of claim 13,
When the second profile is successfully installed in the second module, and the authentication key information related to the second profile is successfully updated, the second message is transmitted from the profile server to the first terminal. Way. The method of claim 13,
The first profile includes an identifier of the first module, an identifier of the first terminal, and a first signature,
The second profile includes the identifier of the second module, the identifier of the second terminal, and a second signature. In the first terminal,
Transceiver; And
A first message requesting to move part or all of the first profile from the first module of the first terminal to the second module of the second terminal is transmitted to the profile server through the transmission/reception unit, and the profile server receives the first message. It includes a control unit for receiving a second message requesting the deletion of the profile, and controls to delete the first profile from the first module based on the second message,
If the second profile generated based on a part or all of the first profile is transmitted to the second terminal and is successfully installed in the second module, receiving the second message from the profile server. First terminal. The method of claim 18,
The first message is a first terminal, characterized in that it includes a part or all of the first profile. The method of claim 18, wherein the control unit,
And receiving a third message requesting a part or all of the first profile from the profile server, and controlling to transmit a part or all of the first profile to the profile server based on the third message. First terminal. The method of claim 18,
When the second profile is successfully installed in the second module, and authentication key information related to the second profile is successfully updated, the second message is transmitted from the profile server to the first terminal. First terminal. The method of claim 18,
The first profile includes an identifier of the first module, an identifier of the first terminal, and a first signature,
The second profile includes the identifier of the second module, the identifier of the second terminal, and a second signature.

Images