KR20210034475A - Apparatus and methods for mutual authentication during device to device bundle or profile transfer - Google Patents

Abstract

According to the present disclosure, disclosed are a method for enabling two security media to authenticate each other in regard to a bundle transfer between smart security media, and an apparatus thereof. According to one embodiment of the present disclosure, a terminal providing a bundle to a second terminal includes: a transceiving part; and at least one processor. The at least one processor obtains information about the bundle to be transmitted to the second terminal, controls the transceiving part so as to transmit identification information of the bundle to the second terminal, controls the transceiving part so as to receive bundle transfer-related authentication information of a second smart secure platform (SSP) of the second terminal from the second terminal, determines whether a second secondary platform bundle loader (SPBL) of the second SSP is an SPBL capable of receiving the bundle, based on the bundle transfer-related authentication information of the second SSP, and controls the transceiving part so as to transmit the bundle to the second terminal based on a result of the determination.

Description

Mutual authentication method and device between devices when moving a bundle or profile between devices {APPARATUS AND METHODS FOR MUTUAL AUTHENTICATION DURING DEVICE TO DEVICE BUNDLE OR PROFILE TRANSFER}

The present disclosure relates to a method and apparatus for mutual authentication between devices, and more particularly, to a method and apparatus for mutual authentication of two devices when a bundle or profile is moved between devices.

Efforts are being made to develop an improved 5G communication system or a pre-5G communication system in order to meet the increasing demand for wireless data traffic after the commercialization of 4G communication systems. For this reason, a 5G communication system or a pre-5G communication system is called a Beyond 4G Network communication system or an LTE system and a Post LTE system. In order to achieve a high data rate, the 5G communication system is being considered for implementation in the ultra-high frequency (mmWave) band (eg, such as the 60 Giga (60 GHz) band). In order to mitigate the path loss of radio waves in the ultra-high frequency band and increase the transmission distance of radio waves, 5G communication systems include beamforming, massive MIMO, and Full Dimensional MIMO (FD-MIMO). ), array antenna, analog beam-forming, and large scale antenna technologies are being discussed. In addition, in order to improve the network of the system, in 5G communication system, evolved small cell, advanced small cell, cloud radio access network (cloud RAN), ultra-dense network , Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation And other technologies are being developed. In addition, in 5G systems, advanced coding modulation (ACM) methods such as Hybrid FSK and QAM Modulation (FQAM) and SWSC (Sliding Window Superposition Coding), advanced access technologies such as Filter Bank Multi Carrier (FBMC), NOMA (non orthogonal multiple access), and sparse code multiple access (SCMA) are being developed.

Meanwhile, the Internet is evolving from a human-centered connection network in which humans create and consume information, to an Internet of Things (IoT) network that exchanges and processes information between distributed components such as objects. IoE (Internet of Everything) technology, which combines IoT technology with big data processing technology through connection with cloud servers, etc., is also emerging. In order to implement IoT, technological elements such as sensing technology, wired/wireless communication and network infrastructure, service interface technology, and security technology are required. , M2M), and MTC (Machine Type Communication) technologies are being studied. In the IoT environment, intelligent IT (Internet Technology) services that create new value in human life by collecting and analyzing data generated from connected objects can be provided. IoT is the field of smart home, smart building, smart city, smart car or connected car, smart grid, healthcare, smart home appliance, advanced medical service, etc. through the convergence and combination of existing IT (information technology) technology and various industries. Can be applied to.

Accordingly, various attempts have been made to apply a 5G communication system to an IoT network. For example, technologies such as sensor network, machine to machine (M2M), and machine type communication (MTC) are implemented by techniques such as beamforming, MIMO, and array antenna. There is. The application of a cloud radio access network (cloud RAN) as the big data processing technology described above can be said as an example of the convergence of 5G technology and IoT technology.

As described above, as various services can be provided according to the development of the mobile communication system, a method for effectively providing these services is required. For example, when a bundle or profile (or profile package) is moved between two devices, a method for mutual authentication of the two devices is required.

The disclosed embodiment provides an apparatus and method for enabling mutual authentication between two security modules (or between electronic devices) when moving a bundle between security modules included in two electronic devices or moving a profile between two electronic devices. Can provide.

According to an embodiment of the present disclosure, a method of providing a profile from a first terminal to a second terminal in a wireless communication system includes: determining a profile to be transmitted to a second terminal from among profiles installed in the first terminal; Receiving eUICC information of the second terminal from the second terminal based on the communication connection with the second terminal; Generating authentication information of the first terminal based on the eUICC information; Transmitting authentication information of the first terminal to the second terminal; Receiving authentication information of the second terminal from the second terminal as a response to the authentication information of the first terminal; Verifying authentication information of the second terminal; And transmitting a profile package for the profile to the second terminal based on the verification result.

According to an embodiment of the present disclosure, a method for a second terminal to receive a profile from a first terminal in a wireless communication system includes eUICC information of the second terminal to the first terminal based on a communication connection with the first terminal. Transmitting; Receiving authentication information of the first terminal as a response to the eUICC information from the first terminal; Verifying authentication information of the first terminal; Generating authentication information of the second terminal based on the verification result; Transmitting authentication information of the second terminal to the first terminal; And receiving a profile package from the first terminal as a response to the authentication information of the second terminal.

According to an embodiment of the present disclosure, a method of providing a bundle by a first terminal to a second terminal includes: obtaining information on a bundle to be transmitted to a second terminal; Transmitting identification information of the bundle to the second terminal; Receiving authentication information related to bundle movement of a second Smart Secure Platform (SSP) of the second terminal from a second terminal; Determining whether a second Secondary Platform Bundle Loader (SPBL) of the second SSP is an SPBL capable of receiving the bundle, based on authentication information related to bundle movement of the second SSP; And transmitting the bundle to the second terminal based on the determination result.

According to an embodiment of the present disclosure, the identification information of the bundle may include at least one of a bundle family identifier (Family ID, hereinafter Fid) or a bundle family manager identifier (Family Custodian Object ID, hereinafter Oid) for the bundle. I can.

According to an embodiment of the present disclosure, the authentication information related to the bundle movement of the second SSP includes received SPBL authentication information determined based on the identification information of the bundle, and the second SPBL of the second SSP identifies the bundle. The step of determining whether the SPBL can be received may include, based on the identification information of the bundle, the received SPBL authentication information is based on at least one of information on verifiable SPBL of the first terminal or information on reliable SPBL. The step of determining whether the information is included may be further included, and the information on the verifiable SPBL may be previously stored in the first terminal, and the information on the reliable SPBL may be received from a server.

According to an embodiment of the present disclosure, the information on the reliable SPBL includes bundle movement policy information corresponding to the identification information of the bundle, and the bundle movement policy information includes the received SPBL authentication information, 1) A condition included in the verifiable SPBL information, 2) a condition included in the reliable SPBL information, 3) a condition included in both the verifiable SPBL information and the reliable SPBL information, and 4) It includes any one of conditions included in any one of the verifiable SPBL information and the reliable SPBL information, and the second SPBL of the second SSP can receive the bundle. Determining whether it is an SPBL may further include determining whether the second SPBL is an SPBL capable of receiving the bundle based on the bundle movement policy information.

According to an embodiment of the present disclosure, the authentication information related to the bundle movement of the second SSP of the second terminal includes transmission SPBL authentication information determined based on the identification information of the bundle, and the method includes the transmission SPBL authentication It may further include determining whether the first SPBL of the first SSP of the first terminal is an SPBL capable of transmitting the bundle to the second terminal based on the information.

According to an embodiment of the present disclosure, the method includes: generating authentication information of the first terminal based on the transmission SPBL authentication information; Transmitting authentication information of the first terminal to the second terminal; Receiving authentication information of the second terminal from the second terminal; Verifying the validity of the authentication information of the second terminal; And transmitting the bundle to the second terminal based on the verification result.

According to an embodiment of the present disclosure, the method includes: transmitting a request for information on the reliable SPBL to the server; And receiving information on the reliable SPBL from the server, and the request for information on the reliable SPBL may include identification information of the bundle.

According to an embodiment of the present disclosure, a method of receiving, by a second terminal, a bundle from a first terminal, includes: receiving identification information of a bundle from the first terminal; Generating authentication information related to bundle movement of a second Smart Secure Platform (SSP) of the second terminal based on the received bundle identification information; Transmitting authentication information related to bundle movement of the second SSP to the first terminal; And receiving the bundle from the first terminal based on a verification result of the first terminal with respect to the bundle movement related authentication information of the second SSP.

According to an embodiment of the present disclosure, the generating of the authentication information related to the movement of the bundle of the second SSP may include identification information of the bundle from information about a verifiable Secondary Platform Bundle Loader (SPBL) of the second terminal previously stored. Extracting information corresponding to; And generating reception SPBL authentication information and transmission SPBL authentication information for the bundle based on the extracted information.

According to an embodiment of the present disclosure, the generating of the authentication information related to the bundle movement of the second SSP includes a bundle family identifier (Family ID) and a bundle family manager identifier ( Family Custodian Object ID) may include generating information including the pre-stored verifiable SPBL of the second terminal.

According to an embodiment of the present disclosure, a first terminal providing a bundle to a second terminal includes: a transceiver; And at least one processor, wherein the at least one processor controls the transmission/reception unit to obtain information on a bundle to be transmitted to a second terminal and transmit identification information of the bundle to the second terminal, and a second Controls the transceiver to receive authentication information related to bundle movement of the second SSP (Smart Secure Platform) of the second terminal from the terminal, and based on the authentication information related to bundle movement of the second SSP, the second SSP 2 It is possible to determine whether the Secondary Platform Bundle Loader (SPBL) is an SPBL capable of receiving the bundle, and control the transceiver to transmit the bundle to the second terminal based on the determination result.

According to an embodiment of the present disclosure, a second terminal receiving a bundle from a first terminal includes: a transmission/reception unit; And at least one processor, wherein the at least one processor controls the transmission/reception unit to receive identification information of a bundle from a first terminal, and a second terminal of the second terminal based on the received identification information of the bundle. Generates authentication information related to the movement of the bundle of the Smart Secure Platform (SSP), controls the transmission/reception unit to transmit authentication information related to movement of the second SSP to the first terminal, and authentication information related to movement of the bundle of the second SSP It is possible to control the transmission/reception unit to receive the bundle from the first terminal based on the verification result of the first terminal for.

According to various embodiments of the present disclosure, two devices may authenticate each other, and a bundle or profile installed in one device after authentication is completed may be transmitted and installed to another device in a safe and efficient manner.

1 shows a conceptual diagram of an SSP according to an embodiment of the present disclosure.
2 is a conceptual diagram illustrating an internal structure of an SSP according to an embodiment of the present disclosure.
FIG. 3 is a diagram illustrating an example of a component in a terminal used to download and install a bundle through an SSP by a terminal according to an embodiment of the present disclosure.
4 is a diagram illustrating an example of a method in which two terminals mutually operate in order to transmit a bundle between two terminals according to an embodiment of the present disclosure.
5 is a diagram illustrating a configuration of a "verifiable SPBL list (verifiable_SPBL_list)" according to some embodiments of the present disclosure.
6A is a diagram illustrating a configuration of a "trusted SPBL list (trusted_SPBL_list)" according to some embodiments of the present disclosure.
6B is a diagram illustrating another configuration of a "trusted SPBL list (trusted_SPBL_list)" according to some embodiments of the present disclosure.
7 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure.
FIG. 8 is a diagram illustrating a detailed procedure for a procedure for preparing for bundle transmission among the procedures presented in FIG. 7.
9 is a diagram showing a detailed procedure for a procedure in which bundle transmission and installation are performed among the procedures presented in FIG. 7.
10 is a diagram illustrating an example of a procedure for generating supportable certificate information according to a request of an LBA by an SSP of a terminal according to some embodiments of the present disclosure.
FIG. 11 is a procedure for generating authentication information capable of authenticating itself based on the received information when an SSP of a terminal is provided with supportable certificate information from another terminal according to some embodiments of the present disclosure It is a figure showing an example of.
12 is a diagram illustrating an example of a procedure for obtaining a "trusted SPBL list (trusted_SPBL_list)" by a terminal according to some embodiments of the present disclosure.
13 is a diagram illustrating a configuration of a terminal according to some embodiments of the present disclosure.
14 is a diagram illustrating a configuration of a server according to an exemplary embodiment of the present disclosure.
15 is a diagram illustrating an example of a method in which two terminals interact to transmit a profile between two terminals according to an embodiment of the present disclosure.
16 is a diagram illustrating a configuration of a "trusted CI list" according to some embodiments of the present disclosure.
17 is a diagram illustrating a procedure for transmitting a profile from one terminal to another terminal according to some embodiments of the present disclosure.
18 is a diagram illustrating an operation of a first terminal according to some embodiments of the present disclosure.
19 is a diagram illustrating an operation of a second terminal according to some embodiments of the present disclosure.
20 is a diagram illustrating a configuration of a terminal according to some embodiments of the present disclosure.
21 is a diagram illustrating a configuration of a server according to some embodiments of the present disclosure.
22 is a diagram conceptually illustrating a procedure for transmitting a profile from one terminal to another terminal according to some embodiments of the present disclosure.
23 is a diagram illustrating a detailed procedure of a profile transmission preparation procedure among the procedures presented in FIG. 22 according to some embodiments of the present disclosure.
24 is a diagram illustrating a detailed procedure of a mutual authentication procedure between two terminals among the procedures presented in FIG. 22 according to some embodiments of the present disclosure.
FIG. 25 is a diagram illustrating a detailed procedure in which a profile is transmitted from one terminal to another terminal and the transmitted profile is installed among the procedures presented in FIG. 22 according to some embodiments of the present disclosure.

Hereinafter, embodiments of the present disclosure 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 disclosure belongs and are not directly related to the present disclosure will be omitted. This is to more clearly convey the gist of the present disclosure by omitting unnecessary description.

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

Advantages and features of the present disclosure, and a method of achieving them will be apparent with reference to embodiments described later in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below, but may be implemented in a variety of different forms, only the present embodiments make the present disclosure complete, and those of ordinary skill in the art to which the present disclosure pertains. It is provided to completely inform the scope of the disclosure, and the present disclosure is only defined by the scope of the claims. The same reference numerals refer to the same elements throughout the specification.

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

In addition, each block may represent a module, segment, or part of code that contains one or more executable instructions for executing the specified logical function(s). In addition, it should be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order depending on the corresponding function.

In this case, the term'~ unit' used in this embodiment refers to software or hardware components such as FPGA or ASIC, and'~ unit' performs certain roles. However,'~ part' 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, properties, and procedures. , Subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. Components and functions provided in the'~ units' may be combined into a smaller number of elements and'~ units', or may be further separated into additional elements and'~ units'. In addition, components and'~ units' may be implemented to play one or more CPUs in a device or a security multimedia card.

In the present disclosure, modifiers such as first and second referring to terms may be used to distinguish each term from each other in describing an embodiment. Terms modified by modifiers such as first and second may refer to different objects. However, terms modified by modifiers such as first and second may refer to the same object. That is, modifiers such as first and second may be used to refer to the same object from different viewpoints. For example, modifiers such as first and second may be used to distinguish the same object in terms of functional or operation. For example, a first user and a second user may refer to the same user.

In addition, although the present disclosure describes each of the embodiments by using the SSP as an example of the security medium, the scope of the rights of the present disclosure is not limited to that of the SSP. For example, it is apparent to those of ordinary skill in the art that various embodiments to be described below may be applied to other security media that perform substantially the same or similar functions as the SSP.

Specific terms used in the following description are provided to aid understanding of the present disclosure, and the use of these specific terms may be changed in other forms without departing from the technical spirit of the present disclosure.

“SE (Secure Element)” stores security information (eg, mobile communication network access key, user identification information such as ID/passport, credit card information, encryption key, etc.), and a control module (eg: It refers to a security module composed of a single chip that can install and operate network access control modules such as USIM, encryption modules, key generation modules, etc.). SE can be used in various electronic devices (e.g., smartphones, tablets, wearable devices, automobiles, IoT devices, etc.), and security services (e.g., mobile communication network access, payment, user authentication, etc.) through security information and control modules. Can provide.

SE can be divided into UICC (Universal Integrated Circuit Card), eSE (Embedded Secure Element), and SSP (Smart Secure Platform) in which UICC and eSE are integrated. ), fixed (Embedded), and can be subdivided into integrated (Integrated) integrated in a specific device or SoC (system on chip).

"Universal Integrated Circuit Card (UICC)" is a smart card inserted into a mobile communication terminal and used, and is also called a UICC card. The UICC may include an access control module for accessing the mobile communication service provider's network. Examples of access control modules include Universal Subscriber Identity Module (USIM), Subscriber Identity Module (SIM), and IP Multimedia Service Identity Module (ISIM). UICC with USIM is also commonly referred to as a USIM card. Similarly, a UICC including a SIM module is commonly referred to as a SIM card. On the other hand, the SIM module may be installed when manufacturing the UICC or download a SIM module of a mobile communication service to be used at a time desired by the user to the UICC card. In addition, a plurality of SIM modules may be downloaded and installed on the UICC card, and at least one of them may be selected and used. Such a UICC card may or may not be fixed to the terminal. The UICC fixed to the terminal is called eUICC (embedded UICC), and in particular, a system-on-chip including a communication processor of the terminal, an application processor, or a single processor structure in which the two processors are integrated. The UICC built into (SoC) is sometimes referred to as iUICC (Integrated UICC). Typically, eUICC and iUICC are fixed to a terminal and used, and at least one SIM module is remotely downloaded to the UICC card, and it means a UICC card that includes a function of allowing any one of the downloaded SIM modules to be selected. can do. In the present disclosure, a UICC card including a function of remotely downloading at least one SIM module and allowing the SIM module to be selected is collectively referred to as eUICC or iUICC. That is, a UICC card that is fixed to a terminal or not fixed to a terminal among UICC cards including a function of remotely downloading a SIM module and allowing a SIM module to be selected is collectively referred to as eUICC or iUICC.

In the present disclosure, the term UICC may be mixed with SIM, and the term eUICC may be mixed with eSIM.

The “eUICC ID (eUICC ID)” may be a unique identifier of an eUICC embedded in the terminal, and may be referred to as an EID. In addition, when a provisioning profile is pre-loaded in the eUICC, the eUICC identifier (eUICC ID) may be an identifier of the corresponding provisioning profile (Provisioning Profile ID). In addition, in an embodiment of the present disclosure, when the terminal and the eUICC chip are not separated, the eUICC identifier (eUICC ID) may be the terminal ID. In addition, the eUICC identifier (eUICC ID) may refer to a specific secure domain of the eUICC chip.

"eSE (Embedded Secure Element)" refers to a fixed type SE that is fixed to an electronic device and used. The eSE is usually manufactured exclusively for the manufacturer at the request of the terminal manufacturer, and can be manufactured including an operating system and a framework. A service control module in the form of an applet can be downloaded and installed remotely in the eSE, and the installed service control module can be used for various security services such as electronic wallets, ticketing, e-passports, and digital keys. In the present disclosure, the service control module may be downloaded and installed remotely, and the SE in the form of a single chip attached to the electronic device is collectively referred to as eSE.

