KR102340461B1 - Method and apparatus for setting profile - Google Patents

Abstract

The present specification relates to a profile setting method and apparatus, and the profile setting method according to an embodiment of the present specification receives a profile movement request requesting to move at least a portion of a first profile from a first security module to a second security module Receiving, transmitting a request message for requesting at least a portion of the first profile to the first security module, receiving at least a portion of the first profile from the first security module, the received first constructing a second profile by using at least a part of one profile; transmitting the second profile to the second security module; corresponding to the second profile when the second profile is installed in the second security module Transmitting a message requesting to update the security value to the AuC (Authentication Center), when the AuC updates the security value corresponding to the second profile, transmitting a message requesting to delete the first profile; When the AuC fails to update the security value corresponding to the second profile, transmitting a message requesting deletion of the second profile, and when the AuC fails to update the security value corresponding to the second profile The AuC may include transmitting a message requesting to restore the K to the value before the update.

Description

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

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

A UICC (Universal Integrated Circuit Card) is a smart card inserted into a terminal and used. UICC stores personal information such as network access authentication information, phone book, and short message of mobile communication subscribers. 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), the UICC performs subscriber authentication and traffic security key generation to use secure mobile communications makes it possible The UICC is loaded with communication applications such as SIM (Subscriber Identity Module), USIM (Universal Subscriber Identity Module), and ISIM (IP Multimedia Services Identity Module) depending on the type of mobile communication network the subscriber accesses. In addition, UICC provides high-level security functions for loading various application applications such as e-wallet, ticketing, and e-passport.

The conventional UICC is manufactured as a dedicated card for a specific mobile communication operator at the request of a specific mobile communication operator when manufacturing the card. In the conventional UICC, authentication information (eg, USIM application, IMSI (International Mobile Subscriber Identity), K (key) value) for network access of a corresponding operator is pre-loaded and shipped. Therefore, the mobile communication service provider receives the manufactured UICC and provides it to subscribers, and then, if necessary, manages the installation, modification, and deletion of applications within the UICC using technologies such as over-the-air (OTA). The subscriber can use the network and application services of the corresponding mobile communication operator by inserting the UICC into the owned terminal. The subscriber can use the authentication information, mobile communication phone number, personal phone book, etc. stored in the UICC as it is in the new terminal by moving the UICC from the old terminal to the new terminal when replacing the terminal.

UICC maintains international compatibility by defining its physical shape and logical function by ETSI (European Telecommunications Standards Institute). Looking at the aspect of the form factor that defines the physical shape, it ranges from the most widely used Mini SIM, to the Micro SIM, which has been used for several years, and, more recently, to the Nano SIM. It is getting smaller and smaller. Although this contributes a lot to the miniaturization of the terminal, it is expected that the UICC card with a smaller size than the recently enacted Nano SIM will be difficult to standardize due to the user's fear of loss. It is expected that further miniaturization will be difficult because a space for mounting the slot is required.

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

In order to solve this problem, a method of replacing the conventional detachable UICC by embedding a security module performing a function of the UICC or a similar function in the terminal when manufacturing the terminal is emerging. However, such a security module is mounted so that it cannot be detached inside the terminal when the terminal is manufactured. Therefore, unless the terminal is manufactured as a terminal exclusively for a specific mobile communication service provider, network access authentication information of a specific mobile communication service provider such as USIM's IMSI and K cannot be pre-loaded when the terminal is manufactured. In addition, such authentication information can be set only after the user who purchased the corresponding terminal signs up for a specific mobile communication service provider.

In addition, unlike the conventional UICC card that was manufactured and distributed exclusively for a specific mobile communication operator, the newly introduced terminal built-in security module allows the user who purchased the terminal to sign up as a specific mobile operator, cancel the subscription, or use another operator. It should be able to safely and flexibly install and manage the authentication information of various mobile communication operators as subscription changes are performed. 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 specification, in a method performed by a profile server, a first message requesting to move part or all of a first profile from a first module of a first terminal to a second module of a second terminal receiving from the first terminal; generating a second profile using some or all of the first profile; and transmitting the second profile to the second terminal.