“SSP (Smart Secure Platform)” refers to a single chip that can support integrated functions of UICC and eSE. SSP can be divided into removable (rSSP, Removable SSP), fixed (eSSP, Embedded SSP) and integrated (iSSP, Integrated SSP) built-in SoC. The SSP may include one primary platform (PP) and at least one secondary platform bundle (SPB) operating on the PP, and the primary platform includes a hardware platform and a low level operating system (LLOS). ), and the secondary platform bundle may include at least one of a High-level Operating System (HLOS) and an application running on the HLOS. Secondary platform bundles are also referred to as SPBs or bundles. The bundle accesses resources such as the central processing unit and memory of the PP through the Primary Platform Interface (PPI) provided by the PP, and can be run on the PP through this. The bundle can be loaded with communication applications such as SIM (Subscriber Identification Module), USIM (Universal SIM), ISIM (IP Multimedia SIM), and various application applications such as e-wallets, ticketing, e-passports, and digital keys. I can. In the present disclosure, the SSP may be referred to as a smart security medium.

SSP is for the purpose of UICC or Ese described above depending on the downloaded and installed bundle. It can be used, and multiple bundles are installed in a single SSP and operated at the same time, so that the SSP can be used for a mixed purpose of UICC and eSE. That is, when a bundle including a profile is operated, the SSP can be used for UICC to access the network of a mobile communication service provider. In the UICC bundle, at least one or more profiles, such as eUICC or iUICC described above, are remotely downloaded into the bundle, and any one or more profiles may be selected. In addition, when a bundle including a service control module equipped with an application application capable of providing services such as an electronic wallet, ticketing, e-passport, or digital key is operated on the SSP, the SSP can be used for the purpose of the eSE described above. A plurality of service control modules may be installed and operated by being integrated into one bundle, or they may be installed and operated as independent bundles.

In the SSP, a bundle may be downloaded and installed from an external bundle management server (Secondary Platform Bundle Manager, SPB Manager) using Over The Air (OTA) technology, and a bundle may be transmitted and installed from another terminal. In the present disclosure, the method of installing the downloaded or transmitted bundle is a detachable SSP (rSSP) that can be inserted and removed in the terminal, a fixed SSP (eSSP) installed in the terminal, and an integrated SSP (iSSP) included in the SoC installed in the terminal. ) Can be applied equally.

The “SSP ID (SSP ID)” may be referred to as an sspID as a unique identifier of an SSP embedded in the terminal. In addition, as in the embodiment of the present disclosure, when the terminal and the SSP chip are not separated, the SSP ID may be the terminal ID. In addition, the SSP ID may refer to a specific bundle identifier (SPB ID) in the SSP. In more detail, the SSP ID may refer to a bundle identifier of a management bundle or loader (SPBL, Secondary Platform Bundle Loader) that manages installation, activation, deactivation, and deletion of other bundles in the SSP. In addition, the SSP ID may refer to an ID (Primary Platform Identifier) of the primary platform in the SSP. The SSP may have a plurality of SSP identifiers, and the plurality of SSP identifiers may be values derived from a single unique SSP identifier.

"SPB (Secondary Platform Bundle)" is driven by using the resources of PP on the primary platform (PP) of SSP. For example, the UICC bundle is an application, file system, and authentication key stored in the existing UICC. Values, etc. may mean packaging of the operating system (HLOS) in which they operate in software form. In this disclosure, an SPB may be referred to as a bundle.

In the present disclosure, the "state" of the bundle may be as follows.

[Enable]

In the present disclosure, the operation of enabling the bundle by the terminal or the external server is to change the state of the SPB to the enabled state so that the terminal provides services provided by the bundle (e.g., communication service, credit It may mean an operation of setting to receive a card payment service, a user authentication service, etc.). Bundles in the active state may be expressed as “enabled bundles”. The bundle in the activated state may be stored in an encrypted state in a storage space inside or outside the SSP.

[Active status (Active)]

The bundle activated in the present disclosure is driven by external input (eg, user input, push, request of an application in the terminal, authentication request from a carrier, PP management message, etc.) or an operation inside the bundle (eg, timer, polling). It can be changed to the state (Active). The running bundle is loaded into the driving memory inside the SSP from the storage space inside or outside the SSP, and the security information is processed using the security control unit (Secure CPU) inside the SSP, and the security service is provided to the terminal. It can mean a bundle.

[Disabled]

In the present disclosure, the operation of disabling the bundle by the terminal or the external server may mean an operation of changing the state of the bundle to a disabled state so that the terminal cannot receive the services provided by the bundle. have. The SPB in the deactivated state may be expressed as a "disabled bundle". The inactive bundle may be stored in an encrypted state in a storage space inside or outside the SSP.

[Deleted]

In the present disclosure, when the terminal or the external server deletes the bundle, the terminal or the external server no longer causes the terminal or external server to change the state of the bundle to deleted or delete the related data of the bundle including the bundle. It may mean an operation of setting so that the corresponding bundle cannot be driven, activated, or deactivated. Bundles in the deleted state may be expressed as "deleted bundles".

"Bundle Image, or Image" may be mixed with a bundle or used as a term indicating a data object of a specific bundle, and may be referred to as a bundle TLV or a bundle image TLV (Bundle Image TLV). When the bundle image is encrypted using an encryption parameter, the bundle image may be referred to as a protected bundle image (PBI) or a protected bundle image TLV (PBI TLV). When the bundle image is encrypted using an encryption parameter that can be decrypted only by a specific SSP, it may be referred to as a bound bundle image (BBI) or a bundled bundle image TLV (BBI TLV). The bundle image TLV may be a data set representing information constituting a bundle in a TLV (Tag, Length, Value) format.

The "bundle identifier" will be referred to as a factor matching the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), bundle family manager identifier (SPB Family Custodian Object ID), bundle matching ID, and event identifier (Event ID). I can. The bundle identifier (SPB ID) may indicate a unique identifier of each bundle. The bundle family identifier may indicate an identifier for classifying the type of a bundle (eg, a telecom bundle for accessing a mobile communication company network). In the present disclosure, the bundle family identifier may be referred to as Famaily ID, Fid, or FID. The bundle family manager identifier may indicate an identifier that identifies a subject that manages the bundle family identifier (eg, a communication service provider, a terminal manufacturer, a specific organization, etc.). In the present disclosure, the bundle family manager identifier may be referred to as OID or Oid. The bundle identifier can be used as a value that allows the bundle management server or terminal to index the bundle.

"Bundle metadata" is a term representing a set of information that can refer to or describe a bundle. Bundle metadata may include the bundle identifier described above. In addition, the bundle metadata may further include information on properties, characteristics, or settings of the bundle. Bundle metadata may be expressed as "metadata".

"Profile" may mean a data object such as an application, a file system, and an authentication key value stored in the UICC.

In the present disclosure, the "profile package" may mean that the contents of the "profile" are packaged in the form of software that can be installed in the UICC. The “profile package” may be referred to as a profile package TLV (Profile Package TLV). When the profile package is encrypted using an encryption parameter, it may be referred to as a protected profile package (PPP) or a protected profile package TLV (PPP TLV). When the profile package is encrypted using an encryption parameter that can be decrypted only by a specific eUICC, it may be referred to as a bound profile package (BPP) or a bound profile package TLV (BPP TLV). The profile package TLV may be a data set representing information constituting a profile in a TLV (Tag, Length, Value) format.

In the present disclosure, the'profile image' may mean binary data of a profile package installed in the UICC. The'profile image' may be referred to as a Profile TLV or a profile image TLV. When the profile image is encrypted using an encryption parameter, it may be referred to as a protected profile image (PPI) or a protected profile image TLV (PPI TLV). When the profile image is encrypted using an encryption parameter that can be decrypted only by a specific eUICC, it may be referred to as a bound profile image (BPI) or a bound profile image TLV (BPI TLV). The profile image TLV may be a data set representing information constituting a profile in a TLV (Tag, Length, Value) format.

In the present disclosure, the "state" of the profile may be as follows.

[Enable]

In the present disclosure, the operation of enabling the profile by the terminal means an operation of changing the state of the profile to the enabled state so that the terminal can receive communication services through the communication service provider that provided the profile. can do. The profile in the active state may be expressed as an "enabled profile".

[Disable]

In the present disclosure, the operation of disabling a profile by a terminal means an operation of changing the state of the profile to a disabled state so that the terminal cannot receive communication service through a communication service provider that provided the profile. can do. The profile in the inactive state may be expressed as a "disabled profile".

[Delete]

In the present disclosure, an operation in which the terminal deletes a profile may refer to an operation of changing a state of a corresponding profile to a deleted state so that the terminal can no longer activate or deactivate the corresponding profile. The profile in the deleted state may be expressed as a "deleted profile".

In the present disclosure, the operation of enabling, disabling, or deleting a profile by the terminal is performed by setting the state of each profile to an enabled state, a disabled state, or a deleted state. Without changing immediately, each profile is marked as to be enabled, to be disabled, or to be deleted, and the terminal or UICC of the terminal is displayed. Changing each profile to an enabled, disabled, or deleted state after performing a specific action (e.g., performing a refresh or reset command). It can also mean action. Marking a specific profile as scheduled (i.e., to be enabled, to be disabled, or to be deleted) must be performed for one profile. It is not limited to displaying the scheduled status of, but is not limited to, displaying one or more profiles as the same or different from each other, displaying one profile as one or more scheduled states, or displaying one or more profiles as the same or different from each other. It is also possible to display the status.

In addition, when the terminal displays one or more scheduled states for an arbitrary profile, the two scheduled state indications may be integrated into one. For example, when an arbitrary profile is displayed in a to be disabled and to be deleted state, the corresponding profile may be displayed in an integrated state to be disabled and deleted.

In addition, the operation of the terminal to display a predetermined state for one or more profiles may be performed sequentially or simultaneously. In addition, the operation of the terminal displaying the predetermined state for one or more profiles and then changing the state of the actual profile may be performed sequentially or simultaneously.

The "Profile Identifier" is a Profile ID, ICCID (Integrated Circuit Card ID), Matching ID, Event ID, Activation Code, Activation Code Token, and Command Code. Code), Command Code Token, Signed Command Code, Unsigned Command Code, ISD-P or Profile Domain (PD). May be referred to. The profile ID may indicate a unique ID of each profile. The profile identifier may further include an address of a profile providing server (SM-DP+) capable of indexing the profile. In addition, the profile identifier may further include a signature of the profile providing server (SM-DP+).

The "bundle management server" creates a bundle at the request of a service provider or other bundle management server, encrypts the generated bundle, generates a bundle remote management command, or encrypts the generated bundle remote management command. May contain functions. Bundle management servers that provide the above-described functions are SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), IDS (Image Delivery Server), SM-DP (Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation). plus), Admin Bundle Server, Managing SM-DP+ (Managing Subscription Manager Data Preparation plus), Bundle Encryption Server, Bundle Generation Server, Bundle Provisioner (BP), Bundle Provider, BPC holder (Bundle Provisioning Credentials) holder).

In the present disclosure, the bundle management server may download, install, or update a bundle from the SSP, and may play a role of managing key and certificate settings for remotely managing the state of the bundle. Bundle management servers providing the above-described functions include Secondary Platform Bundle Manager (SPBM), Remote Bundle Manager (RBM), Image Delivery Server (IDS), Subscription Manager Secure Routing (SM-SR), and Subscription Manager Secure Routing (SM-SR+). Plus), an off-card entity of eUICC Profile Manager, PMC holder (Profile Management Credentials holder), and EM (eUICC Manager).

In the present disclosure, the opening brokerage server may receive an event registration request (Register Event Request, Event Register Request) from one or more bundle management servers or opening brokerage servers. In addition, one or more opening brokerage servers may be used in combination, and in this case, the first opening brokerage server may receive an event registration request from not only the bundle management server but also the second opening brokerage server. In the present disclosure, the function of the opening intermediary server may be integrated into the bundle management server. The opening intermediary server that provides the above-described functions is SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), SPBDS (Secondary Platform Bundle Discovery Sever), BDS (Bundle Discovery Sever), SM-DS (Subscription Manager Discovery Service). , DS (Discovery Service), Root SM-DS, and Alternative SM-DS.

In the present disclosure, the bundle management server may mean a server that performs both a function of generating, encrypting, and transmitting a bundle or bundle remote management command, and a function of setting an SSP and managing an installed bundle. In addition, the bundle management server may mean a server capable of further performing an opening intermediary server function. Accordingly, in various embodiments of the present disclosure, operations of the bundle management server and the opening intermediary server may be performed in one bundle management server. In addition, each function may be separately performed by a plurality of bundle management servers separated from each other. In addition, in the specification of the present disclosure, the bundle management server or the opening intermediary server may be expressed as a bundle server. The bundle server may be one of a bundle management server and an opening brokerage server, or may be a device including all functions or configurations of the bundle management server and the opening brokerage server.

The “RSP server (Remote SIM Provisioning Server)” may be used as a name to refer to a profile providing server and/or a profile management server and/or an opening intermediary server to be described later. The RSP server may be expressed as SM-XX (Subscription Manager XX).

In the present disclosure, the "profile providing server" may include a function of generating a profile, encrypting the generated profile, generating a profile remote management command, or encrypting the generated profile remote management command. Profile providing server, SM-DP (Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation plus), off-card entity of Profile Domain, profile encryption server, profile creation server, profile provider (Profile Provisioner, PP) , Profile Provider, and PPC holder (Profile Provisioning Credentials holder).

In the present disclosure, the “profile management server” may include a function for managing a profile, and the profile management server includes a Subscription Manager Secure Routing (SM-SR), a Subscription Manager Secure Routing Plus (SM-SR+), an off-card entity of It can be expressed as eUICC Profile Manager or PMC holder (Profile Management Credentials holder), EM (eUICC Manager), PP (Profile Manager), and the like.

In the present disclosure, the profile providing server may mean a combination of the functions of the profile management server. Accordingly, in various embodiments of the present disclosure, the operation of the profile providing server may be performed in the profile management server. Similarly, the operation of the profile management server or the SM-SR may be performed in the profile providing server.

In the present disclosure, the "opening brokerage server" may be expressed as a subscription manager discovery service (SM-DS), a discovery service (DS), a root brokerage server (Root SM-DS), and an alternative brokerage server (Alternative SM-DS). have. The opening brokerage server may receive an event registration request (Register Event Request, Event Register Request) from one or more profile providing servers or opening brokerage servers. In addition, one or more opening brokerage servers may be used in combination, and in this case, the first opening brokerage server may receive an event registration request from the second opening brokerage server as well as the profile providing server.

"Service Provider" may refer to a business that issues a request to a bundle management server to request a bundle creation, and provides a service to a terminal through the bundle. For example, a service provider may mean a mobile operator that provides a communication network access service through a bundle equipped with a communication application, and a business support system (BSS) and an operation support system of the communication service provider. (Operational Supporting System, OSS), POS terminal (Point of Sale Terminal), and other IT systems can all be collectively referred to. In addition, in the present disclosure, the service provider is not limited to expressing only one specific business entity, and may be used as a term referring to a group or association or consortium of one or more businesses or an agency representing the group or association. . In addition, in the present disclosure, a service provider may be named as a business operator (Operator or OP or Op.), a bundle owner (BO), an image owner (Image Owner, IO), etc., and each service provider is a name and/or At least one unique identifier (Object Identifier, OID) may be set or assigned. If the service provider refers to a group or association or agency of more than one business entity, the name or unique identifier of any group or association or agency is shared by all businesses belonging to that group or association, or by all businesses working with the agency. It may be a name or a unique identifier.

"Mobile operator" can refer to a business that provides communication services to a terminal, and a business supporting system (BSS), operational supporting system (OSS), POS terminal ( point of sale terminal), and other IT systems. In addition, in the present disclosure, a communication service provider is not limited to expressing only one specific business entity that provides a communication service, and a term referring to a group or association of one or more business entities (association or consortium), or an agency representing the group or association. It can also be used as. In addition, in the present disclosure, a communication service provider is an operator (operator or OP or Op.), a mobile network operator (MNO), a mobile virtual network operator (MVNO), a service provider (service provider or SP), It may be named as a profile owner (PO), etc., and each communication service provider may set or be assigned at least one or more names and/or object identifiers (OIDs) of the communication service provider. If a telecommunications operator refers to a group or association or agency of more than one business entity, the name or unique identifier of any group or association or agency is shared by all businesses belonging to the group or association or all businesses working with the agency. It may be a name or a unique identifier.

"Subscriber" may be used as a term referring to a service provider having ownership of a terminal or an end user having ownership of a terminal. In general, a terminal owned by a service provider may be referred to as an M2M terminal, and a terminal owned by a user may be referred to as a user terminal (Consumer Device). In the case of an M2M terminal, there may be an end user who does not have ownership of the terminal but transfers or leases the terminal from a service provider, and in this case, the subscriber may be different from or the same as the service provider.

"Subscriber intent" may be used as a term collectively referring to the intention that the subscriber intends to manage the bundle locally or remotely. In addition, in the case of local management, the subscriber intent refers to an end user intent, and in the case of remote management, the subscriber intent may be used as a term that refers to a service provider intent.

"End User consent" may be used as a term indicating whether a user agrees to perform local management or remote management.

The'terminal' includes a mobile station (MS), a user equipment (UE), a user terminal (UT), a wireless terminal, an access terminal (AT), a terminal, a subscriber unit, and a subscriber station (SS); Subscriber Station), wireless device, wireless communication device, wireless transmit/receive unit (WTRU), mobile node, mobile or other terms. Various embodiments of the terminal include a cellular phone, a smart phone having a wireless communication function, a personal portable terminal (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, and a digital camera having a wireless communication function. Devices, gaming devices having a wireless communication function, music storage and playback appliances having a wireless communication function, Internet appliances capable of wireless Internet access and browsing, as well as portable units or terminals incorporating combinations of such functions. have. In addition, the terminal may include a machine to machine (M2M) terminal and a machine type communication (MTC) terminal/device, but is not limited thereto. In the present disclosure, the terminal may also be referred to as an electronic device.

In the present disclosure, an SSP capable of downloading and installing a bundle may be embedded in an electronic device. When the SSP is not embedded in the electronic device, the SSP physically separated from the electronic device may be inserted into the electronic device and connected to the electronic device. For example, the SSP may be inserted into an electronic device in the form of a card. The electronic device may include a terminal, and the terminal may be a terminal including an SSP capable of downloading and installing a bundle. The SSP may be embedded in the terminal, and may be inserted into the terminal when the terminal and the SSP are separated, or inserted into the terminal to be connected to the terminal.

In the present disclosure, a UICC capable of downloading and installing a profile may be embedded in the electronic device. When the UICC is not embedded in the electronic device, the UICC physically separated from the electronic device may be inserted into the electronic device and connected to the electronic device. For example, in the form of a card, the UICC may be inserted into an electronic device. The electronic device may include a terminal, and in this case, the terminal may be a terminal including a UICC capable of downloading and installing a profile. The UICC may be embedded in the terminal, and when the terminal and the UICC are separated, the UICC may be inserted into the terminal, or inserted into the terminal to be connected to the terminal. A UICC that can be installed by downloading a profile may be referred to as eUICC, for example.

“Local Bundle Assistant (LBA)” may refer to software or applications installed in a terminal or electronic device to control the SSP. The above-described software or application may be referred to as a Local Bundle Manager (LBM).

The “loader (SPBL, Secondary Platform Bundle Loader)” may refer to a management bundle that manages installation, activation, deactivation, and deletion of other bundles in the SSP. The LBA of the terminal or the remote server can install, activate, deactivate, or delete a specific bundle through the loader. In the present disclosure, the operation of the loader may also be described as the operation of the SSP including the loader.

“LPA (Local Profile Assistant)” may refer to software or applications installed in the terminal or electronic device to control the UICC or eUICC in the terminal or electronic device.

"Event" may be used for the following purposes in the present disclosure.

[When used in connection with a bundle]

"Event" may be a term collectively referring to bundle download, remote bundle management, or other management/processing instructions of a bundle or SSP. The event can be named as a remote bundle provisioning operation (or RBP operation, or RBP operation) or an event record, and each event is an event identifier corresponding thereto. , Event ID, EventID) or matching identifier (Matching Identifier, Matching ID, MatchingID), and at least one address (FQDN, IP Address, or URL) or each server identifier of the bundle management server or opening brokerage server in which the event is stored It can be identified as the data it contains. Bundle Download can be mixed with Bundle Installation. In addition, Event Type is a term indicating whether a specific event is a bundle download, remote bundle management (e.g., deletion, activation, deactivation, replacement, update, etc.), or other management/processing commands of the bundle or SSP. Can be used. In addition, the event type is the operation type (Operation Type or OperationType), operation classification (Operation Class or OperationClass), event request type (Event Request Type), event classification (Event Class), event request classification (Event Request Class). ), etc.

"Local Bundle Management (LBM)" means Bundle Local Management, Local Management, Local Management Command, Local Command, Local Bundle Management Package ( LBM Package), Bundle Local Management Package, Local Management Package, Local Management Command Package, Local Command Package, and the like. LBM installs an arbitrary bundle through software installed on the terminal, changes the status of a specific bundle (Enabled, Disabled, Deleted), or changes the contents of a specific bundle (e.g., the bundle nickname). , Or bundle summary information (Bundle Metadata), etc.). The LBM may contain more than one local management command, and the bundles subject to each local management command may be the same or different for each local management command.

"Remote Bundle Management (RBM)" is a bundle remote management (Bundle Remote Management), remote management (Remote Management), remote management command (Remote Management Command), remote command (Remote Command), remote bundle management package ( RBM Package), Bundle Remote Management Package, Remote Management Package, Remote Management Command Package, Remote Command Package, etc. RBM installs an arbitrary bundle, changes the state of a specific bundle (Enabled, Disabled, Deleted), or changes the content of a specific bundle (e.g., bundle nickname, or bundle summary information (Bundle Metadata), etc.) can be used for updating. The RBM may contain more than one remote management command, and the bundles subject to each remote management command may be the same or different for each remote management command.

"Target Bundle" may be used as a term referring to a bundle that is a target of a local management command or a remote management command.

"Bundle Rule" may be used as a term referring to information to be checked by the terminal when performing local management or remote management on a target bundle. Also, the bundle rule may be used interchangeably with terms such as a bundle policy, a rule, and a policy.

[When used in relation to a profile]

"Event" may be a term collectively referring to Profile Download, Remote Profile Management, or other profile or eUICC management/processing commands. Event (Event) may be named as a remote SIM provisioning operation (Remote SIM Provisioning Operation, or RSP operation, or RSP Operation) or event record (Event Record), and each event (Event) corresponding to the event identifier (Event Identifier) , Event ID, EventID) or matching identifier (Matching Identifier, Matching ID, MatchingID), and the address (FQDN, IP Address, or URL), a signature of the profile providing server (SM-DP+) or the opening brokerage server (SM-DS), and at least one digital certificate of the profile providing server (SM-DP+) or the opening brokerage server (SM-DS) It may be referred to as data to be performed.

Data corresponding to an event may be referred to as a “command code”. Some or all of the procedure using the command code may be referred to as "command code processing procedure" or "command code procedure" or "LPA API (Local Profile Assistant Application Programming Interface)". Profile Download can be mixed with Profile Installation.

In addition, "Event Type" is a term that describes whether a particular event is a profile download, remote profile management (eg delete, activate, deactivate, replace, update, etc.), or other profile or eUICC management/handling command. It can be used, and can be named as an operation type (Operation Type or OperationType), an operation classification (Operation Class or OperationClass), an event request type, an event class, an event request class, etc. I can. As for an arbitrary event identifier (EventID or MatchingID), a path or usage purpose (EventID Source or MatchingID Source) for which the terminal obtains the corresponding event identifier (EventID or MatchingID) may be designated.

"Local Profile Management (LPM)" is Profile Local Management, Local Management, Local Management Command, Local Command, Local Profile Management Package ( LPM Package), Profile Local Management Package, LOCAL MANAGEMENT PACKAGE, Local Management Command Package, and Local Command Package. LPM changes the status of a specific profile (Enabled, Disabled, Deleted) through software installed on the terminal, or the contents of a specific profile (e.g., Profile Nickname, Profile Metadata, etc.) ) Can be used for updating. The LPM may include more than one local management command, and in this case, the profile subject to each local management command may be the same or different for each local management command.

"Remote Profile Management (RPM)" refers to Profile Remote Management, Remote Management, Remote Management Command, Remote Command, and Remote Profile Management Package ( RPM Package), Profile Remote Management Package, Remote Management Package, Remote Management Command Package, and Remote Command Package. RPM changes the status of a specific profile (Enabled, Disabled, Deleted), or updates the content of a specific profile (e.g., Profile Nickname, Profile Metadata, etc.). Can be used for purposes. The RPM may include more than one remote management command, and in this case, the target profile of each remote management command may be the same or different for each remote management command.

“Certificate” or digital certificate is a mutual authentication based on an asymmetric key consisting of a pair of a public key (PK) and a secret key (SK). It may represent a digital certificate used for. Each certificate includes at least one public key (PK), a public key identifier (PKID) corresponding to each public key, and the identifier of the certificate issuer (CI) that issued the certificate (Certificate Issuer ID) and digital signature. In addition, a certificate issuer may be referred to as a certification issuer, a certificate authority (CA), a certification authority, or the like. In the present disclosure, a public key (PK) and a public key identifier (Public Key ID, PKID) are a specific public key, a certificate including the public key, or a part of a specific public key or a certificate including the public key. A part or a result of an operation of a specific public key (e.g., hash), or a result of an operation of a certificate containing the public key (e.g., hash), or a part of a specific public key It refers to an operation result (e.g., hash) value or an operation result (e.g., hash) value of a part of the certificate containing the corresponding public key, or a storage space in which data is stored. Can be used.

"Certificate Chain" or Certificate Hierarchy is used by certificates (primary certificates) issued by the "Certificate Issuer" to issue other certificates (secondary certificates), or 2 When secondary certificates are used to issue third or higher certificates in connection, the correlation between the corresponding certificates can be indicated. At this time, the CI certificate used for issuing the initial certificate is the Root of Certificate, the Top Certificate, the Root CI, the Root CI Certificate, the Root CA, and the Root CA. Certificate).

And, in describing the present disclosure, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present disclosure, the detailed description thereof will be omitted.

Hereinafter, various embodiments of a method and apparatus for moving and installing a bundle between terminals will be described.

1 shows a conceptual diagram of an SSP 120 according to an embodiment of the present disclosure.

Referring to FIG. 1, according to an embodiment of the present disclosure, a terminal 110 may include an SSP 120. For example, the SSP 120 may be embedded in the SoC 130 of the terminal 110. In this case, the SoC 130 may be a communication processor, an application processor, or a processor in which the two processors are integrated. For another example, the SSP 120 may be a detachable type 122 in the form of an independent chip without being integrated into the SoC, or may be a built-in type 124 built in advance in the terminal 110.

According to various embodiments, the SSP 120 included in the terminal may include at least one of one or more telecom bundles, one or more payment bundles, and one or more electronic identification card bundles. For example, as shown in FIG. 1, when a plurality of telecom bundles 140 and 150 are included in the SSP 120, the terminal 110 simultaneously transmits a plurality of telecom bundles 140 and 150 according to the setting. Alternatively, it is possible to use a mobile communication network by operating in time division. In addition, when the payment bundle 170 and the electronic identification card bundle 180 are included in the SSP 120, the terminal 110 uses the payment bundle 170 to make online payment through a terminal app or an external credit card PoS (Point Offline payment through the device can be used, and the identity of the terminal owner can be authenticated using the electronic identification card bundle 180.

2 shows a conceptual diagram of an internal structure of a Smart Secure Platform (SSP) 210 according to an embodiment of the present disclosure.

Referring to FIG. 2, according to an embodiment of the present disclosure, the SSP 210 includes one primary platform (PP) 220 and at least one secondary platform bundle operating thereon. SPB) (230, 240) may be included.

According to various embodiments, the primary platform 220 may include hardware (not shown) and at least one low level operating system (LLOS) 222.

According to various embodiments, the secondary platform bundle 230 may include a high-level operating system (HLOS) 232 and at least one application 234 operating thereon.

According to various embodiments, each of the secondary platform bundles 230 and 240 accesses resources such as a central processing unit and memory of the primary platform 220 using a primary platform interface (PPI) 250 And through this, it can be driven in the SSP (210).

3 is a diagram illustrating an example of an internal component of a terminal for a terminal to download and install a bundle through an SSP according to an embodiment of the present disclosure.

Referring to FIG. 3, according to an embodiment of the present disclosure, the terminal 310 may include an LBA 312 for controlling the SSP 330 and/or the SSP 330. For example, the terminal 310 may be a terminal in which the SSP 330 is mounted and the LBA 312 for controlling the SSP 330 is installed. For example, the SSP 330 may be embedded in the terminal 310 or may be detachable.

According to various embodiments, the SSP 330 includes at least one of a primary platform 331, a secondary platform bundle loader (SPBL) 333, and one or more secondary platform bundles 335, 337, or 339. It can contain one.

According to various embodiments, the secondary platform bundle 335, 337, or 339 is not installed inside the SSP 330 at the time of terminal shipment, but may be downloaded and installed remotely after shipment.

According to various embodiments, as in the example of FIG. 3, each bundle may have different bundle family identifiers and/or bundle family manager identifiers 341, 342, and 343. These bundle family identifiers and/or bundle family manager identifiers 341, 342, and 343 may be used as information necessary for downloading and installing a bundle. That is, the SSP 330 or the SPBL 333 may allow or reject the download and installation of a specific bundle according to the bundle family identifier and/or the bundle family manager identifier 341, 342, and 343.

4 is a diagram illustrating an example of a method in which two terminals operate to perform bundle transmission between two terminals according to an embodiment of the present disclosure.

Referring to FIG. 4, according to an embodiment of the present disclosure, a terminal may include at least one LBA and at least one SSP. For example, the first terminal 400 includes a first LBA 410 and a first SSP 420, and the second terminal 450 includes a second LBA 460 and a second SSP 470 can do.

According to various embodiments, the user may send a command to the terminal or receive information to be provided by the user from the terminal. For example, as in operations 4010 and 4060, the first and second users 440 and 490 command the first and second LBAs 410 and 460 of the first and second terminals 400 and 450. Or receive information to be provided by the user from the first and second LBAs 410 and 460. The first user 410 and the second user 460 may refer to different users or may refer to the same user.

According to various embodiments, the operation of the user sending a command to the terminal or receiving information to be provided by the user from the terminal (hereinafter, the first operation) may include a process of selecting a bundle to be transmitted by the user. have. In addition, the first operation may further include a process of checking information on a bundle that the user desires to receive. In addition, the first operation may further include an operation of approving whether to transmit a bundle to be transmitted by the user. In addition, the first operation may further include an operation of approving whether to transmit a bundle to be transmitted by the user. The above-described selection and approval operations are independent operations, and not all operations may be performed, or one or more operations may be independently selected and performed.

In addition, in operations 4020 and 4070, the first and second LBAs 410 and 460 give commands to the first and second SSPs 420 and 470, or the first and second SSPs 420 and 470 and data Can send and receive.

According to an example, the first/second LBA (410, 460) issues a command to the first/second SSP (420, 470) or transmits and receives data with the first/second SSP (420, 470). In operation (hereinafter, second operation), each LBA may transmit a user's command received in the first operation to the SSP. Each LBA can receive the result transmitted by the SSP as a result of the command transmitted to the SSP.

According to another example, in the second operation, each LBA may transmit a command or data received from another terminal or an external server to the SSP. Each LBA can receive the result transmitted by the SSP as a result of the command or data transmitted to the SSP.

According to various embodiments, in the second operation, each LBA may define a new command and data based on a command of a user or a command or data received from another terminal or an external server, and transmit the defined new command and data to the SSP. . Each LBA can receive the results sent by the SSP as a result of the new commands and data it delivers.

According to various embodiments, in the second operation, the first and second LBAs 410 and 460 and the first and second SSPs 420 and 470 may transmit and receive data to each other and install a bundle.

According to various embodiments, in operation 4050 (hereinafter, operation 3), the first and second LBAs 410 and 460 may be connected to each other to give a command to a counterpart or transmit/receive data with the counterpart. In operation 3, the connection of 4050 may be a direct device-to-device connection between the first terminal 400 and the second terminal 450, and although not shown, the connection between the first LBA 410 and the second LBA 460 It may be an indirect device-to-device connection to which an external object (eg, an external server) is connected. A more detailed description of a connection method between the first LBA 410 and the second LBA 460 will be described with reference to the accompanying drawings.

According to various embodiments, in operations 4030 and 4080, the first and second SSPs 420 and 470 may generate, process, or verify necessary data inside the first and second SSPs 420 and 470. .

According to various embodiments, the first and second SSPs 420 and 470 generate, process, or verify necessary data inside the first and second SSPs 420 and 470 (hereinafter, fourth operation). In, each SSP can check the bundle movement setting. In addition, in the fourth operation, each SSP may generate and utilize a bundle movement code. In addition, the operation related to the bundle movement setting and the operation related to the bundle movement code are independent functions, and both functions may not be executed, only one of the two functions, or both functions may be executed. Even when both functions are executed, both functions can be performed as completely independent functions.

According to various embodiments, in the fourth operation, each SSP may generate its own SSP information or verify SSP information received from a counterpart terminal. In addition, in the fourth operation, each SSP may generate authentication data capable of verifying itself and may verify authentication data received from a counterpart terminal.

According to various embodiments, in the fourth operation, each SSP may generate or install a bundle.

5 is a diagram illustrating a configuration of a "verifiable Secondary Platform Bundle Loader (SPBL) list (verifiable_SPBL_list)" according to some embodiments of the present disclosure.

The "verifiable SPBL list" may be provided by the SSP manufacturer for each SPBL, may be provided by the terminal manufacturer, or may be provided through collaboration between the SSP manufacturer and the terminal manufacturer. One SPBL can use the "verifiable SPBL list" to perform mutual authentication with another SPBL.

The SPBL, which is the subject of verification using the "verifiable SPBL list", will be referred to as "SPBL A". Referring to FIG. 5, in the "Verifiable SPBL list", certificate information that other SPBLs can use to verify SPBL A (Spbl column in FIG. 5) and certificate information that SPBL A can use to verify other SPBLs. (The trustedSpbl column of FIG. 5) may be included.

According to an embodiment of the present disclosure,'certificate information that another SPBL can use to verify SPBL A'and'certificate information that SPBL A can use to verify another SPBL' are,

a) The bundle family identifier and the bundle family manager identifier may be set in an assigned state (510 and 530 in FIG. 5).

b) Alternatively, the bundle family identifier may be assigned and the bundle family manager identifier may be set to an unassigned state (550 in FIG. 5).

c) Alternatively, the bundle family identifier and the bundle family manager identifier may be set in an unassigned state (570 in FIG. 5).

'Certificate information that other SPBLs can use to verify SPBL A'is the certificate issued to SPBL A, the chain of certificates issued to SPBL A, and the validity of the signature generated by SPBL A, which other SPBLs can use to verify. Certificate information may be included. 'Certificate information that SPBL A can use to verify other SPBLs' may include certificate information that SPBL A can use to verify the validity of certificates, certificate chains, and signatures presented by other SPBLs.

6A and 6B are diagrams illustrating two possible configurations of a "trusted SPBL list (trusted_SPBL_list)" according to some embodiments of the present disclosure.

The "trusted SPBL list" may be provided by a service provider to each SPBL, may be provided by a bundle management server, or may be provided through cooperation between a service provider and a bundle management server. One SPBL can use the provided "trusted SPBL list" to determine whether another SPBL can be trusted.

6A is a diagram illustrating one possible configuration of a "trusted SPBL list (trusted_SPBL_list)" according to some embodiments of the present disclosure.

Referring to FIG. 6A, the "trusted SPBL list" may include information for identifying a specific bundle. For example, the "trusted SPBL list" may include a bundle identifier (spbID) 6010.

The "trusted SPBL list" further includes a bundle family identifier (SPB Family ID) 6030 and/or a bundle family manager identifier (SPB Family Custodian Object ID) 6050 associated with the bundle identified by the spbID 6010. I can.

The "trusted SPBL list" may further include an information list 6070 of the receiving SPBL that the service provider and/or the bundle management server trusts that the sending SPBL may transmit the bundle identified by the spbID 6010. The information list (6070) of the trusted receiving SPBL is

a) It may be information that can identify the SPBL that the service provider and/or the bundle management server trusts to transmit the bundle.

b) It may be certificate information capable of authenticating the SPBL that the service provider and/or the bundle management server trusts that the bundle may be transmitted.

The "trusted SPBL list" may further include a policy 6090 related to the bundle identified by the spbID 6010. Some examples of possible policies 6090 are: When the device or the SPBL wants to transmit the bundle identified as spbID 6010 to another device or SPBL, the policy 6090 for determining whether the SPBL to receive the bundle can be trusted is the SPBL that will receive the bundle.

a) The policy that the bundle can be trusted if it is included in the "verifiable SPBL list" of the SPBL to which the bundle is to be transmitted, as described with reference to FIG. 5,

b) The policy that it can be trusted if it is included in the "trusted SPBL list",

c) A policy that trust must be included in both "verifiable SPBL list" and "trusted SPBL list", or

d) If it is included in one of the "verifiable SPBL list" and the "trusted SPBL list", the policy that it can be trusted may be included.

6B is a diagram illustrating another configuration of a "trusted SPBL list (trusted_SPBL_list)" according to some embodiments of the present disclosure.

Referring to FIG. 6B, the "trusted SPBL list" may include a list of information of a receiving SPBL (a trustedSpbl column in FIG. 6B) that a service provider and/or a bundle management server trusts that a transmitting SPBL may transmit a bundle. . Since the information list of the trusted reception SPBL of FIG. 6B may correspond to the information list of the trusted reception SPBL 6070 of FIG. 6A, a detailed description thereof will be omitted. However, the information list of the trusted reception SPBL of FIG. 6B (the trustedSpbl column of FIG. 6B) is different from the information list 6070 of the trusted reception SPBL of FIG. 6A. ), but may be a list of information applied to an arbitrary bundle. For example, the information list of the trusted reception SPBL of FIG. 6B may be used regardless of the transmitted/received bundle identifier (SPB ID). However, as described later, the information list of the trusted reception SPBL of FIG. 6B may be used in a state mapped to the bundle family identifier (Fid) and/or the bundle family manager identifier (Oid), or the bundle family identifier (Fid). ) And the bundle family manager identifier (Oid) may be used irrespective of (ie, unmapped).