According to some embodiments of the present specification, it is possible to effectively set a profile.

1 is a block 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 the 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 the present specification belongs and are not directly related to the present specification will be omitted. This is to more clearly convey the gist of the present specification without obscuring the gist of the present specification by omitting unnecessary description.

For the same reason, some components are exaggerated, omitted, or schematically illustrated in the accompanying drawings. In addition, the size of each component does not fully reflect the actual size. In each figure, the same or corresponding elements are assigned the same reference numerals.

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

A communication system according to an embodiment of the present specification includes terminals 105 and 106, embedded Secure Element (eSE) modules 107 and 108 embedded in the terminals 105 and 106, and a Profile Provider ( 102 ), profile managers 103 and 104 , and an address search server 111 . In some embodiments, 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 board of the terminals 105 and 106 in the form of a chip or embedded in other methods, and the eUICC (embedded UICC) is also a type of security module embedded in the terminal. to be. Profiles 109 and 110 are installed in the form of software in the terminal built-in security module 107, 108. The profiles 109 and 110 are software packages containing information corresponding to one (or two or more) existing removable UICCs. For example, a profile may be defined as a software package including all user data information such as one or more applications, subscriber authentication information, and a phone book contained in one existing UICC sheet.

The profile provider 102 may be operated directly by a mobile network operator (MNO), or may be operated by another entity that has a complete trust relationship with the mobile operator. The profile provider 102 creates and encrypts a profile for a subscriber who subscribes to a corresponding mobile operator, and delivers the encrypted profile to the profile managers 103 and 104 . The profile provider 102 may be implemented in the form of a profile providing server, for example.

The profile managers 103 and 104 perform profile management for specific terminal-built security modules 107 and 108 . Due to the technical characteristics of the smart card-based security module, before the terminals 105 and 106 are sold to users (generally when the terminals 105 and 106 are manufactured), the security key information of the same value is transmitted to both sides (the terminal built-in security module). (105, 106) and the profile manager (103, 104)), it is expected that the profile manager (103, 104) can be operated by the manufacturer or the terminal manufacturer of the in-device security module (105, 106). . The profile managers 103 and 104 may be implemented in the form of, for example, a profile management server.

The profile managers 103 and 104 securely transmit the encrypted profile received from the profile provider 102 to the corresponding in-device 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 a profile management role such as activation, deactivation, backup, and removal of the profile. A plurality of profiles may be installed in one terminal's built-in security module (107, 108) according to the mobile operator's subscription status of the corresponding terminal. In this case, when the terminal (105, 106) accesses the mobile communication network, any one of the installed profiles is selected and used.

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

2 shows that after a request for moving a profile from the first built-in terminal security module 107 to the second built-in security module 108 is received, the profile information of the first built-in terminal security module 107 is backed up, After the profile is reconfigured to enable installation in the second in-device security module 108, and the reconfigured profile is installed in the second in-device security module 108, according to the installation result and the AuC (Authentication Center) update result Indicates the process in which processing is executed.

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

After that, in step 203, the first profile 109 installed in the first built-in terminal security module 107 is encrypted, transmitted to the profile providing server, and backed up. At this time, the first terminal 105 , for example, the first in-device 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 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. And, the symmetric key value for encryption/decryption may be encrypted with the public key of the profile provider 102 certificate and delivered to the profile provider 102 .

In this case, the first terminal 105 may encrypt and transmit the entire content of the first profile 109 . According to a modified example, the first terminal 105 may encrypt and transmit only user data such as a phone book, except for 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 untransmitted contents may be added by the profile provider 102 in step 204 to be described later. According to another modification, the user may select a target to be moved to the second in-device security module 108 from among the applications and data included in the first profile 109 as needed.

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/replicated to another terminal built-in security module. First, the profile 320 may further include an identifier (eSE ID) 305 of the terminal's built-in security module to which the profile 320 is to be installed. Instead of the eSE ID 305 , a terminal identifier (Terminal ID) may be used, or a terminal identifier 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 will be described for convenience of description.