The "trusted SPBL list" may further include a policy (the Policy column of FIG. 6B) to be used to determine whether the received SPBL to receive the bundle is reliable. Since a detailed description of the policy of FIG. 6B may correspond to the policy 6090 of FIG. 6A, a detailed description will be omitted.

'Information list of trusted receiving SPBL' and'policy' are

a) The bundle family identifier and the bundle family manager identifier may be set in an assigned state (6510 and 6530 in FIG. 6B)

b) Alternatively, the bundle family identifier may be assigned and the bundle family manager identifier may be set in an unassigned state (6550 in FIG. 6B).

c) Alternatively, the bundle family identifier and the bundle family manager identifier may be set in an unassigned state. (6570 in Fig. 6B)

7 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure.

Referring to FIG. 7, according to various embodiments, a terminal may include at least one LBA and at least one SSP. For example, the first terminal 700 includes a first LBA 720 and a first SSP 710, and the second terminal 750 includes a second LBA 770 and a second SSP 760. can do. For example, the first terminal 700 may be a terminal equipped with a first SSP 710 and a first LBA 720 for controlling the first SSP 710, and the second terminal 750 2 It may be a terminal in which the SSP 760 is mounted and the second LBA 770 for controlling the second SSP 760 is installed.

In step 7000, the first SSP 710, the first LBA 720 of the first terminal 700, and the second LBA 770 of the second terminal 750 are prepared for bundle transmission. Procedure) can be performed. For a more detailed description of the bundle transmission preparation procedure, reference will be made to the detailed description of FIG. 8 to be described later.

In step 7005, a procedure (bundle transmission and installation procedure) in which the bundle is transmitted from the first terminal 700 to the second terminal 750 and the bundle is installed in the second terminal 750 may be performed. For a more detailed description of the bundle transmission and installation procedure, reference will be made to the detailed description of FIG. 9 to be described later.

FIG. 8 is a diagram illustrating a detailed procedure for a procedure for preparing for bundle transmission among the procedures presented in FIG. 7. In more detail, FIG. 8 is a diagram illustrating a procedure for a preparation process necessary for one terminal to transmit a bundle to another terminal according to an embodiment of the present disclosure. In this specification, the procedure of FIG. 8 may be referred to as a bundle transmission preparation procedure.

Referring to FIG. 8, according to various embodiments, a terminal may include at least one LBA and at least one SSP. For example, the first terminal 800 includes a first LBA 820 and a first SSP 810, and the second terminal 850 includes a second LBA 8700 and a second SSP 860 can do. As an example, the first terminal 800 may be a terminal equipped with a first SSP 810 and a first LBA 820 for controlling the first SSP 810, and the second terminal 850 2 It may be a terminal in which the SSP 860 is mounted and the second LBA 870 for controlling the second SSP 860 is installed.

According to various embodiments, the first terminal 800 may have a pre-installed bundle, and may further have metadata associated with the pre-installed bundle.

According to various embodiments, the first terminal 800 includes at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), or a bundle family manager identifier (SPB Family Custodian Object ID) related to an installed bundle. You may have it.

According to various embodiments, the first terminal 800 may have a'bundle movement setting' related to an already installed bundle.

'Bundle Movement Settings' is information on whether a bundle can be moved between devices. It may have been created by the service provider, the first provider of the bundle, or it may have been created by the bundle management server, or the aforementioned service provider and bundle management. It may have been created by server collaboration. The'bundle movement setting' can be updated by a service provider, a bundle management server, or cooperation between a service provider and a bundle management server. Alternatively, at least one of the service provider and the bundle management server and the terminal may cooperate with each other to update the'bundle movement setting'. When and/or how the update is performed may be determined by a policy of a service provider, a bundle management server, and a terminal manufacturer.

The'bundle movement setting' may optionally include a factor (or indication) indicating whether transmission between devices of the corresponding bundle is allowed. In addition, the'bundle movement setting' may optionally further include a factor specifying under what conditions the transmission is allowed when transmission between devices of the corresponding bundle is allowed. For example, the bundle movement setting may include information on which connection between devices can transmit the bundle. In this case, the possible connection may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), a wireless connection such as 5G D2D or a wired connection through a cable), or It may be a remote connection in which a remote server (eg, a relay server) is located between the first LBA 820 and the second LBA 870.

In addition, the'bundle movement setting' may include a setting for a mutual authentication method to be performed when a bundle is transmitted between devices. For example, when the terminal to which the bundle is to be transmitted authenticates the terminal to receive the bundle, information received from the service provider and/or the bundle management server (eg, "trusted_SPBL_list" shown in FIG. 6A or 6B) Information on whether additional authentication should be performed using may also be included in the'bundle movement setting'. If this additional authentication is set to be required, the service provider and/or the bundle management server provides authentication information related to the trusted terminal and/or SSP to the terminal transmitting the bundle, and the terminal transmitting the bundle receives the bundle. The bundle may be transmitted after authentication using information provided whether the terminal to be performed is a terminal that the service provider and/or the bundle management server can trust.

In step 8000, the first LBA 820 may obtain information on a bundle to be transmitted between devices. Alternatively, information on a bundle to be transmitted between devices may be transmitted to the first LBA 820. For example, the first LBA 820 may obtain information of a bundle to be transmitted by receiving a user input for selecting a bundle through a UI provided by the first terminal 800 by a user, or a push input from a remote server. Information of a bundle to be transmitted through may be input to the first LBA 820, or the first LBA 820 may access a remote server to read information of a bundle to be transmitted.

In addition, in step 8000, the first LBA 820 may check whether a corresponding bundle can be transmitted between devices using a'bundle movement setting'.

Also, in step 8000, the first LBA 820 may generate'bundle transmission information'. The bundle transmission information may include a bundle identifier such as a bundle identifier (SPB ID) of a bundle to be transmitted, a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID). In addition, the bundle transmission information may further include other information indicating the properties of the bundle (eg, metadata of the bundle or part of the metadata). Also, the bundle transmission information may include an address (SPBM Addr) of a bundle management server linked to a bundle to be transmitted. The bundle transmission information may include information necessary for connection between two terminals to be made in step 8025. For example, information necessary for wi-fi connection of two terminals (e.g., SSID and/or BSSID of the first terminal 800, a Pre Shared Key to be used for connection authentication of two terminals, an IP address of the first terminal 800, The port number to be used for communication between the two terminals) may be included.

In step 8005, information related to the bundle selected (or acquired) through step 8000 may be transferred from the first LBA 820 to the first SSP 810. For example, information related to the selected bundle may be transmitted from the first LBA 820 to the first SSP 810 through the Select SPB command. The information related to the bundle transmitted from the first LBA 820 to the first SSP 810 may include information for identifying the bundle selected in step 8000.

In step 8010, the first SSP 810 may check whether the bundle requested to be transmitted can be transmitted between devices. In the process of determining whether transmission between devices is possible, the first SSP 810 identifies the bundle requested to be transmitted based on the information received in step 8005, and checks the'bundle movement setting' associated with the identified bundle. It can be done by doing. .

Also, in step 8010, the first SSP 810 may set a'bundle movement code'. The'bundle movement code' is a code used to refer to a bundle transmitted during a transmission process between devices of the bundle, and is a value that can identify a transmitted bundle. The first SSP 810 may bind the'bundle movement code' and information of the bundle to be transmitted.

In step 8015, a response to step 8005 may be transmitted from the first SSP 810 to the first LBA 820. For example, a response to the Select SPB command in step 8005 may be transmitted from the first SPB 810 to the first LBA 820 through the Select SPB response in step 8015. The response may include the'bundle movement code' described in step 8010.

According to an embodiment of the present disclosure, steps 8005 to 8015 described above may be omitted.

In step 8020, information necessary for inter-device bundle transmission may be transferred from the first LBA 820 of the first terminal 800 to the second LBA 870 of the second terminal 850. In this case, the information transmitted from the first LBA 820 to the second LBA 870 may include'bundle transmission information'. Alternatively, information transmitted from the first LBA 820 to the second LBA 870 may include a'bundle movement code'. In addition, the information transmitted from the first LBA 820 to the second LBA 870 may further include a bundle family identifier (SPB Family ID) and/or a bundle family manager identifier (SPB Family Custodian Object ID). In addition, the information transmitted from the first LBA 820 to the second LBA 870 includes information necessary for connection to be established between the first LBA 820 and the second LBA 870 in a future step 8025. It may contain more. In addition, the information transmitted from the first LBA 820 to the second LBA 870 may further include information indicating that a bundle movement between devices is to be performed.

Information transferred from the first LBA 820 to the second LBA 870 through operation 8020 may be transferred in various ways. For example, the first LBA 820 may provide information to be transmitted to the second LBA 870 to the first user of the first terminal 800 through the UI of the first terminal 800. The first user may provide the provided information to the second user of the second terminal 850. The second user may input the provided information into the second LBA 870 using the UI of the second terminal 850. Alternatively, the first LBA 820 creates information to be transmitted to the second LBA 870 in the form of an image (for example, a QR code) and displays it on the screen of the first terminal 800, and the second user Information may be transmitted to the second LBA 870 by scanning the image displayed on the screen of the first terminal 800 using the second terminal 850. However, a method of transferring information from the first LBA 820 to the second LBA 870 is not limited to the above-described methods and may be variously determined. The first user and the second user may refer to different users or may refer to the same user.

In step 8025, a connection may be established (or established) between the first LBA 820 and the second LBA 870. The first LBA 820 and the second LBA 870 may establish a connection using information transmitted to the second LBA 870 in step 8020. The connection between the first LBA 820 and the second LBA 870 is a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), wireless connection such as 5G D2D) or It may be a wired connection through a cable) or a remote connection in which a remote server (eg, a relay server) is located between the first LBA 820 and the second LBA 870.

Step 8025 can be performed as the last step. However, step 8025 is an independent step from the other steps described above, that is, steps 8000, 8005, 8010, 8015, and 8020, and the order in which step 8025 is performed is not limited by what is shown in FIG. 8, and other steps are performed. It can be irrelevant to the order in which they are made. For example, step 8025 may be performed between steps 8015 and 8020. In this case, information transmitted from the first LBA 820 to the second LBA 2 870 in step 8020 is through the connection established in step 8025. It can also be transmitted.

9 is a diagram illustrating a detailed procedure for a procedure in which a bundle is transmitted and installed among the procedures described in FIG. 7. In more detail, FIG. 9 is a diagram illustrating a procedure in which one terminal transmits a bundle to another terminal and a bundle is installed in another terminal according to an embodiment of the present disclosure. In the present disclosure, the procedure of FIG. 9 may be referred to as a bundle transmission and installation procedure.

Referring to FIG. 9, according to various embodiments, a terminal may include at least one LBA and at least one SSP. For example, the first terminal 900 includes a first LBA 920 and a first SSP 910, and the second terminal 950 includes a second LBA 970 and a second SSP 960 can do. For example, the first terminal 900 may be a terminal equipped with a first SSP 910 and a first LBA 920 for controlling the first SSP 910, and the second terminal 950 2 It may be a terminal in which the SSP 960 is mounted and the second LBA 970 for controlling the second SSP 960 is installed.

In step 9000, the second LBA 970 may request "SSP information (SspInfo)" from the second SSP 960. When the second LBA 970 requests "SSP information (SspInfo)" from the second SSP 960, the second LBA 970 may inform the second SSP 960 that the inter-device bundle movement is to be performed. In addition, for example, a D2D indicator may be included in the request message. The second LBA 970 may inform the second SSP 960 that the inter-device bundle movement is to be performed by including the D2D indicator in the request message or setting the value of the D2D indicator to 1. The second LBA 970 may provide information on a bundle to be transmitted between devices to the second SSP 960. This information may include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID).

In addition, step 9000 may be automatically performed immediately following the entire process described in FIG. 8, or may be performed after receiving an external input. In this case, the'external input' may be a user input for selecting a bundle to be directly transmitted by the second user of the second terminal through a UI provided by the second terminal 950, and the second LBA 970 from the remote server It may be a push input input to the user. In addition, the second LBA 970 may access a remote server and read information on a bundle to be transmitted.

In step 9005, the second SSP 960 may generate its own "SSP information". The "SSP information" may include information on the second SSP 960 to be provided for bundle transmission.

In this case, the "SSP information" may include information (certificate negotiation information) for a certificate negotiation process that the second SSP 960 must go through before receiving the bundle. "Certificate negotiation information" refers to certificate information that can be used by the second SSP 960 to verify another SSP (SenderSpblVerification) and certificate information that can be used by another SSP to verify the second SSP (960) (ReceiverSpblVerification). It may include. In addition, the "certificate negotiation information" may further include a list of key agreement algorithms supported by the second SSP 960, and may further include a list of encryption algorithms supported by the second SSP 960. The second SSP 960 may generate "certificate negotiation information".

When the second SSP 960 is provided with a bundle family identifier (SPB Family ID) and/or a bundle family manager identifier (SPB Family Custodian Object ID) in step 9000, in some cases, "certificate negotiation information" is a bundle family identifier. Alternatively, it may be selected based on the value of the bundle family manager identifier, and "SSP information" may further include a bundle family identifier and a bundle family manager identifier along with certificate negotiation information. A detailed description of the procedure for configuring "certificate negotiation information" by using the value of the bundle family identifier or the bundle family manager identifier by the second SSP 960 (in particular, a procedure for configuring SenderSpblVerification and ReceiverSpblVerification) will be described in FIG. 10 to be described later. I will refer to it.

In addition, "SSP information" may further include SSP version information including at least one version information among version information of a standard standard supported by the primary platform and loader included in the second SSP 960.

In step 9010, the second SSP 960 may transmit "SSP information" generated in step 9005 to the first SSP 910 through the second LBA 970 and the first LBA 920.

According to steps 9000 to 9010, after the second LBA 970 requests "SSP information (SspInfo)" from the second SSP 960, and the second SSP 960 generates its own "SSP information" , The second SSP 960 may transmit “SSP information” to the first SSP 910 through the second LBA 970 and the first LBA 920. However, depending on the embodiment, the second LBA 970 may generate “SSP information” by itself and then transmit the “SSP information” to the first SSP 910 through the first LBA 920.

In step 9015, the first SSP 910 checks the received "SSP information" and generates "first terminal authentication information (Device1.Auth)" that can authenticate the first SSP 910 based on this information. can do. A more specific procedure for the process of generating "first terminal authentication information (Device1.Auth)" is as follows.

1) Confirmation procedure

The first SSP 910 may check certificate information capable of verifying the first SSP 910 using the received "SenderSpblVerification" and select at least one key agreement certificate (ssp1.Cert.KA). Alternatively, the first SSP 910 uses the received “list of key agreement algorithms supported by the second SSP 960” to use the public key “ssp1.ePK. After creating "KA" and the private key "ssp1.eSK.KA", you can select the public key (ssp1.ePK.KA) from this key pair. In addition, the first SSP 910 may check certificate information capable of verifying the first SSP 910 using the received "SenderSpblVerification" and further select at least one signing certificate (ssp1.Cert.DS). A detailed description of a procedure for the first SSP 910 to select the certificate information of the first SSP 910 using "SenderSpblVerification" will be described with reference to the description of FIG. 11 to be described later.

In addition, the first SSP 910 may select at least one certificate information of the second SSP 960 to be verified using the received “ReceiverSpblVerification” and then set information corresponding to the selected certificate information to “CiPkIdToBeUsed”. . For a detailed description of a procedure for the first SSP 910 to select the certificate information of the second SSP 960 using "ReceiverSpblVerification", reference will be made to the description of FIG. 11 to be described later.

In addition, the first SSP 910 selects at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 960", and then selects information corresponding to the selected encryption algorithm as "CryptoToBeUsed". Can be set. In addition, the first SSP 910 checks the list of the received "version information of the primary platform included in the second SSP 960 and the standard standard supported by the loader", and among them, the version of the standard standard that it also supports. You can check whether it exists or not.

2) First terminal authentication information generation procedure

“First terminal authentication information (Device1.Auth)” may include at least one of “ssp1.Cert.KA”, “ssp1.ePK.KA”, “CiPkIdToBeUsed”, and “CryptoToBeUsed” described above. In addition, the "first terminal authentication information (Device1.Auth)" may further include the above-described "ssp1.Cert.DS". In addition, the "first terminal authentication information (Device1.Auth)" may further include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future. .

At this time, part or all of the "first terminal authentication information (Device1.Auth)" may be digitally signed so that it can be verified using ssp1.Cert.DS to ensure the integrity of the information, and the digital signature data It may be added as part of "terminal authentication information".

In operation 9020, the first SSP 910 may transmit “first terminal authentication information (Device1.Auth)” generated in operation 9015 to the second LBA 970 through the first LBA 920.

In step 9025, the second LBA 970 may transmit "first terminal authentication information (Device1.Auth)" to the second SSP 960. In addition, the second LBA 970 may further transmit a "bundle movement code" to the second SSP 960. In addition, the second LBA 970 may further transmit a bundle identifier (SPB ID) of a bundle to be transmitted to the second SSP 960.

In step 9030, the second SSP 960 may verify the received "first terminal authentication information (Device1.Auth)". When the second SSP 960 receives "ssp1.Cert.KA", it may check the validity of "ssp1.Cert.KA" by checking the signature of "ssp1.Cert.KA". In addition, when the second SSP 960 receives "ssp1.ePK.KA" and a digital signature for it, it first checks the validity of ssp1.Cert.DS and then verifies the digital signature using ssp1.Cert.DS. By doing so, the integrity of the received public key ssp1.ePK.KA can be verified. In addition, the second SSP 960 may select at least one signing certificate (ssp2.Cert.DS) capable of verifying the second SSP 960 based on the received "CiPkIdToBeUsed".

Further, in step 9030, the second SSP 960 generates a public key "ssp2.ePK.KA" and a private key "ssp2.eSK.KA", which are asymmetric encryption key pairs to be used for key agreement. , You can select the public key (ssp2.ePK.KA) among these key pairs. In addition, the second SSP 960 selects one of the public key for key agreement or ssp1.ePK.KA included in ssp1.Cert.KA, and then uses the selected value and ssp2.eSK.KA to use the first terminal (in the future) ( 900) can generate a session key ShKey01 to be used for encryption. ShKey01 may be a session key for an encryption algorithm included in "CryptoToBeUsed" received from the first SSP 910.

Also, in step 9030, the second SSP 960 may generate “second terminal authentication information (Device2.Auth)” capable of authenticating the second SSP 960. In this case, the "second terminal authentication information (Device2.Auth)" may include "ssp2.Cert.DS". In addition, the "second terminal authentication information (Device2.Auth)" may further include "ssp2.ePK.KA". In addition, the "second terminal authentication information (Device2.Auth)" may further include a transaction ID indicating a current session generated by the second SSP 960. In addition, the "second terminal authentication information (Device2.Auth)" may further include a "bundle movement code". In addition, the "second terminal authentication information (Device2.Auth)" may further include a bundle identifier of a bundle to be transmitted. In addition, the "second terminal authentication information (Device2.Auth)" may further include an SSP identifier of the second SSP 960. In addition, the "second terminal authentication information (Device2.Auth)" may further include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future. .

At this time, part or all of the "second terminal authentication information (Device2.Auth)" may be digitally signed so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information, and the digital signature data is It may be added as part of "terminal authentication information". In addition, some or all of the "second terminal authentication information (Device2.Auth)" may be encrypted using the previously generated session key ShKey01.

In step 9035, the second SSP 960 passes through the second LBA 970 and the first LBA 920 to the first SSP 910, the "second terminal authentication information (Device2.Auth)" generated in step 9030. Can be delivered. In this case, a "bundle movement code" may be further transmitted.

In step 9040, the first SSP 910 may verify the received "second terminal authentication information (Device2.Auth)". The first SSP 910 may verify the validity of the "ssp2.Cert.DS" by verifying the signature of the received "ssp2.Cert.DS". In addition, the first SSP (910) is a bundle family identifier (SPB Family ID) and / or bundle family manager identifier (SPB Family Custodian Object ID) received is correctly set in association with the bundle to be transmitted by the first SSP (910). You can check if it is a value. In particular, the first SSP 910 may check whether the bundle is a bundle that can be transmitted to the second terminal by checking the bundle movement setting associated with the received bundle identifier. In addition, the first SSP 910 checks whether the bundle is normally installed and operated in the second terminal (eg, the SSP of the second terminal) using the received bundle identifier and the received information of the second terminal. can do. In addition, the first SSP 910 may store the received transaction ID and/or the SSP identifier of the second SSP 960. In addition, the first SSP 910 may bind the received transaction ID or the SSP identifier of the second SSP 960 with a currently ongoing session or a bundle to be transmitted.

In the process of verifying the "second terminal authentication information (Device2.Auth)", if the encrypted data is included in the "second terminal authentication information (Device2.Auth)", the first SSP 910 transmits the received ssp2. The session key ShKey01 is generated by using the private key corresponding to the public key for key agreement or ssp1.eSK.KA included in the ssp1.Cert.KA of the .ePK.KA and the first SSP 910, and the generated session key ShKey01 is generated. After decrypting the encrypted data using the key ShKey01, the verification process can be performed. In addition, in the process of verifying the "second terminal authentication information (Device2.Auth)", if the digital signature is included in the "second terminal authentication information (Device2.Auth)", the first SSP 910 is "ssp2. You can use ".Cert.DS" to verify the validity of the received digital signature.

Further, in step 9040, the first SSP 910 has a public key "ssp1.bundle.ePK.KA" and a private key "ssp1.bundle.eSK.KA", which are asymmetric encryption key pairs to be used for key agreement. Can be created. The key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" may be set to the same value as "ssp1.ePK.KA and ssp1.eSK.KA" created in step 9015. Alternatively, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" may be set to the same value as the "public key included in ssp1.Cert.KA and the corresponding private key". Also, the first SSP 710 may generate the session key ShKey02 using ssp1.bundle.eSK.KA and ssp2.ePK.KA. If the private key corresponding to the public key included in ssp1.eSK.KA or'ssp1.Cert.Ka' is reused for ssp1.bundle.eSK.KA, the value of the session key ShKey02 is also the value of the previously generated ShKey01. Can be set to a value.

In addition, in operation 9040, the first SSP 910 may configure a bundle to be transmitted to the second terminal 950 and/or metadata associated with the bundle. In this case, the first SSP 910 may identify a bundle to be transmitted by the first SSP 910 using the received "bundle movement code". In addition, "ssp1.Cert.DS" may be included in the configured bundle. In addition, the configured bundle may further include "ssp1.bundle.ePK.KA". In addition, the configured bundle may further include a transaction ID identifying a corresponding session. In addition, the configured bundle may further include at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID) associated with the bundle to be transmitted. According to various embodiments, a "bundle movement setting" may be included in a bundle (or metadata associated with the bundle) configured in operation 9040.

According to various embodiments, digital signature data generated using ssp1.Cert.DS may be added to the bundle configured in step 9040. That is, digital signature data generated for some or all components of the bundle may be added as a part of the bundle. In addition, part or all of the configured bundle may be encrypted using ShKey02.

In step 9045, the first SSP 910 may deliver the bundle generated (configured) in step 9040 to the second LBA 970 through the first LBA 920. In this case, metadata associated with the transmitted bundle may be further transmitted. In addition, a "bundle movement setting" associated with the transmitted bundle may be further transmitted. For example, the “bundle movement setting” is not included in the bundle or metadata, but may be transmitted in a separate format (eg, a message). In addition, a "trusted SPBL list (trusted_SPBL_list)" may be further transmitted.

In step 9050, the second LBA 970 and the second SSP 960 may cooperate with each other to install a bundle in the second terminal 950. When metadata is transmitted, the second LBA 970 or the second SSP 960 may verify content included in the metadata. When the "bundle movement setting" is transmitted, the second LBA 970 may transmit the "bundle movement setting" information to the second SSP 960. When a transaction ID is transmitted, the second LBA 970 or the second SSP 960 may check whether the received transaction ID is the same as the transaction ID used in the current session. When at least one of the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family manager identifier (SPB Family Custodian Object ID) is transmitted, the second LBA 970 or the second SSP 960 is received. It is possible to check whether the identified identification information matches the identification information of the bundle to be currently received. When the ssp1.Cert.DS is transmitted, the second SSP 960 may authenticate the first SSP 910 by verifying the validity of the ssp1.Cert.DS. When the transmitted data contains encrypted data, the second SSP 960 generates the session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and the ssp2.eSK.KA of the second SSP 960. And, you can perform verification after decrypting the encrypted data using this session key. When the digital signature is included in the received data, the second SSP 960 may verify the validity of the digital signature using ssp1.Cert.DS after verifying ssp1.Cert.DS. The second LBA 970 and the second SSP 960 may install a bundle in the second terminal 950 based on the above-described verification, authentication, and verification results.

10 is a diagram illustrating an example of a procedure for generating supportable certificate information according to a request of a second LBA by a second SSP of a second terminal according to some embodiments of the present disclosure. FIG. 10 may correspond to an embodiment of the detailed procedure of step 9005 of FIG. 9.

In FIG. 10, the second SSP of the second terminal may hold "verifiable SPBL list" information shown in FIG. 5.

Referring to FIG. 10, in step 10001, a second SSP may receive a request for certificate information from a second LBA. In step 10003, the second SSP may determine whether a bundle family identifier for a specific bundle and a bundle family manager identifier are included in the certificate information request transmitted from the second LBA.

If the certificate information request includes both the bundle family identifier and the bundle family manager identifier, the second SSP proceeds to step 10101 to determine whether the second SSP supports the bundle family identifier and the bundle family manager identifier. have. That is, it may be determined whether or not the bundle family identifier and certificate information set in the bundle family manager identifier exist in the "verifiable SPBL list" information held by the second SSP. For example, referring to FIG. 5, when a bundle family identifier such as (FID1, Oid1) and a bundle family manager identifier are input from the second LBA, (FID1, Since a row corresponding to Oid1) exists, the second SSP may determine that the second SSP supports the corresponding bundle family identifier and bundle family manager identifiers FID1 and Oid1. Alternatively, when a bundle family identifier such as (FID2, Oid6) and a bundle family manager identifier are input from the second LBA, a row corresponding to (FID2, Oid6) exists in the "verifiable SPBL list" information held by the second SSP. Therefore, the second SSP may determine that the second SSP does not support the corresponding bundle family identifier and the bundle family manager identifiers FID2 and Oid6, especially the bundle family manager identifier Oid6.

In step 10101, if the certificate information set for the bundle family identifier and the bundle family manager identifier exists in the "verifiable SPBL list" information held by the second SSP, in step 10102, the second SSP is the corresponding bundle family identifier and the bundle family manager identifier. SSP information can be generated including the certificate information set in. More specifically, the second SSP is

a) After selecting the Spbl INFO List in the row corresponding to the bundle family identifier (Family ID) and the bundle family manager identifier (Oid), ReceiverSpblVerification can be configured using the certificate information included in the Spbl INFO List.

b) After selecting the Trusted Spbl INFO List in the row corresponding to the bundle family identifier (Family ID) and the bundle family manager identifier (Oid), SenderSpblVerification can be configured using the certificate information included in the Trusted Spbl INFO List.

If the certificate information set in the combination of the bundle family identifier and the bundle family manager identifier included in the certificate information request in step 10101 does not exist in the "verifiable SPBL list" information held by the second SSP, in step 10103, the second SSP It can be determined whether or not certificate information including a corresponding bundle family identifier exists in the "verifiable SPBL list" information held by the SSP. For example, referring to FIG. 5, when a bundle family identifier such as (FID2, Oid6) and a bundle family manager identifier are input from the second LBA, the second SSP is the corresponding bundle family identifier and the bundle family manager. It is determined that the combination of identifiers (FID2, Oid6) is not supported (in particular, it is determined that the bundle family manager identifier Oid6 is not supported), and the process proceeds to step 10103.

In step 10103, if there is certificate information including the bundle family identifier in the "verifiable SPBL list" information held by the second SSP, in step 10104, the second SSP includes the certificate information set in the bundle family identifier. Can generate information. For example, the second SSP may determine that the second SSP supports only the bundle family identifier FID2, and may select a value set in (FID2, *). More specifically, the second SSP is

a) After selecting the Spbl INFO List in the row corresponding to the (Family ID, *), ReceiverSpblVerification can be configured using the certificate information included in the Spbl INFO List.

b) After selecting the Trusted Spbl INFO List in the row corresponding to (Family ID, *), SenderSpblVerification can be configured using the certificate information included in the Trusted Spbl INFO List.

If the certificate information set in the bundle family identifier included in the certificate information request in step 10103 does not exist in the "verifiable SPBL list" information held by the second SSP, in step 10105, the second SSP includes the bundle family identifier and the bundle family manager. It is possible to generate SSP information including certificate information to which an identifier is not assigned. For example, referring to FIG. 5, when a bundle family identifier such as (FID3, OID1) and a bundle family manager identifier are input from the second LBA, the second SSP says that the second SSP does not support the bundle family identifier FID3. It is possible to determine and select a value in which the combination of Family ID and Oid is set to (*, *) within the "verifiable SPBL list" information held by the second SSP. And, using the selected value, the second SSP may generate SSP information. More specifically, the second SSP is

a) After selecting the Spbl INFO List in the row corresponding to (*,*), ReceiverSpblVerification can be configured using the certificate information included in the Spbl INFO List.

b) After selecting the Trusted Spbl INFO List in the row corresponding to (*,*), SenderSpblVerification can be configured using the certificate information included in the Trusted Spbl INFO List.

If the bundle family manager identifier does not exist in the certificate information request in step 10003, the second SSP may determine whether the bundle family identifier is included in the certificate information request transmitted from the second LBA in step 10005. For example, referring to FIG. 5, when only the FID is input from the second LBA, since the Oid does not exist in the second SSP, operation 10005 may be performed.

If only a specific bundle family identifier is included in the certificate information request in step 10005, in step 10201, the second SSP determines whether the certificate configuration including the bundle family identifier exists in the "verifiable SPBL list" information held by the second SSP. You can judge whether or not. For example, referring to FIG. 5, when only FID2 is included in the certificate information request, the second SSP is SSP setting information having FID2 in the “verifiable SPBL list” information held by the second SSP, for example, FIG. 5 It may be determined whether 530 or 550 of is present. The certificate setting including the corresponding bundle family identifier may refer to certificate information to which the corresponding bundle family identifier and the bundle family manager identifier are assigned, or certificate information to which the corresponding bundle family identifier is assigned and the bundle family manager identifier is not assigned.

If the certificate configuration including the bundle family identifier exists in the "verifiable SPBL list" information held by the second SSP, in step 10202, the second SSP generates SSP information using the certificate information including the bundle family identifier. can do. More specifically, the second SSP is

a) After selecting the Spbl INFO List of the row(s) including the corresponding bundle family identifier (Family ID), ReceiverSpblVerification can be configured using the certificate information included in the Spbl INFO List.

b) After selecting the Trusted Spbl INFO List of the row(s) including the corresponding bundle family identifier (Family ID), SenderSpblVerification can be configured using the certificate information included in the Spbl INFO List.

If the certificate setting including the bundle family identifier does not exist in step 10201, the second SSP is assigned a bundle family identifier and a bundle family manager identifier within the "verifiable SPBL list" information held by the second SSP in step 10203. It is possible to generate SSP information including certificate information that has not been registered. More specifically, the second SSP is

a) After selecting the Spbl INFO List in the row corresponding to (*,*), ReceiverSpblVerification can be configured using the certificate information included in the Spbl INFO List.

b) After selecting the Trusted Spbl INFO List in the row corresponding to (*,*), SenderSpblVerification can be configured using the certificate information included in the Trusted Spbl INFO List.

If the bundle family identifier does not exist in the certificate information request in step 10005, for example, if neither the bundle family identifier nor the bundle family manager identifier is included in the certificate information request, the second SSP is the second SSP in step 10007. SSP information can be generated including all certificate information set in. For example, the second SSP may generate SSP information including all of the "verifiable SPBL list" information shown in FIG. 5.

11 is an authentication capable of verifying the received information and authenticating itself based on this information when a first SSP of a first terminal according to some embodiments of the present disclosure receives supportable certificate information from a second terminal It is a diagram showing an example of a procedure for generating information. 11 may correspond to an embodiment of the detailed procedure of step 9015 of FIG. 9.

In FIG. 11, the first SSP of the first terminal may hold the "verifiable SPBL list" information described in FIG. 5. In addition, the first SSP of the first terminal may further hold the "trusted SPBL list" information described with reference to FIG. 6A or the "trusted SPBL list" information described with reference to FIG. 6B. The "trusted SPBL list" information described in FIG. 6A or 6B may already exist in the first terminal before step 9015 of FIG. 9, or may be obtained when necessary in step 9015 of FIG. 9. For a detailed description of the procedure for obtaining the "trusted SPBL list" information described in FIG. 6A or 6B by the first terminal, reference will be made to the description of FIG. 12 to be described later.

Referring to FIG. 11, in step 11001, a first SSP of a first terminal receives supportable certificate information (sspInfo) from a second terminal.

In step 11003, the first SSP of the first terminal may perform a verification process using "ReceiverSpblVerification" among the received certificate information. The detailed procedure of the verification process is as follows.

In step 11100, the first SSP extracts ReceiverSpblVerification from the received certificate information. Thereafter, in step 11105, the first SSP may perform the following procedure.

1. Create " Transmit SPBL List" and "Receive SPBL List Trusted by SPBL(Secondary Platform Bundle Loader)"

The first SSP uses the bundle family identifier and/or bundle family manager identifier information transmitted by itself in step 8020 of FIG. 8 and the "verifiable SPBL list" information described in FIG. 5 that it has, and the Spbl INFO List(s) and Select Trusted Spbl INFO List(s). The process of selecting Spbl INFO List(s) and Trusted Spbl INFO List(s) by using the bundle family identifier and/or bundle family manager identifier information and the "verifiable SPBL list" information described in FIG. 5 by the first SSP is illustrated in FIG. Since it may correspond to the contents described with respect to the process of the second terminal in 10, refer to FIG. 10. The Spbl INFO List selected on the basis of the "verifiable SPBL list" will be referred to as a "transmission SPBL list", and the selected Trusted Spbl INFO List will be referred to as a "receive SPBL list trusted by SPBL".

2. Create "List of incoming SPBLs trusted by Secondary Platform Bundle Manager (SPBM)" and/or "selected policies"

When the first SSP holds the "trusted SPBL list" information described in FIG. 6B, the first SSP includes the bundle family identifier and/or bundle family manager identifier information transmitted by the first SSP and the " Select Trusted Spbl INFO List(s) and/or Polices using the "trusted SPBL list" information. In more detail, the first SSP may select Trusted Spbl INFO List(s) and/or Polices according to at least one of the following methods.

a) When the first SSP transmits the bundle family identifier and the bundle family manager identifier, the Trusted Spbl INFO List(s) and/or Policies of the row including the corresponding Family ID and Oid are selected in FIG. 6B.

b) When the first SSP transmits only the bundle family identifier, select the Trusted Spbl INFO List(s) and/or Policies of the row in which the Family ID is included in FIG. 6B and * is included in the Oid.

c) When the first SSP does not transmit any of the bundle family identifier and the bundle family manager identifier, in FIG. 6B, the Trusted Spbl INFO List(s) and/or Policies of the row containing * in the Family ID and Oid are selected.

Alternatively, the first SSP may select Trusted INFO List(s) and/or Policies through a process similar to the process described in FIG. 10 instead of the processes a) to c). For example, the first SSP is the same as the method of selecting a row using'bundle family identifier and/or bundle family manager identifier information and the "verifiable SPBL list" shown in FIG. After selecting a row using the family identifier and/or bundle family manager identifier information and the "trusted SPBL list"' described in FIG. 6B, Trusted Spbl INFO List(s) and/or Policies of the selected row may be selected.

The Trusted Spbl INFO List selected based on the "trusted SPBL list" described in FIG. 6B will be referred to as "received SPBL list trusted by SPBM", and the Polices will be referred to as "selected policy".

When the first SSP has the "trusted SPBL list" described in FIG. 6A corresponding to the bundle to be transmitted (for example, it can be identified as an SPB ID), the first SSP is shown in FIG. 6A. Set the Trusted Spbl INFO List included in the "Trusted SPBL List" described above to the "Received SPBL List Trusted by SPBM", and the Polices included in the "Trusted SPBL List" described in FIG. 6A "Selected Policy" Set to.

3. Create "Trusted Received SPBL List"

The first SSP constructs a "trusted reception SPBL list" based on the above-described "received SPBL list trusted by SPBL" and/or "received SPBL list trusted by SPBM" and/or "selected policy". Some possible examples of the "trusted reception SPBL list" configured by the first SSP are as follows. "Trusted receiving SPBL list"

a) It may be the same as "received SPBL list trusted by SPBL",

b) It may be the same as "received SPBL list trusted by SPBM",

c) It may be an intersection of "received SPBL list trusted by SPBL" and "received SPBL list trusted by SPBM", or

d) It may be a union of a "received SPBL list trusted by SPBL" and a "received SPBL list trusted by SPBM".

Which of a) to d) is used by the first SSP as a "trusted receiving SPBL list" i) Does the first SSP have the "trusted SPBL list" information described in Fig. 6a or 6b, ii) It may be selected according to conditions such as what is the terminal and/or SSP manufacturer's policy, iii) what is the “selected policy” extracted earlier.

4. Select CiPkIdToBeUsed

The first SSP checks whether an intersection exists between the extracted ReceiverSpblVerification and the previously created "trusted receiving SPBL list", and if there is an intersection, selects the common certificate information of the two lists, and can set "CiPkIdToBeUsed" using the selected information. have.

In step 11005, the first SSP of the first terminal may perform a verification process other than "ReceiverSpblVerification" among the received certificate information. In particular, the procedure of the verification process using "SenderSpblVerification" is as follows. The first SSP checks whether an intersection exists between the received “SenderSpblVerification” and the previously described “transmission SPBL list”, then selects the common certificate information of the two lists when there is an intersection, and selects the signature and/or corresponding to the selected certificate information. Alternatively, you can choose a certificate for key agreement. A detailed procedure of another verification process performed by the first SSP using SspInfo may correspond to the content described in step 9015 of FIG. 9.

In addition, the verification processes included in 11005 and the verification process 11003 are independent verification processes, and the verification processes in each step may be irrelevant to the order in which other steps are performed.

In step 11007, the first SSP of the first terminal generates authentication information (Device.Auth) (ie, Device1.Auth) capable of authenticating itself. Since the detailed description of step 11007 may correspond to the content described in step 9015 of FIG. 9, a detailed description will be omitted.