Profile 320 may also include a signature value 306 . If the value of the internal security module identifier 305 is tampered with by a third party for abnormal duplication to other in-device security modules or the USIM 330 is abnormally copied, the signature value 306 is used to immediately identify This is possible. The signature value 306 is the profile identifier 304, the in-device security module identifier and/or the terminal identifier value 305, and the profile provider for 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.

<Equation>

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 of the profile 320 and USIM ( 330) can all be prevented.

According to a variant, only the profile identifier 304 and the eSE ID 305 may 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.

<Equation>

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 modification, only the profile identifier 304 and the IMSI 307 may be utilized 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.

<Equation>

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 may activate the profile according to the process of FIG. 4 , and detect abnormal duplication of the profile and/or USIM according to this process.

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

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

As a result of the verification, if the terminal built-in security module identifier value is incorrect, the process proceeds to step 404. In step 404, the in-device security module 310 does not use the selected profile. The terminal built-in security module 310 may discard the selected profile. Later, the terminal built-in security module 310 may select another profile and repeat the same process. However, profiles with incorrect identifiers as a result of verification are not used. As a result of the verification, if the terminal built-in security module identifier value is correct, the process proceeds to step 405 .

In step 405, the in-device security module 310 verifies the signature value in the profile. If it is verified that the signature value is correct, the process proceeds to step 406 and the in-device security module 310 uses the corresponding profile. If it is determined that the signature value is incorrect, the process proceeds to step 404, and similarly, the in-device security module 310 may discard the profile without using the corresponding profile (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 above-described anti-piracy function with reference to FIGS. 3 and 4 , the profile provider 102 determines the identifier value of the first in-device security module 107 of the first profile 190 for profile reconstruction in step 204 . to be replaced with the identifier value of the second in-device security module 108, and the signature value must also be regenerated to a value corresponding to the value to reconfigure the profile.

In addition, when the reconfigured second profile 110 is successfully installed in the second terminal built-in security module 108, the first profile previously installed in the first terminal built-in security module 107 is not necessarily deleted or used. should be dealt with If the first profile 109 is not deleted due to a technical error or malicious intent, in order to prevent abnormal use of the first profile 109, in step 204, the profile provider 102 performs the second in-device security module A second profile may be generated using the USIM authentication key K value of the second profile 110 to be installed in the . The K value of the second profile 110 may be different from the K value of the first profile 109 . Also, the profile provider 102 may transmit a request message requesting the AuC of the corresponding mobile operator to update the K value of the first profile 109 to the K value of the second profile 110 . Accordingly, AuC may 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, since the K value of AuC is changed, the first terminal 105 uses the USIM of the first profile 109 to It becomes impossible to access the 3GPP network. When AuC receives a request for access approval based on the first profile 109 from the first terminal 105, it attempts authentication using the K value stored in AuC, and in this case, the K value stored in AuC is stored in the second profile 110. Although updated to the corresponding value, since the first terminal 105 attempts to access using the conventional K value, the connection fails.

The second profile 110 reconfigured in step 205 is installed in the second terminal built-in security module 108 . The installation result is transmitted to the profile provider 102 and the profile managers 103 and 104 .

If the installation result is failure, the process ends. Accordingly, the first profile 109 installed in the first terminal 105 is maintained as it is, and is maintained in a state prior to 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 K value update request 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 by error or malicious intent in step 208, since AuC has completed updating the K value in step 206, access using the first profile 109 is 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. In addition, even if the second profile 110 is not deleted from the second terminal 106 due to an error or malicious intent at this time, since the AuC update process was not performed properly in step 206, the communication network using the second profile 110 It is impossible to access

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 restored to its original state. 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 built-in security module 107 , the second terminal 106 or the second terminal built-in security module 108 . It may include an identifier. When a plurality of profiles exist in the first in-device security module 107, the profile movement request message may further include one or more of a profile identifier, MSISDN, and 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 user authentication is successful, the subsequent process is performed.

In step 515 , the MNO 502 transmits the received profile move request message to the profile provider 102 .

In step 520, the profile provider 102 searches the address search server 111 for the address of the profile manager for the first in-device security module 107 of the first terminal 105 in which the moving target profile is currently stored. ) to find the address. Instead of the address search server 111, another type of address search interface or address storage device 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 modified example in which the profile provider 102 directly stores and manages an address corresponding to each terminal built-in security module may be considered. In this case, the profile provider 102 may acquire the address of the first profile manager 103 without external communication. Here, the address may be in the form of, for example, an IP address and/or a domain address.