12 is a diagram illustrating an example of a procedure for obtaining a "trusted SPBL list (trusted_SPBL_list)" by the terminal 1250 according to some embodiments of the present disclosure. The "trusted SPBL list (trusted_SPBL_list)" may be provided to the terminal 1250 through a service provider, a bundle management server, or cooperation between a service provider and a bundle management server.

Referring to FIG. 12, according to various embodiments, a terminal 1250 may include at least one LBA and at least one SSP. For example, the terminal 1250 may include an LBA 1270 and an SSP 1260. For example, the terminal 1250 may be a terminal equipped with an SSP 1260 and an LBA 1270 for controlling the SSP 1260.

In addition, according to various embodiments, the server 1200 may be a server operated by a service provider, a bundle management server, a server operated by cooperation between a service provider and a bundle management server, or a service It may be any server operated in connection with the provider and/or the bundle management server. In the description of this drawing, the term SPBM, which is one of the possible examples of the server, is used to refer to the server 1200, but as described above, the type of server is not limited to SPBM.

In step 12000, a Transport Layer Security (TLS) connection may be established between the SPBM 1200 and the LBA 1270.

In step 12005, the LBA 1270 may request a "trusted SPBL list (trusted_SPBL_list)" from the SPBM 1200. When requesting from the LBA 1270 to the SPBM 1200, information such as a bundle identifier (sbpID), a bundle family identifier (FID), and a bundle family manager identifier (OID) may be transmitted together.

In step 12010, the SPBM 1200 may generate a "trusted SPBL list (trusted_SPBL_list)". The "trusted SPBL list (trusted_SPBL_list)" may be a value previously stored in the SPBM 1200, or may be a value newly generated at the request of step 12005. In addition, the "trusted SPBL list (trusted_SPBL_list)" may be a value in the form described with reference to FIGS. 6A or 6B. At this time, the generated "trusted SPBL list (trusted_SPBL_list)" may further include information signed by the SPBM 1200 to ensure the integrity of the information.

In step 12015, the "trusted SPBL list (trusted_SPBL_list)" generated in step 12010 may be delivered from the SPBM 1200 to the LBA 1270.

In step 12020, a "trusted SPBL list (trusted_SPBL_list)" created in step 12010 may be delivered from the LBA 1270 to the SSP 1260.

In step 12025, the SSP 1260 may verify the received "trusted SPBL list (trusted_SPBL_list)". The verification process may include verifying the validity of the signature generated in step 12010. Also, the SSP 1260 may store the received "trusted SPBL list (trusted_SPBL_list)".

In step 12030, the SSP 1260 may transmit a result of the "trusted SPBL list (trusted_SPBL_list)" received to the LBA 1270. For example, the SSP 1260 may transmit the success or failure of verification and/or reception to the LBA 1270.

13 is a diagram illustrating a configuration of a terminal according to an embodiment of the present disclosure.

As shown in FIG. 13, the terminal may include a transceiver 1310 and at least one processor 1320. In addition, the terminal may further include an SSP 1330. For example, the SSP 1330 may be inserted into the terminal or may be embedded in the terminal. The at least one processor 1320 may also be referred to as a “control unit”. However, the configuration of the terminal is not limited to FIG. 13, and may include more or fewer components than the components illustrated in FIG. 13. According to some embodiments, the transmission/reception unit 1310, at least one processor 1320, and a memory (not shown) may be implemented in the form of one chip. In addition, when the SSP 1330 is embedded, it may be implemented in the form of a single chip, including the SSP 1330.

According to various embodiments, the transmission/reception unit 1310 may transmit and receive signals, information, and data according to various embodiments of the present disclosure with a transmission/reception unit of another terminal or an external server. The transceiver 1310 may include an RF transmitter that up converts and amplifies a frequency of a transmitted signal, and an RF receiver that amplifies a received signal with low noise and down converts the frequency. . However, this is only an embodiment of the transmission/reception unit 1310, and components of the transmission/reception unit 1310 are not limited to the RF transmitter and the RF receiver. In addition, the transmission/reception unit 1310 may receive a signal through a wireless channel, output it to the at least one processor 1320, and transmit a signal output from the at least one processor 1320 through a wireless channel.

According to various embodiments, the transmission/reception unit 1310 includes information on the SSP included in the other terminal from the transmission/reception unit of another terminal or an external server, authentication information for authenticating other terminals, authentication information for authenticating itself, bundle It is possible to send or receive movement code, bundle movement configuration, bundle, request information of a trusted SPBL list (trusted_SPBL_list), and a trusted SPBL list (trusted_SPBL_list).

Meanwhile, at least one processor 1320 is a component for overall control of the terminal. The at least one processor 1320 may control the overall operation of the terminal according to various embodiments of the present disclosure as described above.

Meanwhile, the SSP 1330 may include a processor or controller for installing and controlling a bundle, or may have an application installed.

According to various embodiments, at least one processor or controller in the SSP 1330 may determine whether to transmit a specific bundle by checking the bundle movement setting.

In addition, according to various embodiments, at least one processor or controller in the SSP may generate a bundle movement code to control a transmission process of a specific bundle.

In addition, according to various embodiments, at least one processor or controller in the SSP may generate its own SSP information, and may check and verify SSP information of another SSP transmitted from the outside.

In addition, according to various embodiments, at least one processor or controller in the SSP may generate authentication information capable of verifying itself, and may verify authentication information of another SSP transmitted from the outside.

In addition, according to various embodiments, the SSP 1330 may generate a bundle, and may install the bundle alone or in cooperation with one or more processors 1320. Also, the SSP 1330 may manage bundles.

In addition, according to various embodiments, the SSP 1330 may verify and/or store a trusted SPBL list (trusted_SPBL_list).

In addition, according to various embodiments, the SSP 1330 may operate under the control of the processor 1320. Alternatively, the SSP 1330 may include a processor or controller for installing and controlling a bundle, or may have an application installed. Some or all of the applications may be installed in the SSP 1330 or a memory (not shown).

Meanwhile, the terminal may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the terminal. In addition, the memory is a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium. In addition, the processor 1320 may perform various operations using various programs, contents, data, etc. stored in the memory.

14 is a diagram illustrating a configuration of a server according to an embodiment of the present disclosure. In this case, the server may be understood as the same concept as the server described in FIG. 12. As described in FIG. 12, the server may be a server operated by a service provider, a bundle management server, a server operated by collaboration between a service provider and a bundle management server, or a service provider and/or It may be any server operated in connection with the bundle management server. In the description of this drawing, the term "bundle management server", which is one of the possible examples of servers, is used to refer to the server, but as described above, the type of server is not limited to the bundle management server.

According to some embodiments, the bundle management server may include a transceiver 1410 and at least one processor 1420. However, the configuration of the bundle management server is not limited to FIG. 14, and may include more or fewer components than the components illustrated in FIG. 14. According to some embodiments, the transmission/reception unit 1410, at least one processor 1420, and a memory (not shown) may be implemented in the form of one chip.

According to some embodiments, the transmission/reception unit 1410 may transmit and receive signals, information, and data according to various embodiments of the present disclosure to and from the terminal. For example, the transceiver 1410 may receive a bundle identifier, a specific bundle family identifier, or a bundle family manager identifier from the terminal, and transmit a trusted SPBL list (trusted_SPBL_list) to the terminal.

The transceiver 1410 may include an RF transmitter that up-converts and amplifies a frequency of a transmitted signal, and an RF receiver that amplifies a received signal with low noise and down-converts a frequency. However, this is only an example of the transmission/reception unit 1410, and components of the transmission/reception unit 1410 are not limited to the RF transmitter and the RF receiver. In addition, the transmission/reception unit 1410 may receive a signal through a wireless channel, output it to at least one processor 1420, and transmit a signal output from the at least one processor 1420 through a wireless channel.

Meanwhile, at least one processor 1420 is a component for overall control of the bundle management server. The processor 1420 may control the overall operation of the bundle management server according to various embodiments of the present disclosure as described above. The at least one processor 1420 may be referred to as a control unit.

According to some embodiments, at least one processor 1420 may configure a trusted SPBL list (trusted_SPBL_list).

Meanwhile, the bundle management server may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the bundle management server. In addition, the memory is a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium. Also, the processor 1420 may perform various operations using various programs, contents, data, etc. stored in the memory.

15 is a diagram illustrating an example of a method in which two terminals interact to transmit a profile between two terminals according to an embodiment of the present disclosure.

As shown in FIG. 15, a first eSIM 1503 and a second eSIM 1523 are mounted on the first terminal 1500 and the second terminal 1520, respectively, and the first eSIM 1503 and the second Profiles (not shown) may be installed in the eSIM 1523, respectively. In addition, a first LPA 1501 and a second LPA 1521 may be installed in the first terminal 1500 and the second terminal 1520, respectively. The first eSIM 1503 and the second eSIM 1523 may be controlled by the first LPA 1501 and the second LPA 1521, respectively. The first user 1505 and the second user 1525 are connected to the eSIM (first eSIM 1503 and second eSIM 1523) of each terminal through the first LPA 1501 and the second LPA 1521, respectively. You can control the installed profile. In this case, the first user 1505 and the second user 1525 may be the same. In addition, the first LPA 1501 and the second LPA 1521 may be connected to each other to communicate. In this case, a possible connection method between LPAs will be referred to the description of the drawings to be described later.

The communication service provider 1560 is connected to the first RSP server 1540 and the second RSP server 1580, and the first LPA 1501 of the first terminal 1500 is connected to the first RSP server 1540. In addition, the second LPA 1521 of the second terminal 1520 may be connected to the second RSP server 1580. In this case, the first RSP server 1540 and the second RSP server 1580 may be the same or different from each other. In addition, when one or more operator servers are included in the configuration, each operator server may be connected to each separate RSP server, or at least one or more operator servers may be connected to the same RSP server. In addition, for convenience, FIG. 15 illustrates a case in which each of the first RSP server 1540 and the second RSP server 1580 is configured as a single server. However, depending on implementations and embodiments, one or more profile providing servers (SM-DP+) may be included in the server configuration, and one or more open mediation servers (SM-DS) that assist in creating a connection between a specific profile providing server and a terminal are provided. It can also be included in the server configuration. The configurations of various servers as described above may be simply indicated as a single RSP server in the following drawings.

16 is a diagram illustrating a configuration of a "trusted CI list" according to some embodiments of the present disclosure.

The'trusted CI list 1600 stored in the terminal' may be a list of eUICCs trusted by the terminal manufacturer and/or the eUICC manufacturer. Alternatively, the'trusted CI list 1600 stored in the terminal' may be a list of information that can be used to verify the eUICC trusted by the terminal manufacturer and/or the eUICC manufacturer. More specifically, the Trusted CI by Device Info(s) included in the'trusted CI list 1600 stored in the terminal' is

a) It may be information that can identify eUICC trusted by the terminal manufacturer and/or eUICC manufacturer,

b) It may be certificate information that can verify the eUICC trusted by the terminal manufacturer and/or the eUICC manufacturer. For example, this information may be public key information of the highest root certificate of the certificate chain of eUICC to verify the authenticity. Alternatively, this information may be public key ID (PKID) information of the highest root certificate of the certificate chain of eUICC to verify the reliability.

The'trusted CI list 1600 stored in the terminal' may be information generated and/or provided by the terminal manufacturer and/or the eUICC manufacturer.

The'trusted CI list 1600 stored in the terminal' may be previously stored in the terminal before the profile movement is performed. In addition, the'trusted CI list 1600 stored in the terminal' may be obtained from the terminal manufacturer and/or the eUICC manufacturer at a necessary time point when performing profile movement.

The'trusted CI list 1650 provided from the server' may mean a list of eUICCs trusted by a communication service provider and/or an RSP server. Alternatively, the'trusted CI list 1650 provided from the server' may be a list of information that can be used to verify the eUICC trusted by the communication service provider and/or the RSP server. More specifically, the Trusted CI by Server Info(s) included in the'list of trusted CIs provided from the server (1650)'

a) It may be information that can identify the eUICC trusted by the service provider and/or the RSP server.

b) It may be certificate information that can verify the eUICC trusted by the communication service provider and/or the RSP server. For example, this information may be public key information of the highest root certificate of the certificate chain of eUICC to verify the authenticity. Alternatively, this information may be public key ID (PKID) information of the highest root certificate of the certificate chain of eUICC to verify the reliability.

The'trusted CI list 1650 provided from the server' may be information generated and/or provided by a communication service provider and/or an RSP server.

The'trusted CI list 1650 provided from the server' may be pre-stored in the terminal before the profile movement is performed. In addition, the'trusted CI list 1650 provided from the server' may be obtained from the communication service provider and/or the RSP server at a necessary time point when performing profile movement.

17 is a diagram illustrating a procedure for transmitting a profile from one terminal to another terminal according to an embodiment of the present disclosure.

Although not shown in FIG. 17, the first terminal 1700 and the second terminal 1750 may each include an eUICC and an LPA therein, as shown in FIG. 15. Although not shown in FIG. 17, the first terminal ( 1700) may have a'profile movement setting'. According to various embodiments, the'profile movement setting' is a policy on whether a profile can be moved between devices, and may be generated by a communication service provider, may be generated by an RSP server, or the aforementioned communication service provider and RSP. It may have been created by server collaboration. According to various embodiments, the'profile movement setting' inside the terminal may be updated by a communication service provider, an RSP server, or cooperation between a communication service provider and an RSP server. Alternatively, at least one of the communication service provider and the RSP server and the terminal may cooperate with each other to update the'profile movement setting'. The timing and/or method of updating the'profile movement setting' may be determined by a policy of a communication service provider, an RSP server, or a terminal manufacturer.

'Profile movement setting' may include a factor (or indication) indicating whether transmission between devices of the corresponding profile is allowed. In addition, the'profile movement setting' may optionally further include a factor specifying under what conditions transmission is allowed when transmission between devices of the corresponding profile is allowed. For example, when the terminal to which the profile is to be transmitted authenticates the terminal to receive the profile, authentication must be performed using information received from the communication service provider and/or the RSP server (for example, a trusted CI list provided from the server shown in FIG. 16). Whether or not it can also be included in the'Profile Move Settings'. That is, the communication service provider and/or the RSP server provides authentication information related to the terminal and/or eUICC to which it(s) can trust and/or verify, and the terminal to which the profile is to be transmitted is the terminal to receive the profile and/or It may be necessary to authenticate whether the eUICC is a terminal and/or eUICC that the communication service provider and/or the RSP server can trust using the previously provided authentication information.

In addition, the'profile movement setting' is based on information indicating whether transmission of the profile is allowed between devices and/or information on under what conditions the transmission of the profile is allowed when transmission between devices is allowed ( Alternatively, at least one or more generated signature information may be further included. The at least one or more signature information may be, for example, information generated by at least one of an RSP server, a communication service provider, a terminal manufacturer, an eUICC, and an eUICC manufacturer. In addition, the at least one or more signature information may further include authentication information for at least one (ie, part or all) of, for example, an RSP server, a communication service provider, a terminal manufacturer, an eUICC, or an eUICC manufacturer. In addition, the'profile movement setting' may further include signature information of the RSP server for at least one (ie, part or all) of the at least one authentication information further included as described above.

Referring to FIG. 17, in step 17000, a profile to be transmitted may be selected (or determined). This selection or determination process may be performed through a process in which the user directly selects a profile through a user interface (UI) provided by the first terminal 1700, or to the first terminal 1700 through a push input from a remote server. It may be input, or the first terminal 1700 may access the remote server and read the corresponding information. When the first terminal 1700 provides a UI to a user, a list of all profiles installed in the terminal may be provided through this UI, or only a list of profiles that can be moved may be provided. When a list of profiles that are not currently available for movement is provided, information indicating the possibility of movement of the profile shown in the list may be additionally provided to the UI. In addition, information such as profile information or profile movement policy may be selectively further provided through the UI in addition to the profile list described above.

In step 17000, the first terminal 1700 may check (or identify) whether the profile can be moved by checking the'profile movement setting'. The first terminal 1700 transmits the selected (or determined) profile to the second terminal 1750 based on the confirmation or identification result of whether the profile can be moved or not for the profile selected (or determined) to be transmitted. You can perform the procedure to do it. For example, the first terminal 1700 may perform step 17005 on the basis of a result of confirming or identifying whether the profile can be moved. In addition, when the first terminal 1700 checks the'profile movement setting' and subsequently authenticates the second terminal 1750, the information received from the communication service provider and/or the RSP server (for example, the reliability provided from the server shown in FIG. You can check whether authentication should be performed using (list of possible CIs).

In step 17005, a connection may be created between the first terminal 1700 and the second terminal 1750. For example, the connection between the first terminal 1700 and the second terminal 1750 may be a wireless communication connection. The connection between the first terminal 1700 and the second terminal 1750 may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), 5G D2D) or It may be a remote connection in which a remote server (eg, a relay server) is located between the first terminal 1700 and the second terminal 1750.

In step 17010, the second terminal 1750 may transmit its own eUICC information (eUICC2.Info1). eUICC2.Info1 may include an arbitrary string (eUICC2.Challenge) generated by the eUICC of the second terminal. eUICC2.Info1 may include version information(s) supported by the eUICC of the second terminal. eUICC2.Info1 may include'certificate information that can be used to verify the eUICC of the second terminal'(s). eUICC2.Info1 may include'certificate information that can be used to verify the eUICC of another terminal'(s).

In step 17015, the first terminal 1700 may check the received eUICC2.Info1. The first terminal 1700 may use the received eUICC2.Info1 to check whether there is a version supported by the second terminal among the eUICC versions supported by the second terminal. The first terminal 1700 may select a certificate eUICC1.Cert capable of verifying itself using the received eUICC2.Info1. The first terminal 1700 may select certificate information to be used by the second terminal 1750 using the received eUICC2.Info1.

In this case, a detailed process for the process of selecting the certificate information to be used by the second terminal 1750 using the eUICC2.Info1 received by the first terminal 1700 is as follows:

The first terminal 1700 may hold the'trusted CI list stored in the terminal' described in FIG. 16. In addition, the first terminal 1700 may maintain the'trusted CI list provided from the server' described in FIG. 16. The first terminal 1700 may derive a'trusted CI list' using the'trusted CI list stored in the terminal' and the'trusted CI list provided from the server'. 'List of Trusted CIs'

a) It can be the same as'the list of trusted CIs stored in the terminal',

b) It can be the same as'list of trusted CIs provided by the server',

c) It may be an intersection of the'trusted CI list stored in the terminal' and the'trusted CI list provided from the server', or

d) It may be the union of the'trusted CI list stored in the terminal' and the'trusted CI list provided from the server'.

Which of the methods mentioned in a) to d) above may be used may be determined by a policy of at least one of the RSP server, the communication service provider, the terminal manufacturer, and the eUICC manufacturer. In addition, if'Profile Movement Settings' is set to'Authentication must be performed using information transmitted from a communication service provider and/or RSP server', as in the methods b) to d), the'trusted CI provided from the server' List' may have to be used.

The first terminal 1700 determines whether an intersection exists between the derived'trusted CI list' and the'certificate information(s) that can be used to verify the eUICC of the second terminal' included in eUICC2.Info1. You can check whether or not. The first terminal 1700 is among the information present in the intersection of the'trusted CI list' and the'certificate information(s) that can be used to verify the eUICC of the second terminal' included in eUICC2.Info1. Some or all of them may be selected, and the selected information may be set as certificate information to be used by the second terminal 1750.

In step 17015, the first terminal 1700 may generate “first terminal authentication information (Device1.Auth)”. “First terminal authentication information (Device1.Auth)” may include part or all of eUICC2.Info1. For example, the "first terminal authentication information (Device1.Auth)" may include the eUICC2.Challenge received by the first terminal 1700. The first terminal authentication information (Device1.Auth) may include an arbitrary string (eUICC1.Challenge) generated by the eUICC of the first terminal.

The “first terminal authentication information (Device1.Auth)” may include certificate information to be used by the second terminal 1750. The “first terminal authentication information (Device1.Auth)” may include a certificate eUICC1.Cert capable of verifying the first terminal 1700 itself and related certificate chain information.

Part or all of the aforementioned “first terminal authentication information (Device1.Auth)” may be digitally signed using the certificate eUICC1.Cert of the first terminal, and the digitally signed data is “first terminal authentication information (Device1.Auth)”. .Auth)”.

In step 17020, the first terminal 1700 may transmit “first terminal authentication information (Device1.Auth)” to the second terminal 1750.

In step 17025, the second terminal 1750 may verify the received “first terminal authentication information (Device1.Auth)”. The second terminal 1750 checks the validity of the eUICC1.Cert included in the “first terminal authentication information (Device1.Auth)”, and includes it in the “first terminal authentication information (Device1.Auth)” using the eUICC1.Cert. You can further check the validity of the signed signature. The second terminal 1750 may check whether the value of eUICC2.Challege included in the “first terminal authentication information (Device1.Auth)” is the same as the value of eUICC2.Challenge transmitted by itself in step 17010. For example, if the eUICC1.Cert is valid, the signature included in the “first terminal authentication information (Device1.Auth)” is valid, and the eUICC2.Challenge value is the same, the verification may be successful.

Based on the verification result (eg, when verification is successful), the second terminal 1750 may generate “second terminal authentication information (Device2.Auth)”. “Second terminal authentication information (Device2.Auth)” may include some or all of Device1.Auth. For example, the second terminal authentication information (Device2.Auth)” may include the eUICC1.Challenge received by the second terminal 1750. “Second terminal authentication information (Device2.Auth)” may include eUICC2.Info2, which is information for eligibility check of the eUICC installed in the second terminal. eUICC2.Info2 may be information used to determine whether a profile to be received from the first terminal 1700 in the future is normally installed and operated in the eUICC of the second terminal 1750. For example, eUICC2.Info2 may include hardware and/or software information of eUICC mounted on the second terminal 1750.

The “second terminal authentication information (Device2.Auth)” may include a certificate eUICC2.Cert capable of verifying the second terminal 1750 itself and related certificate chain information.

Part or all of the aforementioned “second terminal authentication information (Device2.Auth)” may be digitally signed using the certificate eUICC2.Cert of the second terminal, and this digitally signed data is “second terminal authentication information (Device2.Auth)”. .Auth)”.

In step 17030, the second terminal 1750 may transmit “second terminal authentication information (Device2.Auth)” to the first terminal 1700.

In step 17035, the first terminal 1700 may verify the received “second terminal authentication information (Device2.Auth)”. The first terminal 1700 checks the validity of the eUICC2.Cert included in the “second terminal authentication information (Device2.Auth)”, and includes it in the “second terminal authentication information (Device2.Auth)” using the eUICC2.Cert. You can check the validity of the signed signature. The first terminal 1700 may check whether the value of eUICC1.Challege included in the “second terminal authentication information (Device2.Auth)” is the same as the value of eUICC1.Challenge transmitted by itself in step 17020. For example, if the eUICC2.Cert is valid, the signature included in the “second terminal authentication information (Device2.Auth)” is valid, and the value of eUICC1.Challenge is the same, verification may be successful.

Based on the verification result (for example, when verification is successful), the first terminal 1700 provides information for the eligibility check of eUICC included in the “second terminal authentication information (Device2.Auth)” eUICC2 By checking .Info2, it can be determined whether the profile to be transmitted by the first terminal 1700 itself is normally installed and operated in the eUICC of the second terminal 1750.

Based on the determination result in step 17035, in step 17040, the first terminal 1700 may transmit the profile package to the second terminal 1750. The second terminal 1750 may install the received profile package.

18 is a diagram illustrating an operation of a first terminal according to some embodiments of the present disclosure.

Referring to FIG. 18, in step 1810, a first terminal according to an embodiment of the present disclosure may determine a profile to be transmitted to a second terminal from among profiles installed in the first terminal.

In step 1820, the first terminal may receive the second eUICC information of the second terminal from the second terminal based on the communication connection with the second terminal.

In step 1830, the first terminal may generate authentication information of the first terminal based on the second eUICC information.

In step 1840, authentication information of the first terminal may be transmitted to the second terminal.

In step 1850, the first terminal may receive authentication information of the second terminal from the second terminal as a response to the authentication information of the first terminal.

In step 1860, the first terminal may verify authentication information of the second terminal.

In step 1870, the first terminal may transmit a profile package for the profile to the second terminal based on the verification result.

19 is a diagram illustrating an operation of a second terminal according to some embodiments of the present disclosure.

Referring to FIG. 19, in step 1910, the second terminal according to an embodiment of the present disclosure may transmit eUICC information of the second terminal to the first terminal based on a communication connection with the first terminal.

In step 1920, the second terminal may receive authentication information of the first terminal as a response to the eUICC information from the first terminal.

In step 1930, the second terminal may verify the authentication information of the first terminal.

In step 1940, the second terminal may generate authentication information of the second terminal based on the verification result.

In step 1950, the second terminal may transmit authentication information of the second terminal to the first terminal.

In step 1960, the second terminal may receive a profile package from the first terminal as a response to the authentication information of the second terminal.

20 is a diagram illustrating a configuration of a terminal according to some embodiments of the present disclosure.

Referring to FIG. 20, the terminal may include a transceiver 2010, a processor 2020, and an eUICC 2030. Each of the terminals described above in the present disclosure may correspond to the terminals described in FIG. 20. For example, the first terminal and the second terminal described in FIGS. 15 to 19 may each include the configuration of the terminal described in FIG. 20.

However, the configuration of the terminal is not limited to FIG. 20, and may include more or fewer components than the components illustrated in FIG. 20. According to some embodiments, the transmission/reception unit 2010, the processor 2020, and the eUICC 2030 may be implemented in the form of a single chip. In addition, the terminal may further include a memory, and the processor 2020 may be configured as at least one processor.

According to various embodiments, the transmission/reception unit 2010 may transmit and receive signals, information, and data according to various embodiments of the present disclosure with a transmission/reception unit of another terminal or an external server. The transceiving unit 2010 may include an RF transmitter that up converts and amplifies a frequency of a transmitted signal, and an RF receiver that amplifies a received signal with low noise and down converts the frequency. . However, this is only an embodiment of the transmission/reception unit 2010, and components of the transmission/reception unit 2010 are not limited to the RF transmitter and the RF receiver. In addition, the transmission/reception unit 2010 may receive a signal through a wireless channel, output it to the processor 2020, and transmit a signal output from the processor 2020 through a wireless channel.

Meanwhile, the processor 2020 is a component for overall control of the terminal. The processor 2020 may control the overall operation of the terminal according to various embodiments of the present disclosure as described above.

Meanwhile, the terminal may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the terminal. In addition, the memory is a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium. In addition, the processor 2020 may perform various operations using various programs, contents, data, and the like stored in the memory.

21 is a diagram illustrating a configuration of a server according to some embodiments of the present disclosure.

Referring to FIG. 21, the server may include a transceiver 2110 and a processor 2120. Each of the servers described above in the present disclosure may correspond to the server described in FIG. 21. For example, the servers described in FIGS. 15 to 19 (eg, an operator server, an RSP server, SM-DP+, SM-DS, etc.) may each include a configuration of a server described in FIG. 21.

However, the configuration of the server is not limited to FIG. 21, and may include more or fewer components than the components illustrated in FIG. 21. According to some embodiments, the transmission/reception unit 2110 and the processor 2120 may be implemented in the form of a single chip. In addition, the server may additionally include a memory, and the processor 2120 may be configured as at least one processor.

According to some embodiments, the transmission/reception unit 2110 may transmit and receive signals, information, and data according to various embodiments of the present disclosure to and from the terminal. The transceiver 2110 may include an RF transmitter that up-converts and amplifies a frequency of a transmitted signal, and an RF receiver that amplifies a received signal with low noise and down-converts a frequency. However, this is only an embodiment of the transmission/reception unit 2110, and components of the transmission/reception unit 2110 are not limited to the RF transmitter and the RF receiver. In addition, the transmission/reception unit 2110 may receive a signal through a wireless channel, output it to the processor 2120, and transmit a signal output from the processor 2120 through a wireless channel.

Meanwhile, at least one processor 2120 is a component for overall control of the server. The processor 2120 may control the overall operation of the server according to various embodiments of the present disclosure as described above. The at least one processor 2120 may be referred to as a control unit.

Meanwhile, the server may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the server. In addition, the memory is a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium. Also, the processor 2120 may perform various operations using various programs, contents, data, etc. stored in the memory.

22 is a diagram conceptually illustrating a procedure for transmitting a profile from one terminal to another terminal according to some embodiments of the present disclosure.

According to various embodiments, the terminal may include at least one LPA and at least one eSIM. For example, referring to FIG. 22, a first terminal 2210 includes a first LPA 2230 and a first eSIM 2220, and a second terminal 2260 includes a second LPA 2280 and a second It may include an eSIM 2270.

In step 22000, the first LPA 2230 of the first terminal 2210 and the second LPA 2270 of the second terminal 2260 may perform a preparation procedure necessary for profile transmission (a profile transmission preparation procedure). . For a more detailed description of the above procedure, refer to the detailed description of FIG. 23 to be described later.

In step 22005, a mutual authentication process may be performed between the first terminal 2210 and the second terminal 2260. For a more detailed description of the above procedure, refer to the detailed description of FIG. 24 to be described later.

In step 22010, a procedure in which a profile is transmitted from the first terminal 2210 to the second terminal 2260 and the transmitted profile is installed in the second terminal may be performed. For a more detailed description of the above procedure, refer to the detailed description of FIG. 25 to be described later.

23 is a diagram illustrating a detailed procedure of a profile transmission preparation procedure among the procedures presented in FIG. 22 according to some embodiments of the present disclosure.

Referring to FIG. 23, a terminal may include at least one LPA and at least one eSIM. For example, the first terminal 2310 includes a first LPA 2330 and a first eSIM 2320, and the second terminal 2360 includes a second LPA 2380 and a second eSIM 2370 can do.

According to various embodiments, the first terminal 2310 may have a pre-installed profile, and may further have metadata associated with the pre-installed profile. According to various embodiments, the first terminal may have a'profile identifier' related to a previously installed profile.

According to various embodiments of the present disclosure, the first terminal 2310 may further have a'profile movement setting' linked to a pre-installed profile.

'Profile movement setting' may include a factor (or indication) indicating whether transmission between devices of the corresponding profile is allowed.

In addition, the'profile movement setting' may include a setting for a mutual authentication method to be passed when a profile is transmitted between devices (eg, a setting value indicating this setting). For example, when the terminal to which the profile is to be transmitted authenticates the terminal to receive the profile, it is added by using information transmitted from the communication service provider and/or the RSP server (eg, "trusted CI list provided from the server" shown in FIG. 16). Information on whether or not authentication is required may also be included in the'Profile Movement Settings'. If this additional authentication is set to be required, the communication service provider and/or the RSP server provides the trusted terminal and/or eSIM-related authentication information to the terminal transmitting the profile, and the terminal transmitting the profile receives the profile. After the terminal authenticates using information provided whether the communication service provider and/or the RSP server is a reliable terminal, the profile can be transmitted.

Various factors or setting values included in the above-mentioned'profile movement setting' may be electronically signed by at least one of an RSP server, a communication service provider, a terminal manufacturer, an eUICC, or an eUICC manufacturer. The corresponding electronic signature value may be stored in the first terminal 2310 as part of the'profile movement setting' or together with the'profile movement setting'.

In step 23000, the first LPA 2330 may obtain information on a profile to be transmitted. Alternatively, information on a profile to be transmitted may be delivered to the first LPA 2330. For example, the first LPA 2330 may obtain information of a profile to be transmitted by receiving a user input for selecting a profile through a UI provided by the first terminal 2310 by a user, or a push input from a remote server. Profile information to be transmitted through may be input to the first LPA 2330, or the first LPA 2330 may access a remote server to read information of a profile to be transmitted.

In step 23005, the first LPA 2330 may check whether a corresponding profile can be transmitted between devices by using'profile movement setting'.

In step 23010, the first LPA 2230 may generate a'profile transmission code'. The profile transmission code may include a'profile identifier' of a profile to be transmitted. In addition, the profile transmission code may include the address of the RSP server related to the profile to be transmitted. In addition, the profile transmission code may further include other information indicating the properties of the profile (eg, metadata of the profile or part of the metadata). In addition, the profile transmission code may include information necessary for connection between two terminals to be made in step 23020. For example, information required for wi-fi connection between two terminals (e.g., SSID and/or BSSID of the second terminal 2360, a Pre Shared Key to be used for connection authentication between the two terminals, the IP address of the second terminal 2360, The port number to be used for communication between the two terminals) may be included in the profile transmission code.

In step 23015, the profile transmission code generated in step 23010 may be transmitted from the first LPA 2330 to the second LPA 2380. The profile transmission code can be transmitted in a variety of ways.

For example, the first LPA 2330 may provide information to be transmitted to the second LPA 2380 to the first user of the first terminal through the UI of the first terminal. The first user may provide the provided information to the second user of the second terminal. The second user may input the provided information into the second LPA using the UI of the second terminal.

Alternatively, the first LPA 2330 creates information to be transmitted to the second LPA 2380 in the form of an image (for example, a QR code) and displays it on the screen of the first terminal, and the second user Information may be transmitted from the first LPA 2330 to the second LPA 2380 by scanning the image displayed on the screen of the second terminal.

Alternatively, the first LPA 2330 may establish a connection between the first LPA 2330 and the second LPA 2380 and transmit information to be transmitted using the established connection. At this time, the connection established between the first LPA 2330 and the second LPA 2380 is a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), 5G D2D). It may be a wireless connection such as a wireless connection or a wired connection such as a cable connection), or a remote connection in which a remote server (eg, a relay server) is located between the first LPA 2330 and the second LPA 2380.

In step 23020, a connection may be established (or established) between the first LPA 2330 and the second LPA 2380. If information necessary for connection is transmitted in step 23015, the first LPA 2330 and the second LPA 2380 may establish a connection using this information. The connection between the first LPA 2330 and the second LPA 2380 is a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), a wireless connection such as 5G D2D) or It may be a wired connection through a cable) or a remote connection in which a remote server (eg, a relay server) is located between the first LPA 2330 and the second LPA 2380.

24 is a diagram illustrating a detailed procedure of a mutual authentication procedure between a first terminal 2410 and a second terminal 2460 among the procedures presented in FIG. 22 according to some embodiments of the present disclosure.

Referring to FIG. 24, the terminal may include at least one LPA and at least one eSIM. For example, the first terminal 2410 includes a first LPA 2430 and a first eSIM 2420, and the second terminal 2460 includes a second LPA 2480 and a second eSIM 2470 can do.

In operation 24000, the second LPA 2480 may request euicc2.Info1 from the second eSIM 2470.

In step 24005, the second eSIM 2470 may generate euicc2.Info. For example, Euicc2.Info1 may include at least one of the following information.

- Certificate information that the first eSIM can use to verify the second eSIM

- Certificate information that the second eSIM can use to verify the first eSIM

- Version information supported by the second terminal

In addition, the second eSIM 2470 may provide euicc2.Info to the second LPA 2480.

In operation 24010, the second LPA 2480 may request euicc2.Challenge from the second eSIM 2470.

In step 24015, the second eSIM 2470 may generate euicc2.Challenge. Euicc2.Challenge may be an arbitrary random number generated by the second eSIM 2470. The second eSIM 2470 may provide euicc2.Challenge to the second LPA 2480.

In operation 24020, the second LPA 2480 may provide euicc2.Info1 to the first eSIM 2420 through the first LPA 2430. In addition, the second LPA 2480 may provide euicc2.Challenge to the first eSIM 2420 through the first LPA 2730. In this case, the first LPA 2730 may further provide a'profile identifier' of the profile to be transmitted to the first eSIM 2420.

In step 24025, the following process may be performed.

The first eSIM 2420 may select the certificate euicc1.Certificate to be used by itself using'certificate information that the second eSIM can use to verify the first eSIM' included in euicc2.Info1.

The first eSIM 2420 may select a certificate to be used by the second eSIM 2470 using'certificate information that the first eSIM can use to verify the second eSIM' included in euicc2.Info1. At this time, the selected certificate information or information indicating the selected certificate may be called euiccCiPKIdToBeUsed.

At this time, the process of generating or selecting euiccCiPKIdToBeUsed by the first eSIM 2420 using'certificate information that the first eSIM can use to verify the second eSIM' may be the same as one of the processes specified below.

a) After checking whether there is an intersection in the'certificate information that the first eSIM can use to verify the second eSIM' and the'trusted CI list stored in the terminal' shown in FIG. At least one of the elements in euiccCiPKIdToBeUsed

b) After checking whether there is an intersection in the'certificate information that the first eSIM can use to verify the second eSIM' and the'trusted CI list provided from the server' shown in FIG. At least one of the elements in euiccCiPKIdToBeUsed

c) 'Certificate information that the first eSIM can use to verify the second eSIM', the'trusted CI list stored in the terminal' shown in FIG. 16 and the'trusted CI list provided from the server' shown in FIG. After checking whether there is an intersection in', if there is an intersection, at least one of the elements of the intersection is set to euiccCiPKIdToBeUsed.

In other words, the first eSIM 2420 includes'certificate information that the first eSIM can use to verify the second eSIM' and'the trusted CI list stored in the terminal' and/or the After checking whether there is an intersection in the CI list'”, at least one of the elements of the intersection can be set as euiccCiPKIdToBeUsed when there is an intersection.

The setting of which of the above-described methods will be used may be included in'Profile Movement Settings'.

When the'trusted CI list provided from the server' needs to be used, the first eSIM 2420 can check which'trusted CI list provided from the server' should be used by the first eSIM 2420 using the received'profile identifier'. In addition, when it is necessary to use the'trusted CI list stored in the terminal', the first eSIM 2420 can check which'trusted CI list stored in the terminal' should be used by using the received'profile identifier'. have. That is, in the terminal, there may be one or more'trusted CI lists stored in the terminal' and'trusted CI lists provided from the server', among which the list(s) associated with the profile to be transmitted are selected and used. I can.

The first eSIM 2420 may check the'profile movement setting' of the profile associated with the received profile identifier. The first eSIM 2420 may check whether a corresponding profile can be transmitted through device-to-device transmission.

The first eSIM 2420 may check version information supported by the second terminal 2460 included in euicc2.Info1 and check whether a version supported by itself exists among them.

The first eSIM 2420 may generate a session ID (Transaction ID) used to refer to communication with the second eSIM 2470 in the future.