In step 525 , the profile provider 102 transmits 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 in-device 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 the identifier of the MNO 502 in some fields, and signing may 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 a destination to which the request message is to 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 transmitted in step 530 may include an identifier of the first profile 109 and a 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 in-device 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 in-device security module 107 encrypts at least a portion of the corresponding profile 109 . A detailed process of encrypting the profile is the same 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, 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, the encryption in step 535 and the delivery process in step 540 will be performed.

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 and a new K value. A process of configuring the second profile 110 is the same as described above with reference to FIGS. 2 to 4 . In step 555, the profile provider 102 inquires the address of the profile manager 104 corresponding to the second in-device security module 108 to receive the second profile through the address search server. The address lookup process is similar to that of step 520 . Similar to the process of step 520 , when the profile provider 102 directly holds address information, address acquisition may be performed without external communication.

In step 560 , the profile provider 102 installs the second profile 110 in the second terminal built-in security module 108 of the second terminal 106 through the second profile manager 104 . The second profile 110 may be encrypted in a similar manner to the first profile 109 . If the installation is successful, the subsequent steps are performed.

In step 565, the profile provider 102 transmits a request message for requesting update of the K value corresponding to the profile to the AuC of the MNO 502. In step 570, the AuC notifies the K value update result to the profile provider 102 . If the K value update is successful, in step 575 , the profile provider 102 transmits 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 the second embodiment of the present specification.

The embodiment of FIG. 6 is similar to the embodiment of FIG. 5 , but is different in that the 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 for the address of the profile manager corresponding to the first in-device security module 107 through the address search server 111 . As described above, when the first terminal 105 has 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 includes, for example, an identifier of the first in-device security module 107, an identifier of a moving target profile (eg, Profile ID, MSISDN, or IMSI), and an identifier of the second in-device security module 108 may include

In step 615 , the first profile manager 103 searches for the address of the profile provider 102 corresponding to the first in-device security module 107 through the address search server 111 . As described above, when the first profile manager 103 has the corresponding address, the search process may be omitted.

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

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

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 update of the K value to the AuC and receive a result message therefor. Also, the communication unit 710 may transmit/receive an encrypted profile.

The controller 720 performs an operation necessary to perform at least some of the embodiments described with reference to FIGS. 1 to 6 and controls each component so that the profile provider operates according to at least some of the above-described embodiments. In particular, the controller 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 signals 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. Also, the communication unit 810 may transmit/receive an encrypted profile.

The controller 820 performs an operation necessary to perform at least some of the embodiments described with reference to FIGS. 1 to 6 and controls each component so that the profile manager operates 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.

The 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 built-in security module 930 .

The communication unit 910 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 910 may transmit and receive a profile movement request message and a profile backup request message. Also, the communication unit 910 may transmit/receive an encrypted profile.

The controller 920 performs an operation 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 controller 920 may install or remove the profile in the terminal built-in security module 930 . Also, the controller 920 may encrypt or decrypt the profile. Among the operations that can be performed by the terminal built-in security module 930 , operations that may be performed outside the terminal built-in security module 930 may be performed outside the terminal built-in 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, and since the physical card is moved, the two terminals There is no problem with card duplication or duplicate use between cards.

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