The first eSIM 2420 may generate euicc1.Challenge. Euicc1.Challenge may be an arbitrary random number generated by the first eSIM 2420.

The first eSIM 2420 may electronically sign all and/or some of the following values. In this case, the electronic signature may be performed using euicc1.Certificate.

- Transaction ID

- Euicc1.Challenge

- Euicc2.Challenge

The first eSIM 2420 may transmit all and/or part of the following data to the second LPA 2480 through the first LPA 2430.

- Transaction ID and/or euicc1.Challenge and/or euicc2.Challenge and their digital signature values

- euiccCiPKIdToBeUsed

- euicc1.Certificate

The provided data may be referred to as Device1.Auth1.

In operation 24030, the second LPA 2480 may transmit all and/or part of the following data to the second eSIM 2470.

- Device1.Auth1

- Profile identifier of the profile to be transmitted by the first terminal 2410 to the second terminal 2460

In step 24035, the following process may be performed.

The second eSIM 2470 may verify the validity of euicc1.Certificate.

The second eSIM 2470 may verify the electronic signature value included in Device1.Auth1.

The second eSIM 2470 may check whether euicc2.Challenege included in Device1.Auth1 is the same value as euicc2.Challenge transmitted by itself in step 24020.

The second eSIM 2470 may select the certificate euicc2.Certificate to be used by itself using euiccCiPKIdToBeUsed.

The second eSIM 2470 may electronically sign all and/or some of the following values. In this case, the electronic signature may be performed using euicc2.Certificate.

- Transaction ID

- Euicc1.Challenge

- Euicc2.Info2. Here, euicc2.Info2 may be information that can be used to perform an eligibility check whether the'profile transmitted by the first terminal to the second terminal' is installed in the second terminal 2460 and can be operated. For example, eUICC2.Info2 may include hardware and/or software information of the second eSIM 2470.

- Profile identifier of the profile to be transmitted by the first terminal 2410 to the second terminal 2460

The second eSIM 2470 may transmit all and/or part of the following data to the first eSIM 2420 through the second LPA 2480 and the first LPA 2430.

- Transaction ID and/or euicc1.Challenge and/or euicc2.Info2 and/or'profile identifier of the profile that the first terminal intends to transmit to the second terminal' and their digital signature values

- Euicc2.Certificate

The above data may be referred to as Device2.Auth1.

25 is a detailed procedure in which a profile is transmitted from a first terminal 2510 to a second terminal 2560 and the transmitted profile is installed in a second terminal among the procedures shown in FIG. 22 according to some embodiments of the present disclosure It is a figure showing.

Referring to FIG. 25, a terminal may include at least one LPA and at least one eSIM. For example, the first terminal 2510 includes a first LPA 2530 and a first eSIM 2520, and the second terminal 2560 includes a second LPA 2580 and a second eSIM 2570 can do.

In step 25000, the following process may be performed.

The first eSIM 2520 may verify the validity of euicc2.Certificate.

The first eSIM 2520 may verify an electronic signature value included in Device2.Auth1.

The first eSIM 2520 may check whether euicc1.Challenege included in Device2.Auth1 is the same value as euicc1.Challenge transmitted by itself in step 25025.

The first eSIM 2520 may identify a profile to be transmitted by checking a profile identifier included in Device2.Auth1. Alternatively, the first eSIM 2520 may check whether the profile identifier included in Device2.Auth1 matches the profile identifier received in step 24020 of FIG. 24.

The first eSIM 2520 may check the'profile movement setting' of the profile associated with the received profile identifier. The first eSIM 2520 may check whether a corresponding profile can be transmitted through device-to-device transmission.

The first eSIM 2520 may perform an eligibility check as to whether the corresponding profile is normally installed and operated in the second terminal 2560 (eg, the second eSIM 2570). At this time, the profile identifier and euicc2.Info2 may be used to check conformance.

The first eSIM 2520 may electronically sign the following values. In this case, the electronic signature may be performed using euicc1.Certificate.

- Transaction ID

The first eSIM 2520 may transmit a Tranction ID and/or an electronic signature value to the second eSIM 2570 through the first LPA 2530 and the second LPA 2580. At this time, the transmitted value may be called Device1.Auth2.

In step 25005, the following process may be performed.

The second eSIM 2570 may verify an electronic signature value included in Device1.Auth2.

The second eSIM 2570 has its own encryption key pair (eg, public key otPK.EUICC2.KA and a corresponding private key otSK.EUICC2. KA) can be created.

The second eSIM 2570 may electronically sign all and/or some of the following values. In this case, the electronic signature may be performed using euicc2.Certificate.

- Transaction ID

- otPK.EUICC2.KA

The second eSIM 2570 may transmit the Transaction ID and/or otPK.EUICC2.KA and their electronic signature values to the first eSIM 2520 via the second LPA 2580 and the first LPA 2530. At this time, the transmitted value may be called Device2.Auth2.

In step 25010, the following process may be performed.

The first eSIM 2520 may verify an electronic signature value included in Device2.Auth2.

The first eSIM 2520 has its own encryption key pair (eg, a public key otPK.EUICC1.KA and a corresponding private key otSK.EUICC1. KA) can be created.

The first eSIM 2520 may generate a session key for encrypted communication with the second terminal using the otSK.EUICC1.KA generated by itself and the received otPK.EUICC2.KA.

The first eSIM 2520 may prepare a profile (a profile image and/or a profile package) to be transmitted to the second terminal 2560. In this case, the prepared profile image or profile package may be referred to as a bound profile package or a bound profile image. In addition, the bundled profile package and the bundled profile image may be collectively referred to as a bound profile.

In this preparation process, all and/or part of the'profile image and/or profile package to be transmitted' may be encrypted by the previously generated session key. In addition, all and/or part of the'profile image and/or profile package to be transmitted' may be electronically signed using euicc1.Certificate, and the electronically signed value may be included as part of the Bound Profile. In addition, otPK.EUICC1.KA may be included as a part of the Bound Profile.

The first eSIM 2520 may transmit the Bound Profile to the second LPA 2580 through the first LPA 2530. In this case, metadata associated with the corresponding profile may be transmitted together. In this case, the metadata may be included as part of the Bound Profile, or may be transmitted as data separate from the Bound Profile.

The first eSIM 2520 may delete the corresponding profile.

In step 25015, the following process may be performed.

The second terminal 2560 may check the transmitted metadata.

The second terminal 2560 may receive user consent in connection with the installation of the received Bound Profile.

The second terminal 2560 may install the received Bound Profile in the second eSIM 2570. This process may be performed by collaboration between the second LPA 2580 and the second eSIM 2570. In this process, if there is encrypted data in the Bound Profile, the second eSIM 2570 may generate a session key using otSK.EUICC2.KA and otPK.EUICC1.KA, and then decrypt the data using the session key. In addition, if the electronic signature value is included in the Bound Profile, the second eSIM 2570 may verify the validity of the electronic signature value using euicc1.Certificate.

According to some embodiments of the present disclosure, the terminal and server described with reference to FIGS. 22 to 25 may be the terminal of FIG. 20 and the server of FIG. 21, respectively. That is, at least some of the embodiments described with reference to FIGS. 22 to 25 may be implemented using the terminal of FIG. 20 and the server of FIG. 21.

In the above-described specific embodiments of the present disclosure, components included in the disclosure are expressed in the singular or plural according to the presented specific embodiments. However, the singular or plural expression is selected appropriately for the situation presented for convenience of description, and the present disclosure is not limited to the singular or plural constituent elements, and even constituent elements expressed in plural are composed of the singular or in the singular. Even the expressed constituent elements may be composed of pluralities.

Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, various modifications may be made without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure is limited to the described embodiments and should not be defined, and should be determined by the scope of the claims and equivalents as well as the scope of the claims to be described later.

Various embodiments of the present disclosure and terms used therein are not intended to limit the technology described in the present disclosure to a specific embodiment, and should be understood to include various modifications, equivalents, and/or substitutes of the corresponding embodiment. In connection with the description of the drawings, similar reference numerals may be used for similar elements. Singular expressions may include plural expressions unless the context clearly indicates otherwise. In the present disclosure, expressions such as "A or B", "at least one of A and/or B", "A, B or C" or "at least one of A, B and/or C" are all of the items listed together It can include possible combinations. Expressions such as "first", "second", "first" or "second" can modify the corresponding elements regardless of their order or importance, and are only used to distinguish one element from another. It does not limit the components. When any (eg, first) component is referred to as being “(functionally or communicatively) connected” or “connected” to another (eg, second) component, the component is It may be directly connected to the component, or may be connected through another component (eg, a third component).

The term "module" used in the present disclosure includes a unit composed of hardware, software, or firmware, and may be used interchangeably with terms such as, for example, logic, logic blocks, parts, or circuits. The module may be an integrally configured component or a minimum unit that performs one or more functions, or a part thereof. For example, the module may be configured as an application-specific integrated circuit (ASIC).

Various embodiments of the present disclosure are software (eg, programs) including instructions stored in a machine-readable storage media (eg, internal memory or external memory) that can be read by a machine (eg, a computer). Can be implemented as The device is a device capable of calling a stored command from a storage medium and operating according to the called command, and may include a terminal according to various embodiments. When the command is executed by a processor (eg, the processor 1420 of FIG. 14), the processor may perform a function corresponding to the command directly or by using other components under the control of the processor. Instructions may include code generated or executed by a compiler or interpreter.

A storage medium that can be read by a device may be provided in the form of a non-transitory storage medium. Here,'non-transient' means that the storage medium does not contain a signal and is tangible, but does not distinguish between semi-permanent or temporary storage of data in the storage medium.

A method according to various embodiments disclosed in the present disclosure may be provided in a computer program product. Computer program products can be traded between sellers and buyers as commodities. The computer program product may be distributed online in the form of a device-readable storage medium (eg, compact disc read only memory (CD-ROM)) or through an application store (eg, Play StoreTM). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a storage medium such as a server of a manufacturer, a server of an application store, or a memory of a relay server. Each element (e.g., a module or program) may be composed of a single or a plurality of entities, and some of the above-described sub-elements may be omitted, or other sub-elements may be further included in various embodiments. have. Alternatively or additionally, some constituent elements (eg, a module or a program) may be integrated into a single entity, and functions performed by each corresponding constituent element prior to the consolidation may be performed identically or similarly. Operations performed by modules, programs, or other components according to various embodiments may be sequentially, parallel, repetitively or heuristically executed, or at least some operations may be executed in a different order, omitted, or other operations may be added. I can.

Claims (22)

In a method for a first terminal to provide a bundle to a second terminal,
Obtaining information on a bundle to be transmitted to a second terminal;
Transmitting identification information of the bundle to the second terminal;
Receiving authentication information related to bundle movement of a second Smart Secure Platform (SSP) of the second terminal from a second terminal;
Determining whether a second Secondary Platform Bundle Loader (SPBL) of the second SSP is an SPBL capable of receiving the bundle, based on authentication information related to bundle movement of the second SSP; And
And transmitting the bundle to the second terminal based on the determination result. The method of claim 1,
The identification information of the bundle,
The method comprising at least one of a bundle family identifier (Family ID, hereinafter Fid) or a bundle family manager identifier (Family Custodian Object ID, hereinafter Oid) for the bundle. The method of claim 1,
The authentication information related to the bundle movement of the second SSP,
Includes received SPBL authentication information determined based on the identification information of the bundle,
The step of determining whether the second SPBL of the second SSP is an SPBL capable of receiving the bundle,
Based on the identification information of the bundle, further comprising the step of determining whether the received SPBL authentication information is included in at least one of information on a verifiable SPBL or information on a reliable SPBL of the first terminal,
The information on the verifiable SPBL is pre-stored in the first terminal,
The information on the reliable SPBL is received from a server. The method of claim 3,
Information on the reliable SPBL,
Includes bundle movement policy information corresponding to the identification information of the bundle,
The bundle movement policy information,
The received SPBL authentication information is 1) a condition included in the verifiable SPBL information, 2) a condition included in the reliable SPBL information, 3) the verifiable SPBL information and the reliable SPBL A condition included in all of the information, and 4) a condition included in any one of the information on the verifiable SPBL and the information on the reliable SPBL,
The step of determining whether the second SPBL of the second SSP is an SPBL capable of receiving the bundle,
The method further comprising determining whether the second SPBL is an SPBL capable of receiving the bundle based on the bundle movement policy information. The method of claim 1,
The authentication information related to the bundle movement of the second SSP of the second terminal,
Includes transmission SPBL authentication information determined based on the identification information of the bundle,
The above method,
The method further comprising determining whether the first SPBL of the first SSP of the first terminal is an SPBL capable of transmitting the bundle to the second terminal based on the transmission SPBL authentication information. The method of claim 5,
The above method,
Generating authentication information of the first terminal based on the transmission SPBL authentication information;
Transmitting authentication information of the first terminal to the second terminal;
Receiving authentication information of the second terminal from the second terminal;
Verifying the validity of the authentication information of the second terminal; And
And transmitting the bundle to the second terminal based on the verification result. The method of claim 3,
The above method,
Transmitting a request for information on the reliable SPBL to the server; And
Further comprising the step of receiving information on the reliable SPBL from the server,
The request for information on the reliable SPBL includes identification information of the bundle. In the method for the second terminal to receive the bundle from the first terminal,
Receiving identification information of a bundle from a first terminal;
Generating authentication information related to bundle movement of a second Smart Secure Platform (SSP) of the second terminal based on the received bundle identification information;
Transmitting authentication information related to bundle movement of the second SSP to the first terminal; And
And receiving the bundle from the first terminal based on a verification result of the first terminal with respect to the bundle movement related authentication information of the second SSP. The method of claim 8,
Generating the authentication information related to the bundle movement of the second SSP,
Extracting information corresponding to identification information of the bundle from pre-stored information on verifiable Secondary Platform Bundle Loader (SPBL) of the second terminal; And
And generating received SPBL authentication information and transmission SPBL authentication information for the bundle based on the extracted information. The method of claim 9,
Generating the authentication information related to the bundle movement of the second SSP,
Based on identifying that the bundle family identifier (Family ID) and the bundle family manager identifier (Family Custodian Object ID) for the bundle are not included in the received bundle identification information, the pre-stored second terminal can be verified. Generating information comprising SPBL. In the first terminal providing the bundle to the second terminal,
A transmission/reception unit; And
Including at least one processor,
The at least one processor,
Obtaining information about the bundle to be transmitted to the second terminal,
Controlling the transmission/reception unit to transmit identification information of the bundle to the second terminal,
Controlling the transceiver to receive authentication information related to bundle movement of a second smart secure platform (SSP) of the second terminal from a second terminal,
Based on the authentication information related to bundle movement of the second SSP, it is determined whether the second Secondary Platform Bundle Loader (SPBL) of the second SSP is an SPBL capable of receiving the bundle,
The first terminal, which controls the transmission/reception unit to transmit the bundle to the second terminal based on the determination result. The method of claim 11,
The identification information of the bundle,
The first terminal comprising at least one of a bundle family identifier (Family ID, hereinafter Fid) or a bundle family manager identifier (Family Custodian Object ID, hereinafter Oid) for the bundle. The method of claim 11,
The authentication information related to the bundle movement of the second SSP,
Includes received SPBL authentication information determined based on the identification information of the bundle,
The at least one processor,
Based on the identification information of the bundle, it is determined whether the received SPBL authentication information is included in at least one of information on a verifiable SPBL or information on a reliable SPBL of the first terminal,
The information on the verifiable SPBL is pre-stored in the first terminal,
The information on the reliable SPBL is received from a server, the first terminal. The method of claim 13,
Information on the reliable SPBL,
Includes bundle movement policy information corresponding to the identification information of the bundle,
The bundle movement policy information,
The received SPBL authentication information is 1) a condition included in the verifiable SPBL information, 2) a condition included in the reliable SPBL information, 3) the verifiable SPBL information and the reliable SPBL A condition included in all of the information, and 4) a condition included in any one of the information on the verifiable SPBL and the information on the reliable SPBL,
The at least one processor,
The first terminal to determine whether the second SPBL is an SPBL capable of receiving the bundle based on the bundle movement policy information. The method of claim 11,
The authentication information related to the bundle movement of the second SSP of the second terminal,
Includes transmission SPBL authentication information determined based on the identification information of the bundle,
The at least one processor,
The first terminal to determine whether the first SPBL of the first SSP of the first terminal is an SPBL capable of transmitting the bundle to the second terminal based on the transmission SPBL authentication information. The method of claim 15,
The at least one processor,
Generate authentication information of the first terminal based on the transmission SPBL authentication information,
Controlling the transmission/reception unit to transmit the authentication information of the first terminal to the second terminal,
Controlling the transceiver to receive authentication information of the second terminal from the second terminal,
Verifying the validity of the authentication information of the second terminal,
The first terminal, which controls the transmission/reception unit to transmit the bundle to the second terminal based on the verification result. The method of claim 13,
The at least one processor,
Controlling the transmission/reception unit to transmit a request for information on the reliable SPBL to the server,
Controlling the transceiver to receive information on the reliable SPBL from the server,
The request for information on the reliable SPBL includes identification information of the bundle. In the second terminal receiving the bundle from the first terminal,
A transmission/reception unit; And
Including at least one processor,
The at least one processor,
Controlling the transceiver to receive the identification information of the bundle from the first terminal,
Generates authentication information related to bundle movement of a second Smart Secure Platform (SSP) of the second terminal based on the received bundle identification information,
Controlling the transceiver to transmit authentication information related to the bundle movement of the second SSP to the first terminal,
The second terminal, which controls the transceiver to receive the bundle from the first terminal based on a verification result of the first terminal with respect to the bundle movement related authentication information of the second SSP. The method of claim 18,
The at least one processor,
Extracting information corresponding to the identification information of the bundle from pre-stored information on the verifiable Secondary Platform Bundle Loader (SPBL) of the second terminal,
Generate received SPBL authentication information and transmission SPBL authentication information for the bundle based on the extracted information,
The received SPBL authentication information and the transmission SPBL authentication information,
The second terminal to be included in the authentication information related to the bundle movement of the second SSP. The method of claim 19,
The at least one processor,
Based on identifying that the bundle family identifier (Family ID) and the bundle family manager identifier (Family Custodian Object ID) for the bundle are not included in the received bundle identification information, the pre-stored second terminal can be verified. The second terminal including information including the SPBL in the authentication information related to the movement of the bundle of the second SSP. In a method for providing a profile by a first terminal to a second terminal in a wireless communication system,
Determining a profile to be transmitted to a second terminal from among profiles installed in the first terminal;
Receiving eUICC information of the second terminal from the second terminal based on the communication connection with the second terminal;
Generating authentication information of the first terminal based on the eUICC information;
Transmitting authentication information of the first terminal to the second terminal;
Receiving authentication information of the second terminal from the second terminal as a response to the authentication information of the first terminal;
Verifying authentication information of the second terminal; And
And transmitting a profile package for the profile to the second terminal based on the verification result. In a method for receiving a profile from a first terminal by a second terminal in a wireless communication system,
Transmitting eUICC information of the second terminal to the first terminal based on the communication connection with the first terminal;
Receiving authentication information of the first terminal as a response to the eUICC information from the first terminal;
Verifying authentication information of the first terminal;
Generating authentication information of the second terminal based on the verification result;
Transmitting authentication information of the second terminal to the first terminal; And
And receiving a profile package from the first terminal as a response to the authentication information of the second terminal.

Images