According to some embodiments of the present specification, when a user purchases a new terminal or wants to replace an existing terminal, the previously subscribed profile can be safely moved from the first terminal to the second terminal. In addition, when the movement process is completed to the end, only the second profile of the second terminal can be used, and if a failure occurs in any one place before completion, it is restored to its original state and only the first profile of the first terminal can be used again. or Nothing) processing method is provided. In this case, the target that can be moved includes not only the applications included by the mobile operator during initial installation of the profile, but also additionally installed applications (eg, NFC banking/card applications, etc.) and data added by the user (eg, phone book). can do. Unlike the existing removable hardware UICC, in which all data in the card is moved together with the card when the card is removed or inserted in the terminal, according to some embodiments of the present specification, all or selected parts can be backed up and moved according to the selection of the mobile operator or the user. have.

The content of the backed-up first profile is added or changed by the profile providing server so that it can be installed in the second terminal built-in security module and reconfigured into the second profile. During backup, security information such as the K value of USIM is excluded from the backup target, so that security damage can be minimized even if the backed-up profile is leaked.

In the profile reconfiguration step, by updating the terminal built-in security module identifier field with the second terminal built-in security module identifier, the newly created second profile operates only on the second terminal built-in security module to prevent abnormal duplication of the profile, and also AuC A security mechanism is provided, such as preventing abnormal use even if the first profile is not deleted from the first terminal built-in security module by creating the second profile by changing the K value managed by .

According to some embodiments of the present specification, security-sensitive information (eg, the K value of the USIM application) among the contents of the profile is not backed up and the corresponding value is added when the profile is reconfigured in the profile providing server to minimize damage caused by leakage can do. According to some embodiments of the present specification, a user or an administrator may set a target for applications and data to be backed up/moved.

As described above, if the profile copy to the new built-in security module is successful when moving the profile, the corresponding profile must be deleted from the existing built-in security module. It should be prepared for the case of dual existence in two terminals. According to some embodiments of the present specification, when the profile provider reconfigures the profile, the K value of USIM is changed and this is reflected in AuC, so that access to the communication network using the existing profile can be blocked.

As described above, it is necessary to prevent the profile from being copied to another terminal's built-in security module without permission.

According to some embodiments of the present specification, by adding the identifier value (eSEID) of the terminal built-in security module to which the corresponding profile is to be installed and the signature value thereof in the profile, installation and operation in other terminal built-in security modules may be prevented. . The purpose of the signature value is to prevent falsification of the identifier value, and the signature value connects important parameters in the profile such as profile identifier (ProfileID), security module identifier (eSEID) and IMSI, and is signed with the certificate private key of the profile providing server. It can be created in this way, or in a similar way. When moving a normal profile, the profile provider can change the value and then re-sign.

At this time, it will be understood that each block of the flowchart diagrams and combinations of the flowchart diagrams may be performed by computer program instructions. These computer program instructions may be embodied in a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, such that the instructions performed by the processor of the computer or other programmable data processing equipment are not described in the flowchart block(s). It creates a means to perform functions. These computer program instructions may also be stored in a computer-usable or computer-readable memory which may direct a computer or other programmable data processing equipment to implement a function in a particular manner, and thus the computer-usable or computer-readable memory. It is also possible that the instructions stored in the flow chart block(s) produce an article of manufacture containing instruction means for performing the function described in the flowchart block(s). The computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operational steps are performed on the computer or other programmable data processing equipment to create a computer-executed process to create a computer or other programmable data processing equipment. It is also possible that instructions for performing the processing equipment provide steps for performing the functions described in the flowchart block(s).

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

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

Those of ordinary skill in the art to which this specification belongs will be able to understand that the present specification may be embodied in other specific forms without changing the technical spirit or essential features thereof. 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 claims described later rather than the detailed description, and all changes or modifications derived from the meaning and scope of the claims and their equivalent concepts are included in the scope of the present specification. should be interpreted

On the other hand, in the present specification and drawings, preferred embodiments of the present specification have been disclosed, and although specific terms are used, these are only used in a general sense to easily explain the technical content of the present specification and help the understanding of the invention, It is not intended to limit the scope of the rights in the specification. It will be apparent to those of ordinary skill in the art to which this specification pertains that other modifications based on the technical spirit of the present specification may be implemented in addition to the embodiments disclosed herein.

Claims (22)

A method performed by a profile server, comprising:
Receiving a first message from the first terminal 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;
generating a second profile using some or all of the first profile;
transmitting the second profile to the second terminal; and
and when the second profile is successfully installed in the second module, transmitting a third message requesting to update a security value corresponding to the second profile to the authentication server. According to claim 1,
The method of 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
The method further comprising the step of receiving a part or all of the first profile from the first terminal. According to claim 1,
When the security value is successfully updated, the method further comprising the step of transmitting a fourth message requesting deletion of 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 comprises an identifier of the second module, an identifier of the second terminal, and a second signature. According to claim 1,
When the second profile is transmitted from the profile server to the second terminal and successfully installed in the second module, transmitting a fifth message requesting deletion of the first profile to the first terminal A method characterized in that In the profile server,
transceiver; and
Receives a first message from the first terminal 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 through the transceiver, and a part of the first profile Or, a second profile is created using all of them, and the second profile is transmitted to the second terminal through the transceiver, and when the second profile is successfully installed in the second module, the second profile corresponds to the second profile. Profile server comprising a control unit for controlling to transmit a third message requesting to update the security value to the authentication server. 8. The method of claim 7,
The profile server of claim 1, wherein the first message includes a part or all of the first profile. According to claim 7, wherein the control unit,
Transmitting a second message requesting a part or all of the first profile to the first terminal through the transceiver, and controlling to receive a part or all of the first profile from the first terminal server. According to claim 7, wherein the control unit,
When the security value is successfully updated, the profile server, characterized in that the control to transmit a fourth message requesting deletion of the first profile to the first terminal. 8. 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 profile server, characterized in that it includes the identifier of the second module, the identifier of the second terminal, and a second signature. According to claim 7, wherein the control unit,
If 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 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 to the profile server;
receiving a second message requesting deletion of the first profile from the profile server; and
deleting the first profile from the first module based on the second message;
A second profile generated based on part or all of the first profile is transmitted to the second terminal, the second profile is successfully installed in the second module, and a security value corresponding to the second profile is obtained. and receiving the second message from the profile server when a message requesting to update is sent to the authentication server, and when the security value is successfully updated. 14. The method of claim 13,
The method of claim 1, wherein the first message includes part or all of the first profile. 14. The method of claim 13,
receiving a third message requesting part or all of the first profile from the profile server; and
The method further comprising the step of transmitting a part or all of the first profile to the profile server based on the third message. 14. The method of claim 13,
When the second profile is successfully installed in the second module and the security value is successfully updated, the second message is transmitted from the profile server to the first terminal. 14. 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 comprises an identifier of the second module, an identifier of the second terminal, and a second signature. In the first terminal,
transceiver; and
Transmitting a first message to the profile server 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 through the transceiver, and from the profile server A control unit that receives a second message requesting deletion of the profile and controls to delete the first profile from the first module based on the second message,
A second profile generated based on part or all of the first profile is transmitted to the second terminal, the second profile is successfully installed in the second module, and a security value corresponding to the second profile is obtained. and receiving the second message from the profile server when a message requesting to update is transmitted to the authentication server, and when the security value is successfully updated. 19. 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,
Receiving a third message requesting part or all of the first profile from the profile server, and controlling to transmit part or all of the first profile to the profile server based on the third message first terminal. 19. The method of claim 18,
When the second profile is successfully installed in the second module and the security value is successfully updated, the second message is transmitted from the profile server to the first terminal. 19. 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 comprises an identifier of the second module, an identifier of the second terminal, and a second signature.

Images