KR20210034522A - Apparatus and methods for setting bundle status after device to device bundle transfer - Google Patents

Abstract

The present disclosure relates to a communication technique for combining an IoT technology with a 5G communication system for supporting a higher data transmission rate than a 4G system, and a system thereof. The present disclosure can be applied to intelligent services (for example, smart homes, smart buildings, smart cities, smart cars or connected cars, health care, digital education, retail businesses, security and safety-related services, and the like) on the basis of 5G communication technologies and IoT-related technologies. The present disclosure describes a method and device for setting the state of a bundle after the bundle has been transmitted between smart security media. The method includes the steps of: transmitting a bundle to a second terminal; receiving, from the second terminal, a first certificate generated including bundle status information of the second terminal; verifying the received first certificate; verifying the first certificate, and then generating a second certificate including bundle status information of the first terminal; and transmitting the second certificate to the second terminal.

Description

{APPARATUS AND METHODS FOR SETTING BUNDLE STATUS AFTER DEVICE TO DEVICE BUNDLE TRANSFER}

The present disclosure relates to a smart security medium, and more particularly, to a method and an apparatus for setting a state of a bundle after moving a bundle between smart security media.

The present disclosure relates to a smart security medium, and more particularly, to a method and apparatus for registering a bundle movement result in a server after a bundle movement between smart security media is performed.

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.

The disclosed embodiment provides an apparatus and method for setting a state of a bundle after bundle transmission is performed when a bundle is moved between security modules included in two electronic devices.

In addition, the disclosed embodiment provides an apparatus and method for registering a bundle transmission result in a server after bundle transmission is performed when a bundle is moved between security modules included in two electronic devices.

In order to solve the above problems, the present invention provides a method of operating a first terminal, the method comprising: transmitting a bundle to a second terminal; Receiving a first certificate generated by the second terminal when the bundle cannot be used repeatedly in a plurality of terminals; Verifying the received first certificate; Generating a second certificate including bundle state setting information of a first terminal after verifying the first certificate; And transmitting the second certificate to the second terminal.

In some examples, the bundle state information of the first terminal includes that the bundle state of the first terminal is set to at least one of DELETE, IN TRANSITION, and SUSPENSION.

In some examples, when the bundle status of the first terminal is set to IN TRANSITION, receiving a third certificate generated from the second terminal including information on the change of the bundle status of the second terminal; Verifying the received third certificate; And deleting (DELETE) the bundle of the first terminal after verifying the third certificate.

In some examples, when the bundle of the first terminal is resumed, receiving a fourth certificate generated from the second terminal including bundle state setting information of the second terminal; Verifying the received fourth certificate; And after verifying the fourth certificate, changing the bundle state of the first terminal to at least one of enabled, active, and disabled, and the bundle of the second terminal The state information includes that the bundle state of the second terminal is set to at least one of DELETE, IN TRANSITION, and SUSPENSION.

In some examples, when the bundle state setting state of the second terminal is set to IN TRANSITION, receiving a fifth certificate generated from the first terminal including information on the bundle state change of the first terminal; Verifying the received fifth certificate; And deleting (DELETE) the bundle of the second terminal after verifying the fifth certificate.

In another example of the present invention, in a method of operating a second terminal, the method includes: receiving a bundle from the first terminal; Installing the bundle; Determining whether the bundle can be used repeatedly in a plurality of terminals; Generating a first certificate when the bundle cannot be used repeatedly in a plurality of terminals; And transmitting the first certificate to the first terminal.

In some examples, receiving a second certificate generated from the first terminal including bundle state setting information of the first terminal; Verifying the received second certificate; And after verifying the second certificate, changing the bundle state of the second terminal to at least one of an enabled state, an active state, and a disabled state.

In some examples, the bundle state information of the first terminal includes that the bundle state of the first terminal is set to at least one of DELETE, IN TRANSITION, and SUSPENSION.

In some examples, when the bundle state of the first terminal is set to IN TRANSITION, generating a third certificate including information on the change of the bundle state of the second terminal; And transmitting the third certificate to the first terminal.

In some examples, when resuming the use of the bundle of the first terminal, generating a fourth certificate including the bundle state setting information of the second terminal from the second terminal; And transmitting the fourth certificate to the first terminal.

In some examples, when the bundle state setting state of the second terminal is set to IN TRANSITION, receiving a fifth certificate generated from the first terminal including information on the bundle state change of the first terminal; Verifying the received fifth certificate; After verifying the fifth certificate, the step of deleting (DELETE) the bundle of the second terminal.

In still other examples, in the first terminal, a transceiver capable of transmitting and receiving at least one signal; And a control unit coupled to the transmitting/receiving unit, wherein the control unit transmits a bundle to a second terminal, and when the bundle cannot be used repeatedly in a plurality of terminals, the first certificate generated by the second terminal is After receiving, verifying the received first certificate, verifying the first certificate, generating a second certificate including bundle state setting information of the first terminal, and the second certificate to the second terminal It characterized in that it is configured to transmit.

In still other examples, in the second terminal, a transceiver capable of transmitting and receiving at least one signal; And a control unit coupled to the transmitting/receiving unit, wherein the control unit receives a bundle from a first terminal, installs the bundle, determines whether the bundle can be redundantly used in a plurality of terminals, and includes a plurality of bundles. If duplicate use is not possible in the terminal of, the first certificate is generated, and the first certificate is transmitted to the first terminal.

According to various embodiments of the present disclosure, a bundle installed in one device may be transmitted and installed to another device in a safe and efficient manner, and a state of the bundle may be set after completing the transmission and installation.

In addition, according to various embodiments of the present disclosure, a bundle installed in one device may be transmitted and installed to another device in a safe and efficient manner, and a transmission result of the bundle may be registered in the server after completing the transmission and installation. .

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 “certificate (Attestaion)” according to some embodiments of the present disclosure.
6 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. 7 is a diagram illustrating a detailed procedure for a procedure for preparing for bundle transmission among the procedures presented in FIG. 6.
8 is a diagram illustrating a detailed procedure for a procedure in which a bundle is transmitted among the procedures presented in FIG. 6.
9 is a diagram illustrating a detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
FIG. 10 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
FIG. 11 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
12 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
13 is a diagram illustrating an example of a procedure for making a bundle that has been discontinued to be used again.
14 is a diagram illustrating another example of a procedure for making a bundle that has been discontinued to be used again.
15 is a diagram illustrating another example of a procedure for making a bundle that has been discontinued to be used again.
16 is a diagram illustrating a configuration of a terminal according to some embodiments of the present disclosure.
FIG. 17 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
18 is a diagram illustrating a configuration of a "certificate (Attestaion)" according to some embodiments of the present disclosure.
19 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. 20 is a diagram illustrating a detailed procedure for a procedure for preparing for bundle transmission among the procedures presented in FIG. 19.
FIG. 21 is a diagram showing a detailed procedure for a procedure in which a bundle is transmitted among the procedures presented in FIG. 19.
FIG. 22 is a diagram illustrating a detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.
23 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 22.
FIG. 24 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.
25 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 24.
FIG. 26 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.
FIG. 27 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 26.
28 is a diagram illustrating a configuration of a terminal according to some embodiments of the present disclosure.
29 is a diagram illustrating a configuration of a server according to some embodiments of the present disclosure.
FIG. 30 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19 and a procedure in which a transmission result of a bundle is registered in the server.

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 addition, although the present disclosure describes each of the embodiments by using the SSP as an example of a security medium, the scope of the present invention 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 and used in a mobile communication terminal, and may also be referred to as 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. The UICC card can also download and install a plurality of SIM modules, and select and use at least one SIM module among them. 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 in (SoC) may be referred to as iUICC (Integrated UICC). Typically, eUICC and iUICC are fixed to a terminal and used, and may mean a UICC card that can remotely download and select a SIM module. In the present disclosure, a UICC card that can remotely download and select a SIM module is collectively referred to as eUICC or iUICC. That is, among UICC cards that can be selected by downloading a SIM module remotely, a UICC card that is fixed or not fixed to the terminal is collectively used as eUICC or iUICC. In addition, the SIM module information to be downloaded is collectively referred to as an eUICC profile or iUICC profile, or more simply, a term of a profile.

In the present disclosure, the term UICC may be mixed with SIM, and the term eUICC may be mixed with eSIM. In addition, in the present disclosure, the USIM Profile may have the same meaning as a profile or may mean that information included in a USIM application in the profile is packaged in a software form.

"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. eSE remotely downloads and installs an applet-type service control module, and can be used for various security services such as electronic wallets, ticketing, e-passports, and digital keys. In the present disclosure, an SE in the form of a single chip attached to an electronic device that can remotely download and install a service control module is collectively referred to as eSE.

"SSP (Smart Secure Platform)" is capable of supporting UICC and eSE functions in a single chip. Removable (rSSP, Removable SSP), fixed (eSSP, Embedded SSP), and integrated (iSSP, Integrated SSP) built in SoC SSP). 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.

The SSP can be used for the above-described UICC or eSE according to the downloaded and installed bundles, and a plurality of bundles can be installed in a single SSP and operated at the same time to mix the uses 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. The corresponding UICC bundle may operate by downloading at least one profile remotely into the bundle, such as the eUICC or iUICC, and selecting it. 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 eSE. 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.

The SSP can download and install a bundle from an external bundle management server (Secondary Platform Bundle Manager, SPB Manager) using OTA (Over The Air) technology, or can receive and install a bundle from another terminal. In the present disclosure, the method of installing the downloaded or transmitted bundle includes a removable 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. Also, as in the embodiment of the present disclosure, when the terminal and the SSP chip are not separated, it may be a terminal ID. It may also refer to a specific bundle identifier (SPB ID) in the SSP. In more detail, it may refer to the bundle identifier of a management bundle or loader (SPBL, Secondary Platform Bundle Loader) that installs, activates, deactivates, and deletes another bundle in the SSP. In addition, it may refer to the Primary Platform Identifier (ID) 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 PP resources on SSP's primary platform (PP, Primary Platform). For example, UICC bundle is an application, file system, authentication key value, etc. stored in the existing UICC. It may mean that the operating system (HLOS) in which they operate is packaged in the form of software. In this disclosure, an SPB may be referred to as a bundle.

In the present disclosure, the "state" of the terminal 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 in the storage space inside or outside the SSP, and it can mean processing security information and providing security services to the terminal using the security control device (Secure CPU) inside the SSP. have.

[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, it 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 the properties, characteristics, or settings of the bundle. Bundle metadata may be expressed as "metadata".

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. The bundle management server that provides the above functions is 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) ) Can be expressed as at least one of.

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 that provide the above 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 Plus (SM-SR+). ), 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 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), It may be expressed as at least one of DS (Discovery Service), Root SM-DS, and Alternative SM-DS.

In the present disclosure, the bundle management server may collectively refer to a combination of 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, it may be collectively referred to as a combination of the functions of the activation intermediary server. 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 both a bundle management server and an opening brokerage server.

"Service Provider" may indicate a business entity 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, it may represent a mobile operator that provides a communication network access service through a bundle equipped with a communication application, and the business support system (BSS) of the communication service provider, and the 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, a 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 an 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 unique At least one or more identifiers (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.

"Subscriber" may be used as a term referring to a service provider having ownership of the terminal or an end user having ownership of the terminal. In general, the former may be referred to as an M2M device, and the latter 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 user may be different 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 referring 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 the 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 in this case, the terminal may be a terminal including an SSP capable of downloading and installing a bundle. Not only can the SSP be embedded in the terminal, but when the terminal and the SSP are separated, the SSP can be inserted into the terminal, or inserted into the terminal to be connected to the terminal.

"Local Bundle Assistant (LBA)" may refer to software or applications installed in a terminal or electronic device to control the SSP. This software or application may be referred to as the Local Bundle Manager (LBM).

A "loader (SPBL, Secondary Platform Bundle Loader)" may refer to a management bundle that installs other bundles in the SSP and manages activation, deactivation, and deletion. 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.

“Event” may be a term collectively referring to bundle download, remote bundle management, or other bundle or SSP management/processing command. 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 may be referred to as containing data. Bundle Download can be mixed with Bundle Installation. In addition, Event Type can be used as a term indicating whether a specific event is a bundle download, remote bundle management (e.g., delete, activate, deactivate, replace, update, etc.), or other bundle or SSP management/handling command. In addition, it may 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. .

"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, and Local Command Package. 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 include more than one local management command, and in this case, 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, and Remote Command Package. 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 a 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.

“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 one or more public keys (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 (Digital Signature) may be included. 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 Calculation result (for example, hash) value, or the result of operation (for example, hash) value of a part of the certificate containing the corresponding public key, or the same meaning as referring to the storage space in which data is stored. They can be used interchangeably.

"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 according to an embodiment of the present disclosure.

According to various embodiments, as in the example of FIG. 1, the terminal 110 may include the 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 is a conceptual diagram illustrating an internal structure of a Smart Secure Platform (SSP) according to an embodiment of the present disclosure.

According to various embodiments, as in the example of FIG. 2, the SSP 210 includes one primary platform (PP) 220 and at least one secondary platform bundle (SPB) operating thereon. ) (230, 240) may be included.

According to various embodiments, the primary platform 220 may include hardware (not disclosed) 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.

According to various embodiments, as in the example of FIG. 3, 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 equipped with an SSP 330 and an LBA 312 for controlling the SSP 330. 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 a different bundle family identifier and/or a bundle family manager identifier 341, 342, or 343. These bundle family identifiers and bundle family manager identifiers may be used as information necessary for downloading and installing bundles. 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 the bundle family manager identifier.

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.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 4, the first terminal 400 includes the LBA 410 and the SSP 420, and the second terminal 450 includes the LBA 460 and the 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 user 440 and the second user 490 issue commands to the LBAs 410 and 460 of the first terminal 400 and the second terminal 450. It is possible to send or receive information to be provided by the user from the LBAs 410 and 460.

According to various embodiments, the above operation may include a process of selecting a bundle to be transmitted by the user. In addition, the above operation may further include a process of confirming the information of the bundle that the user wants to receive. In addition, the above operation may further include an operation of approving whether to transmit a bundle to be transmitted by the user. In addition, the above operation may further include an operation of approving whether or not to transmit a bundle to be transmitted by the user.

In addition, according to various embodiments, the above operation may include a process of selecting a bundle in order for the user to resume use of a bundle that has been suspended. In addition, the above operation may further include a process of checking information on the bundle for which the user has received a request to resume use. In addition, the above operation may further include an operation of approving a bundle to be resumed by the user. Also, the above operation may further include an operation of approving the resumption of use of the bundle for which the user has received a request to resume use.

The above-described selection and approval operations may not all be operated independently of each other, or one or more operations may be independently selected and operated.

In addition, in operations 4020 and 4070, the LBAs 410 and 460 may issue commands to the SSPs 420 and 470 or transmit and receive data with the SSPs 420 and 470.

According to an example, in the above operation, the LBA may receive the above-described user's command and transmit the command to the SSP. In the above operation, when the LBA receives the user's command and transmits the command to the SSP, the LBA may receive the result transmitted by the SSP as a result.

According to another example, in the above operation, the LBA may transmit a command or data received from another terminal or an external server to the SSP. In the above operation, when the LBA transmits a command or data received from another terminal or an external server to the SSP, the LBA may receive a result transmitted by the SSP as a result.

According to various embodiments, in the above operation, the 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 this to the SSP. In the above operation, when the LBA defines new commands and data based on the user's command or commands or data received from other terminals or external servers and delivers them to the SSP, the LBA receives the result sent by the SSP as a result. can do.

According to various embodiments, in the above operation, the LBA and the SSP may transmit and receive data to and from each other to install a bundle.

According to various embodiments, in operation 4050, the two LBAs 410 and 460 may be connected to each other to give a command to the partner or to transmit and receive data with the partner. At this time, the connection in operation 4050 may be a direct connection between the terminal and the device of the terminal, and although not shown, an external entity (eg, an external server) is connected between the connection between the two LBAs 410 and 460. It may be a connection between devices.

For a more detailed description of the connection method between the two LBAs described above, reference will be made to the drawings to be described later.

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

According to various embodiments, in the above operation, the SSP may check the bundle movement setting. In addition, in the above operation, the SSP can generate and utilize the bundle movement code. The operation related to the bundle movement setting and the operation related to the bundle movement code described above are functions independent of each other, 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 above operation, the SSP may generate its own SSP information or verify SSP information received from a counterpart terminal and/or a server. In addition, in the above operation, the SSP may generate authentication data capable of verifying itself or may verify authentication data received from the counterpart terminal.

According to various embodiments, in the above operation, the SSP may generate a "certificate" to be described in FIG. 5 and verify the received "certificate". Examples of various "certificates" that can be generated/verified by the SSP will be described with reference to FIGS. 10 to 15 and 22 to 27 to be described later.

According to various embodiments, in the above operation, the SSP may set the state of the bundle. The states and setting conditions of various bundles that can be set by the SSP will be described with reference to FIGS. 10 to 15 and 22 to 27 to be described later.

According to various embodiments, in the above operation, the SSP may generate a bundle.

5 is a diagram illustrating a configuration of a "certificate (Attestation)" according to some embodiments of the present disclosure.

According to various embodiments, the certificate may optionally include a "bundle identifier" (510). For example, the certificate may selectively include a bundle identifier (SPB ID), which is one of the bundle identifiers, as shown in FIG. 5.

According to various embodiments, the certificate may optionally further include another certificate (530 ). Various examples of another certificate included in the certificate will be referred to the description of FIGS. 10 to 15 which will be described later.

According to various embodiments, the certificate may optionally further include an “SSP identifier (SSP ID)” (540).

According to various embodiments, the certificate may optionally further include information on an operation performed by the SSP (550). Various examples of operations performed by the SSP will be described with reference to the descriptions of FIGS. 10 to 15 to be described later.

According to various embodiments, the certificate may optionally further include other data other than the above-described information 530, 540, and 550 if necessary (520). For various examples of other data that may be included in the certificate, reference is made to the description of FIGS. 10 to 15 which will be described later.

According to various embodiments, the certificate may include electronic signature data for the above-described information (560). This signature data may be an electronic signature generated by the SSP's signature certificate.

6 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.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 6, the first terminal 600 includes a first LBA 620 and a first SSP 610, and the second terminal 650 includes a second LBA 670 and It may include a second SSP (660). For example, the first terminal 600 may be a terminal equipped with a first SSP 610 and a first LBA 620 for controlling the first SSP 610, and the second terminal 650 2 It may be a terminal in which the SSP 660 is mounted and the second LBA 670 for controlling the second SSP 660 is installed.

6, in step 6000, the first SSP 610 of the first terminal 600, the first LBA 620, and the second LBA 670 of the second terminal 650 are prepared for bundle transmission. You can perform a procedure (a procedure for preparing to send a bundle). For a more detailed description of the above procedure, reference will be made to the detailed description of FIG. 7 to be described later.

Referring to FIG. 6, in step 6005, a procedure of transmitting a bundle from the first terminal 600 to the second terminal 650 (a bundle transmission procedure) may be performed. For a more detailed description of the above procedure, reference will be made to the detailed description of FIG. 8 to be described later.

Referring to FIG. 6, in step 6010, the first terminal 600 and the second terminal 660 may perform a procedure for installing a transmitted bundle and a procedure for setting a state of the bundle (a procedure for completing a bundle transmission). For a detailed description of the above procedure, reference will be made to the detailed description of FIGS. 9 to 12 to be described later.

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

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 7, 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 It may include a second SSP (760). 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.

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

According to various embodiments, the first terminal 700 is associated with a corresponding bundle to provide 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). You may have it.

According to various embodiments, the first terminal 700 may be associated with a corresponding bundle and hold a'bundle movement setting'. The bundle movement setting may selectively include information related to whether a corresponding bundle can be transmitted between devices. In addition, the bundle movement setting may selectively further include information on whether a corresponding bundle can be used repeatedly in a plurality of terminals. For example, if the bundle is'forbidden to be used repeatedly in multiple terminals at the same time', that is, if'the bundle should be used only in one terminal at a certain point in time', information about this may be included. have.

Referring to FIG. 7, information of a bundle to be transmitted between devices may be transmitted to the first LBA 720 in step 7000. This delivery process may be performed, for example, through a process in which a user directly selects a bundle through a UI provided by the first terminal 700, as shown in FIG. 7, or through a push input from a remote server. It may be input to 720, or the first LBA 720 may access the remote server and read the corresponding information.

Referring to FIG. 7, information related to a bundle selected through steps 7005 to 7000 may be transferred from the first LBA 720 to the first SSP 710. For example, as shown in FIG. 7, information related to the selected bundle may be transmitted from the first LBA 720 to the first SSP 710 through the Select SPB command. In this case, the information transmitted from the first LBA 720 to the first SSP 710 may include information for identifying the bundle selected in step 7000.

Referring to FIG. 7, in step 7010, the first SSP 710 may check whether a bundle requested to be transmitted can be transmitted between devices. This process may be performed by first identifying a bundle requested to be transmitted based on the information received in step 7005, and confirming a'bundle movement setting' associated with the bundle. In this process, when the'bundle movement setting' includes'information on whether a corresponding bundle can be used repeatedly in a plurality of terminals', the first SSP 710 may confirm this fact.

In addition, in step 7010, the first SSP 710 may selectively set a'bundle movement code'. The'bundle movement code' is a code used to refer to the corresponding bundle in the process of transmitting the bundle between devices and must be a value that can identify the corresponding bundle. The first SSP 710 may bind the'bundle movement code' described above with information of a bundle to be transmitted.

Referring to FIG. 7, a response result for step 7005 in step 7015 may be transmitted from the first SSP 710 to the first LBA 720. For example, as shown in FIG. 7, a response to the Select SPB command may be transmitted from the first SPB 710 to the first LBA 720 through the Select SPB response. This response value may include the'bundle movement code' described in step 7010.

Referring to FIG. 7, information necessary for inter-device bundle transmission in step 7020 may be transferred from the first LBA 720 of the first terminal 700 to the second LBA 770 of the second terminal 750. . In this case, information transmitted from the first LBA 720 to the second LBA 770 may include a'bundle movement code'. 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 720 and the second LBA 770 in the next step 7025. Optionally, it may further include. In addition, the information transmitted from the first LBA 720 to the second LBA 770 may optionally further include information indicating that the inter-device bundle movement is to be performed.

Information transferred from the first LBA 720 to the second LBA 770 through the above-described step 7020 may be transferred in various ways. For example, the first LBA 720 may provide information to be transmitted to the second LBA 770 to the user through the UI of the first terminal 700, and the user provides the received information to the second terminal ( 750) can be entered into the second LBA 770. Alternatively, the first LBA 720 creates information to be transmitted to the second LBA 770 in the form of an image (for example, a QR code) and displays it on the screen of the first terminal 700, and the user By scanning this image using 750, information can be passed to the second LBA 770. However, a method of transferring information from the first LBA 720 to the second LBA 770 is not limited to the above methods.

Referring to FIG. 7, a connection may be established (or established) between the first LBA 720 and the second LBA 770 in step 7025. If information necessary for connection is transmitted in step 7020, the first LBA 720 and the second LBA 770 may establish a connection using this information. The connection between the first LBA 820 and the second LBA 870 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 LBA 720 and the second LBA 770.

Referring to FIG. 7, step 7025 is shown as a final step, but this step is independent of the other steps described above, i.e., steps 7000, 7005, 7010, 7015, and 7020. Can be done without For example, step 7025 may be performed between steps 7015 and 7020. In this case, information transmitted from the first LBA 720 to the second LBA 2 770 in step 7020 is through the connection established in step 7025. It can also be transmitted.

8 is a diagram illustrating a detailed procedure for a procedure in which a bundle is transmitted among the procedures presented in FIG. 6. In more detail, FIG. 8 is a diagram illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure. In the present disclosure, the procedure of FIG. 8 may be referred to as a bundle transmission procedure.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 8, the first terminal 800 includes a first LBA 820 and a first SSP 810, and the second terminal 850 includes a second LBA 870 and It may include a second SSP (860). 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.

Referring to FIG. 8, in step 8000, the second LBA 870 may request “SSP information (SspInfo)” from the second SSP 2 860. In step 8000, when the second LBA 870 requests "SSP information (SspInfo)" from the second SSP 860, the second LBA 870 indicates that the bundle movement between devices will be performed to the second SSP 860. I can tell you.

In addition, step 8000 may be automatically performed immediately following the process illustrated in FIG. 8, or may be performed after receiving an external input. In this case, the'external input' may be performed through a process of selecting a bundle to be directly transmitted by the user through a UI provided by the second terminal 850, or the second LBA 870 through a push input from a remote server. Alternatively, the second LBA 870 may access the remote server to read the corresponding information.

Referring to FIG. 8, in step 8005, the second SSP 860 may generate its own “SSP information”. The "SSP information" may include information on the second SSP 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 860 must go through before receiving the bundle. This "certificate negotiation information" may include certificate information (SenderSpblVerification) that the second SSP 860 can use to verify another SSP and certificate information (ReceiverSpblVerification) that can be used by another SSP to verify itself. have. In addition, the "certificate negotiation information" may optionally further include a list of key agreement algorithms supported by the second SSP 860, and may optionally further include a list of encryption algorithms supported by the second SSP 860. I can. In addition, the "SSP information" may optionally further include SSP version information including at least one of version information of a standard standard supported by a primary platform and a loader included in the second SSP 960.

Referring to FIG. 8, in step 8010, the second SSP 860 may transmit the "SSP information" generated in step 8005 to the first SSP 810 through the second LBA 870 and the first LBA 820. have.

According to steps 8000 to 8010 described above, the second LBA 870 requests "SSP information (SspInfo)" from the second SSP 860, and the second SSP 860 generates its own "SSP information". After that, the second SSP 860 may transmit “SSP information” to the first SSP 810 through the second LBA 870 and the first LBA 820. However, depending on the embodiment, the process of transmitting "SSP information" from the second terminal 850 to the first terminal 800 may be as follows. For example, after the second LBA 870 generates “SSP information” by itself, the “SSP information” may be transmitted to the first SSP 810 through the first LBA 820.

Referring to FIG. 8, in step 8015, the first SSP 810 checks the received “SSP information” and generates “first terminal authentication information (Device1.Auth)” capable of authenticating itself based on this information. can do. A more detailed procedure for this process is as follows.

The first SSP 810 may check certificate information capable of verifying itself using the received "SenderSpblVerification" and select at least one key agreement certificate (ssp1.Cert.KA). Alternatively, the first SSP 810 uses the received "list of key agreement algorithms supported by the second SSP 860" to be used for key agreement, the asymmetric encryption key pair public key "ssp1.ePK.KA" After creating "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 810 may check certificate information capable of verifying itself using the received "SenderSpblVerification" and further select at least one signing certificate (ssp1.Cert.DS).

In addition, the first SSP 810 may select at least one certificate information of the second SSP 860 to be verified using the received "ReceiverSpblVerification" and then set the corresponding information to "CiPkIdToBeUsed".

In addition, the first SSP 810 may select at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 860" and then set corresponding information to "CryptoToBeUsed". .

In addition, the first SSP 810 checks the list of the received "version information of the primary platform included in the second SSP 860 and the standard standard supported by the loader", and among them, the version of the standard standard that it also supports. You can check if it exists.

The “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 optionally further include "ssp1.Cert.DS" described above. In addition, the "first terminal authentication information (Device1.Auth)" may optionally 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. I can.

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

Referring to FIG. 8, in step 8020, the first SSP 810 transmits the “first terminal authentication information (Device1.Auth)” generated in step 8015 to the second LBA 870 through the first LBA 820. I can.

Referring to FIG. 8, in step 8025, the second LBA 870 may transmit “first terminal authentication information (Device1.Auth)” to the second SSP 860. In addition, the second LBA 870 may further transmit a "bundle movement code" to the second SSP 860.

Referring to FIG. 8, in step 8030, the second SSP 860 may verify the received “first terminal authentication information (Device1.Auth)”. If the second SSP 860 receives "ssp1.Cert.KA", it may check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 860 receives "ssp1.ePK.KA" and a digital signature for it, it first checks the validity of ssp1.Cert.DS and then checks the digital signature using this certificate. You can check the integrity of the public key ssp1.ePK.KA. In addition, the second SSP 860 may select at least one signing certificate (ssp2.Cert.DS) capable of verifying itself by checking the received "CiPkIdToBeUsed".

Further, although not shown in the drawing, in step 8030, the second SSP 960 uses a public key "ssp2.ePK.KA" and a private key "ssp2.eSK." as an asymmetric encryption key pair to be used for key agreement. After creating "KA", you can select the public key (ssp2.ePK.KA) from this key pair. In addition, the second SSP 860 selects one of the public key for key agreement or ssp1.ePK.KA included in ssp1.Cert.KA, and then uses this value and ssp2.eSK.KA to communicate with the terminal 1 in the future. Session key ShKey01 to be used for encryption during communication can be generated. ShKey01 must be a session key for the encryption algorithm included in the received "CryptoToBeUsed".

In addition, in step 8030, the second SSP 860 may generate “second terminal authentication information (Device2.Auth)” capable of authenticating itself. 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 the current session generated by the SSP 2 860. 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 an SSP identifier of the second SSP 960. In addition, the "second terminal authentication information (Device2.Auth)" may optionally 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. I can.

At this time, some or all of the "second terminal authentication information (Device2.Auth)" mentioned above may be digitally signed so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information, and this digital signature Data may be added as part of the "second 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.

Referring to FIG. 8, in step 8035, the second SSP 860 passes through the second LBA 870 and the first LBA 820 to the first SSP 810 generated in step 8030. Device2.Auth)" can be delivered. In this case, a "bundle movement code" may be selectively further transmitted.

Referring to FIG. 8, in step 8040, the first SSP 810 may verify the received “second terminal authentication information (Device2.Auth)”. The first SSP 810 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp2.Cert.DS". In addition, the first SSP 810 checks whether the received bundle family identifier (SPB Family ID) and/or the bundle family manager identifier (SPB Family Custodian Object ID) is a value set correctly in association with the bundle to be transmitted. I can. In addition, the first SSP 810 may store the received transaction ID and/or the SSP identifier of the second SSP 860. In addition, the first SSP 810 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 this process, if encrypted data is included in the "second terminal authentication information (Device2.Auth)", the first SSP 810 is sent to the received ssp2.ePK.KA and its own ssp1.Cert.KA. A session key ShKey01 can be generated using a private key corresponding to the included public key for key agreement or ssp1.eSK.KA, and the encrypted data can be decrypted using this session key, and then the verification process can be performed. In addition, in this process, if a digital signature is included in the "second terminal authentication information (Device2.Auth)", the first SSP 810 uses the "ssp2.Cert.DS" to determine the validity of the digital signature received. Can be verified.

In addition, in step 8040, although not shown in FIG. 8, the first SSP 810 includes an asymmetric encryption key pair public key "ssp1.bundle.ePK.KA" and a private key "ssp1. bundle.eSK.KA" can be created. At this time, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" may be set to the same value as the previously created "ssp1.ePK.KA and ssp1.eSK.KA". Alternatively, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" will be set to the same value as the public key included in the previously used "ssp1.Cert.KA and the corresponding private key". May be. Also, the first SSP 810 may generate the session key ShKey02 using ssp1.bundle.eSK.KA and ssp2.ePK.KA. If ssp1.eSK.KA or the private key corresponding to the public key included in ssp1.Cert.Ka is reused for ssp1.bundle.eSK.KA, the value of the session key ShKey02 is also of the previously generated ShKey01. Can be set to a value.

In addition, in step 8040, the first SSP 810 may configure a bundle to be transmitted to the second terminal 850 and/or metadata associated with the bundle. In this case, the first SSP 810 may identify a bundle to be transmitted by using the received "bundle movement code". In addition, "ssp1.Cert.DS" may be included in the bundle to be configured. In addition, the bundle to be configured may further include "ssp1.bundle.ePK.KA". In addition, the bundle to be configured may further include a transaction ID identifying a corresponding session. In addition, the bundle to be configured may optionally 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 to-be-transmitted bundle. According to various embodiments, a "bundle movement setting" may be included in the bundle (or metadata associated with the bundle) configured in step 8040.

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

Referring to FIG. 8, in step 8045, a first SSP 810 may deliver a bundle generated (configured) in step 8040 to a second LBA 870 through a first LBA 820. In this case, metadata associated with the transmitted bundle may be selectively further transmitted. In addition, a "bundle movement setting" associated with the transmitted bundle may be further transmitted. For example, the “bundle movement setting” may not be included in the bundle or metadata, but may be transmitted in a separate format (eg, a message).

9 is a diagram illustrating a detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6. In more detail, FIG. 9 is a possible example of a diagram illustrating a process in which a bundle is installed in a terminal and a process in which a bundle state is set after a bundle is transmitted according to an embodiment of the present disclosure.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 9, 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 It may include a second SSP (960). 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.

1. Bundle installation

Referring to FIG. 9, in step 9000, the second LBA 970 and the second SSP 960 may cooperate with each other to install a bundle in the second terminal 950. In this process, the following procedures can be performed together. If metadata is transmitted, the second LBA 970 or the second SSP 960 may verify the content included in the metadata. If "bundle movement setup" has been transmitted, the second LBA 970 may transmit this information to the second SSP 960. If a transaction ID has been transmitted, the second LBA 970 or the second SSP 960 may check whether the transaction ID is the same as the transaction ID used in the current session. If 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 It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS has been transmitted, the second SSP 960 may authenticate the first SSP 910 by verifying the validity of this certificate. If the transmitted data contains encrypted data, the second SSP 960 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, verification can be performed. If the received data includes a digital signature, the second SSP 960 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.

2. Check whether duplicates can be used

In addition, although not shown in the drawing, the second LBA 970 and/or the second SSP 960 may selectively determine whether a corresponding bundle can be used repeatedly in a plurality of terminals. Some possible ways to make this judgment are: As one possible example, if the bundle movement configuration includes whether the corresponding bundle can be used repeatedly in a plurality of terminals, the second LBA 970 and/or the second SSP 960 determine this information by checking this information. You can get it down. As another possible example, the second LBA 970 and/or the second SSP 960 uses the received bundle family identifier (SPB Family ID) and/or the bundle family manager identifier (SPB Family Custodian Object ID) to have multiple bundles. It is also possible to check whether it is possible to redundantly use the terminal of As part of step 9000, this process may be performed in any order and procedures performed in step 9000, or may be performed after step 9000.

3. Bundle Status Setting

If the bundle is determined to be a bundle that can be used repeatedly in a plurality of terminals, a process of additionally setting the bundle state may not be necessary. Alternatively, even when the second LBA 970 and/or the second SSP 960 does not determine whether the corresponding bundle is used repeatedly, according to the implementation of the second LBA 970 and/or the second SSP 960 The process of additionally configuring the bundle state may not be necessary.

FIG. 10 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6. In more detail, FIG. 10 is another example of a diagram illustrating a process of installing a bundle in a terminal and a process of setting a bundle state after a bundle is transmitted according to an embodiment of the present disclosure.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 10, the first terminal 1000 includes a first LBA 1020 and a first SSP 1010, and the second terminal 1050 includes a second LBA 1070 and It may include a second SSP (1060). As an example, the first terminal 1000 may be a terminal equipped with a first SSP 1010 and a first LBA 1020 for controlling the first SSP 1010, and the second terminal 1050 2 It may be a terminal in which the SSP 1060 is mounted and the second LBA 1070 for controlling the second SSP 1060 is installed.

1. Bundle installation

Referring to FIG. 10, in step 10000, the second LBA 1070 and the second SSP 1060 may cooperate with each other to install a bundle in the second terminal 1050. For a detailed description of this, refer to the "bundle installation" process of FIG. 9.

2. Check whether duplicates can be used

In addition, although not shown in the drawings, the second LBA 1070 and/or the second SSP 1060 may selectively determine whether the corresponding bundle can be used repeatedly in a plurality of terminals. Refer to the procedure "Checking whether duplicates can be used" in 9.

3. Bundle Status Setting

If the bundle is determined to be a bundle that cannot be used repeatedly in a plurality of terminals, the bundle state is additionally set as follows. Alternatively, even when the second LBA 1070 and/or the second SSP 1060 does not determine whether the corresponding bundle is used repeatedly, according to the implementation of the second LBA 1070 and/or the second SSP 1060 The process of additionally setting the bundle state may be performed as follows.

Referring to FIG. 10, in step 10005, the second SSP 1060 may set the state of a corresponding bundle to “IN TRANSITION”. "IN TRANSITION" is a state in which the bundle has been successfully installed but is not yet usable (also,'a request from another terminal (for example, a request made by sending a'finalizationResponse or recoveryRequest)')' and/or'(explained in this disclosure) It means a state that can be changed to an available state (Disabled, Enable, Active state) only by an additional operation such as'Request from an external server'.

Referring to FIG. 10, in step 10010, the second LBA 1070 may request a “certificate” from the second SSP 1060.

Referring to FIG. 10, in step 10015, the second SSP 1060 may generate a “certificate”. In Fig. 10, this certificate may be called finalizationRequest. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The finalizationRequest may include a "bundle identifier" of a corresponding bundle in 510.

- The finalizationRequest may include the "SSP identifier" of the second SSP in 540.

- The finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 550.

- The finalizationRequest may optionally include, in 520, a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created.

- The finalizationRequest may include signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 10, in step 10020, the second SSP 1060 may transmit a finalization Request to the first SSP 1010. For example, the second SSP 1060 may transmit a finalizationRequest to the first SSP 1010 through the following process. That is, the second SSP 1060 may transmit a finalizationRequest to the second LBA 1070 in a response of step 10010, and the second LBA may transmit a finalizationRequest to the first SSP through the first LBA 1020.

Referring to FIG. 10, in step 10025, the first SSP 1010 may verify the received finalizationRequest. This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP. In addition, the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.

Also, in step 10025, the first SSP 1010 may delete the bundle after completing the verification.

In addition, in step 10025, the first SSP 1010 may generate a "certificate". In Fig. 10, this certificate may be called finalizationResponse. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The finalizationResponse may include a "bundle identifier" of a corresponding bundle in 510.

- The finalizationResponse may include the "SSP identifier" of the first SSP in 540.

- The finalizationResponse may include information indicating that the first SSP has deleted the bundle in 550.

- The finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 520.

- The finalizationResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Also, another example of a possible certificate configuration is as follows.

- The finalizationResponse may include the finalizationRequest received at 530. In this case, some information of the received finalizationRequest may be omitted if necessary. For example, signature information of the second SSP included in the finalizationRequest may be omitted in some cases. Also, for example, time information included in the finalizationRequest may be omitted in some cases.

- The finalizationResponse may include the "SSP identifier" of the first SSP in 540.

- The finalizationResponse may include information indicating that the first SSP has deleted the bundle in 550.

- The finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 520.

- The finalizationResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Referring to FIG. 10, in step 10030, a first SSP 1010 may transmit a finalizationResponse to a second SSP 1060. For example, the first SSP 1010 may transmit a finalizationResponse to the second SSP 1060 through the first LBA 1020 and the second LBA 1070.

Referring to FIG. 10, in step 10035, the second SSP 1060 may verify the received finalizationResponse. This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse. In addition, the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle. In addition, the verification process may optionally further include a process of checking whether the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse. In addition, the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse. In addition, the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.

In addition, in step 10035, the second SSP 1060 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification. For example, as shown in the drawing, the second SSP 1060 may convert the state of the bundle to the Disabled state.

Referring to FIG. 10, in step 10040, a second SSP 1060 may transmit a result (eg, success or failure) of a task performed in step 10035 to a second LBA 1070.

FIG. 11 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6. In more detail, FIG. 11 is another example of a diagram illustrating a process of installing a bundle in a terminal and a process of setting a bundle state after a bundle is transmitted according to an embodiment of the present disclosure.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 11, the first terminal 1100 includes a first LBA 1120 and a first SSP 1110, and the second terminal 1150 includes a second LBA 1170 and A second SSP 1160 may be included. For example, the first terminal 1100 may be a terminal equipped with a first SSP 1110 and a first LBA 1120 for controlling the first SSP 1110, and the second terminal 1150 2 It may be a terminal in which the SSP 1160 is mounted and the second LBA 1170 for controlling the second SSP 1160 is installed.

1. Bundle installation

Referring to FIG. 11, in step 11000, the second LBA 1170 and the second SSP 1160 may cooperate with each other to install a bundle in the second terminal 1150. For a detailed description of this, refer to the "bundle installation" process of FIG. 9.

2. Check whether duplicates can be used

In addition, although not shown in the drawings, the second LBA 1170 and/or the second SSP 1160 may selectively determine whether the corresponding bundle can be used repeatedly in a plurality of terminals. Refer to the procedure "Checking whether duplicates can be used" in 9.

3. Bundle Status Setting

If the bundle is determined to be a bundle that cannot be used repeatedly in a plurality of terminals, the bundle state is additionally set as follows. Alternatively, even when the second LBA 1170 and/or the second SSP 1160 does not determine whether the bundle is used repeatedly, according to the implementation of the second LBA 1170 and/or the second SSP 1160 The process of additionally setting the bundle state may be performed as follows.

Referring to FIG. 11, in step 11005, the second SSP 1160 may set the state of a corresponding bundle to “IN TRANSITION”. For a description of the "IN TRANSITION" state, refer to the description of step 10005.

Referring to FIG. 11, in step 11010, the second LBA 1170 may request a “certificate” from the second SSP 1160.

Referring to FIG. 11, in step 11015, the second SSP 1160 may generate a “certificate”. In Fig. 11, this certificate may be called finalizationRequest. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The finalizationRequest may include a "bundle identifier" of a corresponding bundle in 510.

- The finalizationRequest may include the "SSP identifier" of the second SSP in 540.

- The finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 550.

- The finalizationRequest may optionally include, in 520, a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created.

- The finalizationRequest may include signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 11, in step 11020, the second SSP 1160 may transmit a finalization Request to the first SSP 1110. For example, the second SSP 1160 may transmit a finalizationRequest to the first SSP 1110 through the following process. That is, the second SSP 1160 may transmit the finalizationRequest to the second LBA 1170 in response to step 11010, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1120.

Referring to FIG. 11, in step 11025, the first SSP 1110 may verify the received finalizationRequest. This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP. In addition, the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.

In addition, in step 11025, the first SSP 1110 may set the state of the bundle to the "IN TRANSITION" state after completing the verification.

In addition, in step 11025, the first SSP 1110 may generate a "certificate". In Fig. 11, this certificate may be called finalizationResponse. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The finalizationResponse may include a "bundle identifier" of a corresponding bundle in 510.

- The finalizationResponse may include the "SSP identifier" of the first SSP in 540.

- The finalizationResponse may include information indicating that the first SSP changed the state of the bundle to the "IN TRANSITION" state in 550.

- The finalizationResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.

- The finalizationResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

In addition, one example with different possible certificate configurations is as follows.

- The finalizationResponse may include the finalizationRequest received at 530. In this case, some information of the received finalizationRequest may be omitted if necessary. For example, signature information of the second SSP included in the finalizationRequest may be omitted in some cases. Also, for example, time information included in the finalizationRequest may be omitted in some cases.

- The finalizationResponse may include the "SSP identifier" of the first SSP in 540.

- The finalizationResponse may include information indicating that the first SSP changed the state of the bundle to the "IN TRANSITION" state in 550.

- The finalizationResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.

- The finalizationResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Referring to FIG. 11, in step 11030, a first SSP 1110 may transmit a finalizationResponse to a second SSP 1160. For example, the first SSP 1110 may transmit a finalizationResponse to the second SSP 1160 through the first LBA 1120 and the second LBA 1170.

Referring to FIG. 11, in step 11035, the second SSP 1160 may verify the received finalizationResponse. This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse. In addition, the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle. In addition, the verification process may optionally further include a process of checking whether the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse. In addition, the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse. In addition, the verification process may further include a process of checking whether command information included in the finalizationResponse is correct.

In addition, in step 11035, the second SSP 1160 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification. For example, as shown in the drawing, the second SSP 1160 may convert the state of the bundle to the Disabled state.

In addition, in step 11035, the second SSP 1160 may generate a "certificate". In FIG. 10, this certificate may be referred to as spblAttestation. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- spblAttestation may include the "bundle separator" of the corresponding bundle in 510.

- spblAttestation may include “SSP identifier” of the second SSP in 540.

- The spblAttestation may include information indicating that the second SSP has changed the state of the bundle to an available state in 550.

- The spblAttestation may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.

- spblAttestation may include the signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

In addition, one example with different possible certificate configurations is as follows.

- spblAttestation may include the finalizationResponse received at 530. In this case, some information of the received finalizationResponse may be omitted if necessary. For example, some of the signature information included in the finalizationResponse may be omitted in some cases. Also, for example, some of the time information included in the finalizationResponse may be omitted in some cases.

- spblAttestation may include “SSP identifier” of the second SSP in 540.

- The spblAttestation may include information indicating that the second SSP has changed the state of the bundle to an available state in 550.

- The spblAttestation may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.

- spblAttestation may include the signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 11, in step 11040, the second SSP 1160 may transmit spblAttestation to the first SSP 1110. For example, the second SSP 1160 may transmit spblAttestation to the first SSP through the second LBA 1170 and the first LBA 1120.

Referring to FIG. 11, in step 11045, the first SSP 1110 may verify the received spblAttestation. This verification process may include checking the validity of the signature of the second SSP included in the spblAttestation. In addition, the verification process may further include a process of checking whether the "bundle separator" included in spblAttestation matches the bundle identifier of the corresponding bundle. In addition, the verification process may optionally further include a process of checking whether the finalizationResponse included in the spblAttestation matches the information transmitted by the spblAttestation. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the spblAttestation is a correct identifier of the second SSP. In addition, the verification process may further include a process of confirming whether command information included in spblAttestation changes the state of the bundle to a usable state.

Also, in step 11045, the first SSP 1110 may delete the bundle after completing the verification.

12 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6. In more detail, FIG. 12 is another example of a diagram illustrating a process in which a bundle is installed in a terminal and a process in which a bundle state is set after a bundle is transmitted according to an embodiment of the present disclosure.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 12, the first terminal 1200 includes a first LBA 1220 and a first SSP 1210, and the second terminal 1250 includes a second LBA 1270 and A second SSP 1260 may be included. For example, the first terminal 1200 may be a terminal equipped with a first SSP 1210 and a first LBA 1220 for controlling the first SSP 1210, and the second terminal 1250 2 It may be a terminal in which the SSP 1260 is mounted and the second LBA 1270 for controlling the second SSP 1260 is installed.

1. Bundle installation

Referring to FIG. 12, in step 12000, the second LBA 1270 and the second SSP 1260 may cooperate with each other to install a bundle in the second terminal 1250. For a detailed description of this, refer to the "bundle installation" process of FIG. 9.

2. Check whether duplicates can be used

In addition, although not shown in the drawings, the second LBA 1270 and/or the second SSP 1260 can selectively determine whether the corresponding bundle can be used repeatedly in a plurality of terminals. Refer to the procedure "Checking whether duplicates can be used" in 9.

3. Bundle Status Setting

If the bundle is determined to be a bundle that cannot be used repeatedly in a plurality of terminals, the bundle state is additionally set as follows. Alternatively, even when the second LBA 1270 and/or the second SSP 1260 does not determine whether the corresponding bundle is used repeatedly, according to the implementation of the second LBA 1270 and/or the second SSP 1260 The process of additionally setting the bundle state may be performed as follows.

Referring to FIG. 12, in step 12005, the second SSP 1260 may set the state of a corresponding bundle to “IN TRANSITION”. For a description of the "IN TRANSITION" state, refer to the description of step 10005.

Referring to FIG. 12, in step 12010, the second LBA 1270 may request a “certificate” from the second SSP 1260.

Referring to FIG. 12, in step 12015, the second SSP 1260 may generate a “certificate”. In Fig. 12, this certificate may be called finalizationRequest. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The finalizationRequest may include a "bundle identifier" of a corresponding bundle in 510.

- The finalizationRequest may include the "SSP identifier" of the second SSP in 540.

- The finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 550.

- The finalizationRequest may optionally include, in 520, a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created.

- The finalizationRequest may include signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 12, in step 12020, the second SSP 1260 may transmit a finalization Request to the first SSP 1210. For example, the second SSP 1260 may transmit a finalizationRequest to the first SSP 1210 through the following process. That is, the second SSP 1260 may transmit the finalizationRequest to the second LBA 1270 in the response of step 12010, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1220.

Referring to FIG. 12, in step 12025, the first SSP 1210 may verify the received finalizationRequest. This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP. In addition, the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.

In addition, in step 12025, the first SSP 1210 may set the state of the bundle to the "SUSPENSION" state after completing the verification. "SUSPENSION" is in a state in which the bundle cannot be used (also, a request from another terminal (for example, a request made by sending a recoveryRequest)) and/or a request from an external server (though not described in this disclosure). It means a state that can be changed to an available state (Disabled, Enable, Active state). Further, although not shown in the drawing, the "SUSPENSION" state described above may be replaced with the "IN TRANSITION" state.

Also, in step 12025, the first SSP 1210 may generate a "certificate". In Fig. 12, this certificate may be called finalizationResponse. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The finalizationResponse may include a "bundle identifier" of a corresponding bundle in 510.

- The finalizationResponse may include the "SSP identifier" of the first SSP in 540.

- The finalizationResponse may include information in 550 indicating that the first SSP has changed the state of the bundle to the "SUSPENSION" (or IN TRANSITION) state.

- The finalizationResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.

- The finalizationResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Also, another example of a possible certificate configuration is as follows.

- The finalizationResponse may include the finalizationRequest received at 530. In this case, some information of the received finalizationRequest may be omitted if necessary. For example, signature information of the second SSP included in the finalizationRequest may be omitted in some cases. Also, for example, time information included in the finalizationRequest may be omitted in some cases.

- The finalizationResponse may include the "SSP identifier" of the first SSP in 540.

- The finalizationResponse may include information in 550 indicating that the first SSP has changed the state of the bundle to the "SUSPENSION" (or IN TRANSITION) state.

- The finalizationResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.

- The finalizationResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Referring to FIG. 12, in step 12030, a first SSP 1210 may transmit a finalizationResponse to a second SSP 1260. For example, the first SSP 1210 may transmit a finalizationResponse to the second SSP 1260 through the first LBA 1220 and the second LBA 1270.

Referring to FIG. 12, in step 12035, the second SSP 1260 may verify the received finalizationResponse. This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse. In addition, the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle. In addition, the verification process may optionally further include a process of checking whether the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse. In addition, the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse. In addition, the verification process may further include a process of checking whether command information included in the finalizationResponse is correct.

Also, in step 12035, the second SSP 1260 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification. For example, as shown in the drawing, the second SSP 1260 may convert the state of the bundle to the Disabled state.

Referring to FIG. 12, in step 12040, the second SSP 1260 may transmit a result (eg, success or failure) of the task performed in step 12035 to the second LBA 1270.

13 is a diagram illustrating an example of a procedure for making a bundle that has been discontinued to be used again. In more detail, it is an example of a diagram showing a procedure for setting a bundle in an "IN TRANSITION" state or a "SUSPENSION" state to a usable state again.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 13, the first terminal 1300 includes a first LBA 1320 and a first SSP 1310, and the second terminal 1350 includes a second LBA 1370 and A second SSP 1360 may be included. As an example, the first terminal 1300 may be a terminal equipped with a first SSP 1310 and a first LBA 1320 for controlling the first SSP 1310, and the second terminal 1350 2 It may be a terminal in which the SSP 1360 is mounted and the second LBA 1370 for controlling the second SSP 1360 is installed.

A possible example when the state of the bundle is set to the "IN TRANSITION" state or the "SUSPENSION" state before the procedure disclosed in FIG. 13 is performed is as follows. For example, in the step in which the transmission of the bundle disclosed in FIG. 11 is finished, if step 11025 is performed but step 11045 is not performed, the state of the bundle in the first terminal 1300 is set to the "IN TRANSITION" state. There will be. As another example, if step 12025 is performed in the step in which the transmission of the bundle disclosed in FIG. 12 is completed, the state of the bundle in the first terminal 1300 will be set to the "IN TRANSITION" state or the "SUSPENSION" state. .

Referring to FIG. 13, in step 13000, information on a bundle for requesting to resume use may be transmitted to the second LBA 1370. This delivery process may be performed through a process in which the user directly selects a bundle through a UI provided by the second terminal 1350, or may be input to the second LBA 1370 through a push input from a remote server, or The second LBA 1370 may access the remote server and read the corresponding information.

Referring to FIG. 13, information of a bundle selected in step 13000 in step 13005 may be transmitted from the second LBA 1370 to the second SSP 1360. In this case, the information transmitted from the second LBA 1370 to the second SSP 1360 may include information for identifying the bundle selected in step 13000.

Referring to FIG. 13, in step 13010, the second SSP 1360 may delete the corresponding bundle. Also, the second SSP 1360 may generate a "certificate". In Figure 13, this certificate may be called recoveryRequest. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The recoveryRequest may include the "bundle identifier" of the corresponding bundle in 510.

- The recoveryRequest may include the "SSP identifier" of the second SSP at 540.

- The recoveryRequest may include information indicating that the second SSP has deleted the bundle in 550.

- The recoveryRequest may optionally include, in 520, a time when the second SSP deletes a bundle or a time when a certificate is created.

- The recoveryRequest may include the signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 13, in step 13015, the second SSP 1360 may transmit a recovery Request to the first SSP 1310. For example, the second SSP 1360 may transmit a recovery Request to the first SSP 1310 through the following process. That is, the second SSP 1360 transmits a recovery Request to the second LBA 1370 in response to step 13005, and the second LBA 1370 sends a recovery request to the first SSP 1310 through the first LBA 1320. I can deliver.

Referring to FIG. 13, in step 13020, the first SSP 1310 may verify the received recovery Request. This verification process may include checking the validity of the signature of the second SSP 1360 included in the recoveryRequest. In addition, this verification process may further include a process of checking the "bundle identifier" included in the recoveryRequest. In addition, the verification process may further include a process of checking the "SSP identifier" included in the recoveryRequest. In addition, the verification process may further include a process of confirming whether the command information included in the recoveryRequest deletes the bundle.

In addition, in step 13020, after completing the verification, the first SSP 1310 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the first SSP 1310 may convert the state of the bundle to the Disabled state.

Referring to FIG. 13, in step 13025, the first SSP 1310 may transmit a result (eg, success or failure) of the task performed in step 13020 to the first LBA 1320.

14 is a diagram illustrating another example of a procedure for making a bundle that has been discontinued to be used again.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 14, the first terminal 1400 includes a first LBA 1420 and a first SSP 1410, and the second terminal 1450 includes a second LBA 1470 and A second SSP 1460 may be included. As an example, the first terminal 1400 may be a terminal equipped with a first SSP 1410 and a first LBA 1420 for controlling the first SSP 1410, and the second terminal 1450 2 It may be a terminal in which the SSP 1460 is mounted and the second LBA 1470 for controlling the second SSP 1460 is installed.

A possible example when the state of the bundle is set to the "IN TRANSITION" state or the "SUSPENSION" state before the procedure disclosed in FIG. 14 is performed is as follows. For example, in the step in which the transmission of the bundle disclosed in FIG. 11 is finished, if step 11025 is performed but step 11045 is not performed, the state of the bundle in the first terminal 1400 is set to the "IN TRANSITION" state. There will be. As another example, if step 12025 is performed in the step in which the transmission of the bundle disclosed in FIG. 12 is completed, the state of the bundle in the first terminal 1400 will be set to the "IN TRANSITION" state or the "SUSPENSION" state. .

Referring to FIG. 14, information on a bundle for requesting to resume use may be transmitted to the second LBA 1470 in step 14000. This delivery process may be performed through a process in which the user directly selects a bundle through a UI provided by the second terminal 1450, or may be input to the second LBA 1470 through a push input from a remote server, or The second LBA 1470 may access the remote server and read the corresponding information.

Referring to FIG. 14, information of a bundle selected in step 14000 in step 14005 may be transmitted from the second LBA 1470 to the second SSP 1460. In this case, the information transmitted from the second LBA 1470 to the second SSP 1460 may include information for identifying the bundle selected in step 14000.

Referring to FIG. 14, in step 14010, the second SSP 1460 may set the state of a corresponding bundle to an “IN TRANSITION” state. In addition, the second SSP 1460 may generate a "certificate" related to a state change of a corresponding bundle. In Fig. 14, this certificate may be called recoveryRequest. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The recoveryRequest may include the "bundle identifier" of the corresponding bundle in 510.

- The recoveryRequest may include the "SSP identifier" of the second SSP at 540.

- The recoveryRequest may include information indicating that the second SSP has set the bundle state to the "IN TRANSITION" state in 550.

- The recoveryRequest may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.

- The recoveryRequest may include the signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 14, in step 14015, the second SSP 1460 may transmit a recovery Request to the first SSP 1410. For example, the second SSP 1460 may transmit a recovery Request to the first SSP 1410 through the following process. That is, the second SSP 1460 transmits a recovery Request to the second LBA 1470 in response to step 14005, and the second LBA 1470 sends a recovery request to the first SSP 1410 through the first LBA 1420. I can deliver.

Referring to FIG. 14, in step 14020, the first SSP 1410 may verify the received recovery Request. This verification process may include checking the validity of the signature of the second SSP 1460 included in the recoveryRequest. In addition, this verification process may further include a process of checking the "bundle identifier" included in the recoveryRequest. In addition, this verification process may further include a process of verifying the "SSP identifier" included in the recoveryRequest. In addition, the verification process may further include a process of confirming whether command information included in the recoveryRequest changes the state of the bundle to the "IN TRANSITION" state.

In addition, in step 14020, after completing the verification, the first SSP 1410 may change the state of the bundle to one of available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the first SSP 1410 may convert the state of the bundle to the Disabled state.

In addition, in step 14020, the first SSP 1410 may generate a "certificate". In Fig. 14, this certificate may be called recoveryResponse. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The recoveryResponse may include the "bundle identifier" of the corresponding bundle in 510.

- The recoveryResponse may include the "SSP identifier" of the first SSP in 540.

- The recoveryResponse may include information in 550 indicating that the first SSP has changed the state of the bundle to an available state.

- The recoveryResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.

- The recoveryResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Also, another example of a possible certificate configuration is as follows.

- The recoveryResponse may include the recoveryRequest received at 530. In this case, some information of the received recoveryRequest may be omitted if necessary. For example, the signature information of the second SSP included in the recoveryRequest may be omitted in some cases. In addition, for example, time information included in the recoveryRequest may be omitted in some cases.

- The recoveryResponse may include the "SSP identifier" of the first SSP in 540.

- The recoveryResponse may include information in 550 indicating that the first SSP has changed the state of the bundle to an available state.

- The recoveryResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.

- The recoveryResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Referring to FIG. 14, in step 14025, the first SSP 1410 may transmit a recoveryResponse to the second SSP 1460. For example, the first SSP 1410 may transmit a recoveryResponse to the second SSP 1460 through the first LBA 1420 and the second LBA 1470.

Referring to FIG. 14, in step 14030, the second SSP 1460 may verify the received recoveryResponse. This verification process may include checking the validity of the signature of the first SSP 1460 included in the recoveryResponse. In addition, the verification process may optionally further include a process of checking whether the "bundle identifier" included in the recoveryResponse matches the bundle identifier of the corresponding bundle. In addition, the verification process may optionally further include a process of checking whether the recoveryRequest included in the recoveryResponse matches the information transmitted by the user. In addition, this verification process may further include a process of verifying the "SSP identifier" included in the recoveryResponse. In addition, the verification process may further include a process of checking whether command information included in the recoveryResponse is correct command information.

Also, in step 14030, the second SSP 1460 may delete the bundle after completing the verification.

Referring to FIG. 14, in step 14035, the second SSP 1460 may transmit a result (eg, success or failure) of the task performed in step 14030 to the second LBA 1470.

15 is a diagram illustrating another example of a procedure for making a bundle that has been discontinued to be used again.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 15, the first terminal 1500 includes a first LBA 1520 and a first SSP 1510, and the second terminal 1550 is a second LBA 1570 and It may include a second SSP (1560). For example, the first terminal 1500 may be a terminal equipped with a first SSP 1510 and a first LBA 1520 for controlling the first SSP 1510, and the second terminal 1550 2 It may be a terminal in which the SSP 1560 is mounted and the second LBA 1570 for controlling the second SSP 1560 is installed.

A possible example when the state of the bundle is set to the "IN TRANSITION" state or the "SUSPENSION" state before the procedure disclosed in FIG. 15 is performed is as follows. For example, in the step in which the transmission of the bundle disclosed in FIG. 11 is finished, if step 11025 is performed but step 11045 is not performed, the state of the bundle in the first terminal 1500 is set to the "IN TRANSITION" state. There will be. As another example, if step 12025 is performed in the step in which the transmission of the bundle disclosed in FIG. 12 is completed, the state of the bundle in the first terminal 1500 will be set to the "IN TRANSITION" state or the "SUSPENSION" state. .

Referring to FIG. 15, in step 15000, information on a bundle requesting resume of use may be delivered to a second LBA. This delivery process may be performed through a process in which the user directly selects a bundle through a UI provided by the second terminal 1550, or may be input to the second LBA 1570 through a push input from a remote server, or The second LBA 1570 may access the remote server and read the corresponding information.

Referring to FIG. 15, information of a bundle selected in step 15000 in step 15005 may be transmitted from the second LBA 1570 to the second SSP 1560. In this case, the information transmitted from the second LBA 1570 to the second SSP 1560 may include information for identifying the bundle selected in step 15000.

Referring to FIG. 15, in step 15010, the second SSP 1560 may change the state of the corresponding bundle to “SUSPENSION”. In this case, although not shown in the drawing, the "SUSPENSION" state described above may be replaced with the "IN TRANSITION" state.

Also, the second SSP 1560 may generate a "certificate". In Fig. 15, this certificate may be called recoveryRequest. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The recoveryRequest may include the "bundle identifier" of the corresponding bundle in 510.

- The recoveryRequest may include the "SSP identifier" of the second SSP at 540.

- The recoveryRequest may include information indicating that the second SSP has changed the state of the bundle to "SUSPENSION" or "IN TRANSITION" in 550.

- The recoveryRequest may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.

- The recoveryRequest may include the signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 15, in step 15015, the second SSP 1560 may transmit a recovery Request to the first SSP 1510. For example, the second SSP 1560 may transmit a recovery Request to the first SSP 1510 through the following process. That is, the second SSP 1560 transmits a recovery Request to the second LBA 1570 in response of step 15005, and the second LBA 1570 sends a recovery request to the first SSP 1510 through the first LBA 1520. I can deliver.

Referring to FIG. 15, in step 15020, the first SSP 1510 may verify the received recovery Request. This verification process may include checking the validity of the signature of the second SSP 1560 included in the recoveryRequest. In addition, this verification process may further include a process of checking the "bundle identifier" included in the recoveryRequest. In addition, this verification process may further include a process of verifying the "SSP identifier" included in the recoveryRequest. In addition, the verification process may further include a process of checking whether command information included in the recoveryRequest correctly changes the state of the bundle.

In addition, in step 15020, after completing the verification, the first SSP 1510 may change the state of the bundle to one of available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the first SSP 1510 may change the state of the bundle to the Disabled state.

Referring to FIG. 15, in step 15025, a first SSP 1510 may transmit a result (eg, success or failure) of a task performed in step 15020 to a first LBA 1520.

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

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

According to various embodiments, the transmission/reception unit 1610 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 1610 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 1610, and components of the transmission/reception unit 1610 are not limited to the RF transmitter and the RF receiver. In addition, the transmission/reception unit 1610 may receive a signal through a wireless channel, output it to the at least one processor 1620, and transmit a signal output from the at least one processor 1620 through a wireless channel.

According to various embodiments, the transmission/reception unit 1610 includes SSP information included in another terminal from a transmission/reception unit of another terminal or an external server, authentication information capable of authenticating other terminals, authentication information capable of authenticating itself, and bundle. It is possible to transmit or receive a movement code, a bundle movement setting, a bundle, and various certificates described in FIGS. 10 to 15.

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

Meanwhile, the SSP 1630 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 1630 may determine whether to transmit a specific bundle by checking the bundle movement setting. In addition, it is possible to check whether the bundle movement setting is checked and whether a corresponding bundle can be used repeatedly in a plurality of terminals.

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 1620. Also, the SSP 1630 may manage a bundle.

In addition, according to various embodiments, the SSP 1630 may generate various types of certificates described in FIGS. 10 to 15 and verify the received certificates.

Further, according to various embodiments, the SSP 1630 may change the state of the bundle based on the contents of the received certificate as described in FIGS. 10 to 15.

Further, according to various embodiments, the SSP 1630 may operate under the control of the processor 1620. Alternatively, the SSP 1630 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 1630 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. Also, the processor 1620 may perform various operations using various programs, contents, data, and the like stored in the memory.

FIG. 17 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6. In more detail, FIG. 17 is another example of a diagram illustrating a process of installing a bundle in a terminal and a process of setting a bundle state after a bundle is transmitted according to an embodiment of the present disclosure.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 17, the first terminal 1700 includes a first LBA 1720 and a first SSP 1710, and the second terminal 1750 includes a second LBA 1770 and It may include a second SSP (1760). For example, the first terminal 1700 may be a terminal equipped with a first SSP 1710 and a first LBA 1720 for controlling the first SSP 1710, and the second terminal 1750 2 It may be a terminal in which the SSP 1760 is mounted and the second LBA 1770 for controlling the second SSP 1760 is installed.

One. Bundle installation

Referring to FIG. 17, in step 17000, the second LBA 1770 and the second SSP 1760 may cooperate with each other to install a bundle in the second terminal 1750. For a detailed description of this, refer to the "bundle installation" process of FIG. 9.

2. Check for redundancy

In addition, although not shown in the drawings, the second LBA 1770 and/or the second SSP 1760 may selectively determine whether the corresponding bundle can be used repeatedly in a plurality of terminals. Refer to the procedure "Checking whether duplicates can be used" in 9.

3. Bundle state setting

If the bundle is determined to be a bundle that cannot be used repeatedly in a plurality of terminals, the bundle state is additionally set as follows. Alternatively, even when the second LBA 1770 and/or the second SSP 1760 does not determine whether the corresponding bundle is used repeatedly, according to the implementation of the second LBA 1770 and/or the second SSP 1760 The process of additionally setting the bundle state may be performed as follows.

Referring to FIG. 17, in step 17005, the second SSP 1760 may set the state of a corresponding bundle to “IN TRANSITION”. "IN TRANSITION" is a state in which the bundle has been successfully installed but cannot be used (also, such as'a request from another terminal (eg, a request made by sending a finalizationResponse or recoveryRequest)' and/or'a request from an external server' It means a state that can be changed to an available state (Disabled, Enable, Active state) only by an additional operation.

Referring to FIG. 17, in step 17010, the second LBA 1770 may request a “certificate” from the second SSP 1760.

Referring to FIG. 17, in step 17015, the second SSP 1760 may generate a “certificate”. In Fig. 17, this certificate may be called finalizationRequest. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The finalizationRequest may include a "bundle identifier" of a corresponding bundle in 510.

- The finalizationRequest may include the "SSP identifier" of the second SSP in 540.

- The finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 550.

- The finalizationRequest may optionally include, in 520, a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created. Alternatively, information of a certificate to be used for later electronic signature may be optionally further included.

- The finalizationRequest may include signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 17, in step 17020, the second SSP 1760 may transmit a finalization Request to the first SSP 1710. For example, the second SSP 1760 may transmit a finalizationRequest to the first SSP 1710 through the following process. That is, the second SSP 1760 may transmit a finalizationRequest to the second LBA 1770 in the response of step 17010, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1720.

Referring to FIG. 17, in step 17025, the first SSP 1710 may verify the received finalizationRequest. This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP. In addition, the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.

Also, in step 17025, the first SSP 1710 may delete the bundle.

In addition, in step 17025, the first SSP 1710 may generate a "certificate". In Fig. 17, this certificate may be called finalizationResponse. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- The finalizationResponse may include a "bundle identifier" of a corresponding bundle in 510.

- The finalizationResponse may include the "SSP identifier" of the first SSP in 540.

- The finalizationResponse may include information indicating that the first SSP has deleted the bundle in 550.

- The finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 520. Alternatively, information of a certificate to be used for later electronic signature may be optionally further included.

- The finalizationResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

In addition, one example with different possible certificate configurations is as follows.

- The finalizationResponse may include some and/or all data of the finalizationRequest in 530.

- The finalizationResponse may include the "SSP identifier" of the first SSP in 540.

- The finalizationResponse may include information indicating that the first SSP has deleted the bundle in 550.

- The finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 520. Alternatively, information of a certificate to be used for later electronic signature may be optionally further included.

- The finalizationResponse may include signature information of the first SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Referring to FIG. 17, in step 17030, a first SSP 1710 may transmit a finalizationResponse to a second SSP 1760. For example, the first SSP 1710 may transmit a finalizationResponse to the second SSP 1760 through the first LBA 1720 and the second LBA 1770.

Referring to FIG. 17, in step 17035, the second SSP 1760 may verify the received finalizationResponse. This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse. In addition, the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle. In addition, the verification process may optionally further include a process of checking whether some and/or all information of the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse. In addition, the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse. In addition, the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.

In addition, in step 17035, the second SSP 1760 may change the state of the bundle to one of available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the second SSP 1760 may convert the state of the bundle to the Disabled state.

In addition, in step 17035, the second SSP 1760 may generate a "certificate". In Fig. 17, this certificate may be referred to as spblAttestation. The structure of this certificate may follow the structure disclosed in FIG. 5.

At this time, one example of possible certificate configuration is as follows.

- spblAttestation may include the "bundle separator" of the corresponding bundle in 510.

- spblAttestation may include “SSP identifier” of the second SSP in 540.

- The spblAttestation may include information indicating that the second SSP has changed the state of the bundle to an available state in 550.

- The spblAttestation may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created. Alternatively, information of a certificate to be used for later electronic signature may be optionally further included.

- spblAttestation may include the signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Also, another example of a possible certificate configuration is as follows.

- spblAttestation may include some and/or all data of'finalizationRequest and/or finalizationResponse' in 530.

- spblAttestation may include “SSP identifier” of the second SSP in 540.

- The spblAttestation may include information indicating that the second SSP has changed the state of the bundle to an available state in 550.

- The spblAttestation may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created. Alternatively, information of a certificate to be used for later electronic signature may be optionally further included.

- spblAttestation may include the signature information of the second SSP in 560. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 17, in step 17040, the second SSP 1760 may transmit spblAttestation to the first SSP 1710. For example, the second SSP 1760 may transmit spblAttestation to the first SSP 1710 through the second LBA 1770 and the first LBA 1720.

Referring to FIG. 17, in step 17045, the first SSP 1710 may verify the received spblAttestation. This verification process may include checking the validity of the signature of the second SSP included in the spblAttestation. In addition, the verification process may further include a process of checking whether the "bundle separator" included in spblAttestation matches the bundle identifier of the corresponding bundle. In addition, the verification process may optionally further include a process of checking whether some and/or all information of the finalizationRequest and/or finalizationResponse included in the spblAttestation matches the information transmitted by the spblAttestation. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the spblAttestation is a correct identifier of the second SSP. In addition, the verification process may further include a process of confirming whether command information included in spblAttestation changes the state of the bundle to a usable state.

Also, in step 17045, the first SSP 1710 may delete the finalizationResponse.

In step 17035, the step of generating spblAttestation and/or step 17040 and/or step 17045 may be omitted as necessary.

When the certificate transmission fails in steps 17020 and/or 17030 and/or 17040, the corresponding certificate may be retransmitted to the counterpart device.

In this case, retransmission may be attempted as many times as a preset maximum number of retransmissions. Or, it may be repeated until it is confirmed that the corresponding certificate has been transmitted to the other terminal. Alternatively, depending on the implementation of the terminal, it may be retransmitted repeatedly until the corresponding certificate is deleted. For example, in the case of the finalizationResponse, until it is deleted in step 17045, the first terminal may repeatedly attempt to retransmit the finalizationResponse.

If the connection between the two devices is disconnected when attempting to retransmit, the two devices can establish a new connection and transmit and receive the corresponding certificate. At this time, the two terminals can select and/or verify the target of the newly established connection using the records that have been transmitted/received while communicating in the past, and can determine what data to transmit and receive with the newly established counterpart. Validity and/or content of data received from the terminal can be verified.

At this time, retransmission may be automatically initiated by an operation inside the terminal, may be initiated by a request from an external server, or may be initiated by a user input.

18 is a diagram illustrating a configuration of a “certificate (Attestation)” according to some embodiments of the present disclosure.

According to various embodiments, the certificate may optionally include “Attestation Info” (1810). For various examples of data included in the certificate information, reference will be made to the description of FIGS. 22 to 27 to be described later.

According to various embodiments, the certificate may optionally further include "Issuer ID of the subject that issued the certificate" (1830). Various examples of the subject issuing the certificate will be referred to the description of FIGS. 22 to 27 to be described later.

According to various embodiments, the certificate may optionally further include “information on an operation performed by the certificate issuer (Command)” (1850). Various examples of operations performed by the certificate issuer will be described with reference to the descriptions of FIGS. 22 to 27 to be described later.

According to various embodiments, the certificate may optionally further include other data other than the above-described information (1870). For various examples of other data that may be included in the certificate, reference will be made to the description of FIGS. 22 to 27 which will be described later.

According to various embodiments, the certificate may include electronic signature data for the above-described information (1890). This signature data may be an electronic signature generated by the certificate issuer's signature certificate.

19 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.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 19, the first terminal 1900 includes a first LBA 1920 and a first SSP 1910, and the second terminal 1950 includes a second LBA 1970 and It may include a second SSP (1960). For example, the first terminal 1900 may be a terminal equipped with a first SSP 1910 and a first LBA 1920 for controlling the first SSP 1910, and the second terminal 1950 2 It may be a terminal in which the SSP (1960) is mounted and the second LBA (1970) for controlling the second SSP (1960) is installed.

Referring to FIG. 19, in step 19000, the first SSP 1910 of the first terminal 1900, the first LBA 1920, and the second LBA 1970 of the second terminal 1950 are prepared for bundle transmission. You can perform a procedure (a procedure for preparing to send a bundle). For a more detailed description of the above procedure, reference will be made to the detailed description of FIG. 20 to be described later.

Referring to FIG. 19, in step 19005, a procedure for transmitting a bundle from a first terminal 1900 to a second terminal 1950 (a bundle transmission procedure) may be performed. For a more detailed description of the above procedure, reference will be made to the detailed description of FIG. 21 to be described later.

Referring to FIG. 19, in step 19010, a first terminal 1900 and a second terminal 1960 may perform a procedure for installing a transmitted bundle and a procedure for setting a state of a bundle (a procedure for finishing a bundle transmission). For a detailed description of the above procedure, reference will be made to detailed descriptions of FIGS. 22, 24, and 26 to be described later.

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

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 20, the first terminal 2000 includes a first LBA 2020 and a first SSP 2010, and the second terminal 2050 includes a second LBA 2070 and It may include a second SSP (2060). As an example, the first terminal 2000 may be a terminal equipped with a first SSP 2010 and a first LBA 2020 for controlling the first SSP 2010, and the second terminal 2050 2 It may be a terminal in which the SSP 2060 is mounted and the second LBA 2070 for controlling the second SSP 2060 is installed.

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

According to various embodiments, the first terminal 2000 is associated with a corresponding bundle and provides 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). You may have it.

According to various embodiments, the first terminal 2000 may be linked with a corresponding bundle to hold a'bundle movement setting'. The bundle movement setting may selectively include information related to whether a corresponding bundle can be transmitted between devices.

In addition, the bundle movement setting may optionally further include “registration setting” for a process of registering the transmission result between devices of the corresponding bundle in the server. Various examples of possible “registration settings” are as follows.

- Whether notification is required: Setting whether to notify the server of the bundle transmission result between devices

- Whether a pre-notification is required: After the bundle is transmitted from one device to a new device, and before being used by a new device, whether this transmission history should be notified to the server, or before this transmission history is notified to the server. Setting whether or not it can be used on the device

- Whether to require encryption of notification contents: Setting whether data transmitted during the notification process needs to be encrypted so that only the notifying server and the notifying SSP can view the contents.

The "registration setting" may be set by a service provider, may be set by a bundle management server, or may be set by cooperation between the service provider and the bundle management server. In addition, this bundle movement setting may be included as data inside the bundle, may be included in the metadata of the bundle, or may exist as independent data. In addition, the bundle movement setting may include an electronic signature of a service provider and/or a bundle management server.

Referring to FIG. 20, information on a bundle to be transmitted between devices may be transmitted to a first LBA 2020 in step 20000. This delivery process may be performed, for example, through a process in which a user directly selects a bundle through a UI provided by the first terminal 2000, as shown in FIG. 20, or through a push input from a remote server. It may be input to (2020), or the first LBA (2020) may access the remote server and read the corresponding information.

Referring to FIG. 20, information related to a bundle selected through operation 20000 in operation 20005 may be transferred from the first LBA 2020 to the first SSP 2010. For example, as illustrated in FIG. 20, information related to the selected bundle may be transmitted from the first LBA 2020 to the first SSP 2010 through the Select SPB command. In this case, the information transmitted from the first LBA 2020 to the first SSP 2010 may include information for identifying the bundle selected in step 20000.

Referring to FIG. 20, in step 20010, a first SSP 2010 may check whether a bundle requested to be transmitted can be transmitted between devices. This process may be performed by first identifying a bundle requested to be transmitted based on the information received in step 20005, and confirming a'bundle movement setting' associated with the bundle.

Also, in step 20010, the first SSP 2010 may selectively set a'bundle movement code'. The'bundle movement code' is a code used to refer to the corresponding bundle in the process of transmitting the bundle between devices and must be a value that can identify the corresponding bundle. The first SSP 2010 may bind the aforementioned'bundle movement code' and information of a bundle to be transmitted.

Referring to FIG. 20, a response result for step 20005 in step 20015 may be transmitted from the first SSP 2010 to the first LBA 2020. For example, as shown in FIG. 20, a response to the Select SPB command may be transmitted from the first SPB 2010 to the first LBA 2020 through the Select SPB response. This response value may include the'bundle movement code' described in step 20010.

Referring to FIG. 20, information necessary for inter-device bundle transmission in step 20020 may be transferred from the first LBA 2020 of the first terminal 2000 to the second LBA 2070 of the second terminal 2050. . In this case, information transmitted from the first LBA 2020 to the second LBA 2070 may include a'bundle movement code'. In addition, the information transmitted from the first LBA 2020 to the second LBA 2070 includes information necessary for connection established between the first LBA 720 and the second LBA 2070 in the next step 20025. Optionally, it may further include.

Information transmitted from the first LBA 2020 to the second LBA 2070 through the above-described step 20020 may be transmitted in various ways. For example, the first LBA may provide information to be transmitted to the second LBA to the user through the UI of the first terminal 2000, and the user can provide the received information by using the UI of the second terminal 2050. Can be entered into the second LBA. Alternatively, the first LBA creates the information to be transmitted to the second LBA in the form of an image (for example, a QR code) and displays it on the screen of the first terminal, and the user scans this image using the second terminal 2050. By doing so, information can be delivered to the second LBA 2070. However, a method of transferring information from the first LBA 2020 to the second LBA 2070 is not limited to the above methods.

Referring to FIG. 20, a connection may be established (or established) between a first LBA 2020 and a second LBA 2070 in step 20025. If information necessary for connection is transmitted in step 20020, the first LBA 2020 and the second LBA 2070 may establish a connection using this information. The connection between the first LBA 2020 and the second LBA 2070 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 LBA 2020 and the second LBA 2070.

Referring to FIG. 20, step 20025 is shown as the last step, but this step is independent of the other steps described above, namely, steps 20000, 20005, 20010, 20015, and 20020, and is dependent on other steps and sequences. Can be done without For example, step 20025 may be performed between steps 20015 and 20020, and in this case, information transmitted from the first LBA 2020 to the second LBA 2 2070 in step 20020 is through the connection established in step 20025. It can also be transmitted.

FIG. 21 is a diagram showing a detailed procedure for a procedure in which a bundle is transmitted among the procedures presented in FIG. 19. In more detail, FIG. 21 is a diagram illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure. In the present disclosure, the procedure of FIG. 21 may be referred to as a bundle transmission procedure.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 21, the first terminal 2100 includes a first LBA 2120 and a first SSP 2110, and the second terminal 2150 includes a second LBA 2170 and It may include a second SSP (2160). As an example, the first terminal 2100 may be a terminal equipped with a first SSP 2110 and a first LBA 2120 for controlling the first SSP 2110, and the second terminal 2150 2 It may be a terminal in which the SSP 2160 is mounted and the second LBA 2170 for controlling the second SSP 2160 is installed.

Referring to FIG. 21, in step 21000, the second LBA 2170 may request “SSP information (SspInfo)” from the second SSP 2 2160. In step 21000, when the second LBA 2170 requests "SSP information (SspInfo)" from the second SSP 2160, the second LBA 2170 indicates that the bundle movement between devices will be performed to the second SSP 2160. I can tell you.

In addition, step 21000 may be automatically performed immediately following the process illustrated in FIG. 21, or may be performed after receiving an external input. In this case, the'external input' may be performed through a process of selecting a bundle to be directly transmitted by the user through a UI provided by the second terminal 2150, or the second LBA 2170 through a push input from a remote server. Alternatively, the second LBA 2170 may access the remote server and read the corresponding information.

Referring to FIG. 21, in step 21005, the second SSP 2160 may generate its own “SSP information”. The "SSP information" may include information on the second SSP 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 2160 must go through before receiving the bundle. This "certificate negotiation information" may include certificate information (SenderSpblVerification) that the second SSP 2160 can use to verify another SSP and certificate information (ReceiverSpblVerification) that can be used by another SSP to verify itself. have. In addition, the "certificate negotiation information" may optionally further include a list of key agreement algorithms supported by the second SSP 2160, and may optionally further include a list of encryption algorithms supported by the second SSP 2160. I can. In addition, the "SSP information" may optionally further include SSP version information including at least one of version information of a primary platform included in the second SSP 2160 and version information of a standard standard supported by the loader.

Referring to FIG. 21, in step 21010, the second SSP 2160 may transmit the "SSP information" generated in step 21005 to the first SSP 2110 through the second LBA 2170 and the first LBA 2120. have.

According to steps 21000 and 21010 described above, the second LBA 2170 requests "SSP information (SspInfo)" from the second SSP 2160, and the second SSP 2160 requests its "SSP information". After creation, the second SSP 2160 may transmit “SSP information” to the first SSP 2110 through the second LBA 2170 and the first LBA 2120. However, depending on the embodiment, the process of transmitting "SSP information" from the second terminal 2150 to the first terminal 2100 may be as follows. For example, the second LBA 2170 may generate “SSP information” by itself and then transmit the “SSP information” to the first SSP 2110 through the first LBA 2120.

Referring to FIG. 21, in step 21015, the first SSP 2110 checks the received "SSP information" and generates "first terminal authentication information (Device1.Auth)" that can authenticate itself based on this information. can do. A more detailed procedure for this process is as follows.

The first SSP 2110 may check certificate information capable of verifying itself using the received "SenderSpblVerification" and select at least one key agreement certificate (ssp1.Cert.KA). Alternatively, the first SSP 2110 uses the received "list of key agreement algorithms supported by the second SSP 2160" to be used for key agreement, and the asymmetric encryption key pair public key "ssp1.ePK.KA" After creating "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 2110 may check certificate information capable of verifying itself using the received "SenderSpblVerification" and further select at least one signature certificate (ssp1.Cert.DS).

In addition, the first SSP 2110 may select at least one certificate information of the second SSP 2160 to be verified using the received "ReceiverSpblVerification" and then set the corresponding information to "CiPkIdToBeUsed".

In addition, the first SSP 2110 may select at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 2160" and then set corresponding information to "CryptoToBeUsed". .

In addition, the first SSP 2110 checks the list of the received "version information of the primary platform included in the second SSP 2160 and the standard standard supported by the loader", and among them, the version of the standard standard that it also supports. You can check if it exists.

The “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 optionally further include "ssp1.Cert.DS" described above. In addition, the "first terminal authentication information (Device1.Auth)" may optionally 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. I can.

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

Referring to FIG. 21, in step 21020, the first SSP 2110 passes the first LBA 2120 to the second LBA 2170 to transmit “first terminal authentication information (Device1.Auth)” generated in step 21015. I can.

Referring to FIG. 21, in step 21025, the second LBA 2170 may transmit “first terminal authentication information (Device1.Auth)” to the second SSP 2160. In addition, the second LBA 2170 may further transmit a "bundle movement code" to the second SSP 2160.

Referring to FIG. 21, in step 21030, the second SSP 2160 may verify the received “first terminal authentication information (Device1.Auth)”. If the second SSP 2160 receives "ssp1.Cert.KA", it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2160 receives "ssp1.ePK.KA" and a digital signature for it, it first checks the validity of ssp1.Cert.DS and then checks the digital signature using this certificate. You can check the integrity of the public key ssp1.ePK.KA. In addition, the second SSP 2160 may select at least one signing certificate (ssp2.Cert.DS) capable of verifying itself by checking the received "CiPkIdToBeUsed".

In addition, although not shown in the drawing, in step 21030, the second SSP 2160 uses a public key "ssp2.ePK.KA" and a private key "ssp2.eSK." as an asymmetric encryption key pair to be used for key agreement. After creating "KA", you can select the public key (ssp2.ePK.KA) from this key pair. In addition, the second SSP 2160 selects one of the public key for key agreement or ssp1.ePK.KA included in ssp1.Cert.KA, and then uses this value and ssp2.eSK.KA to communicate with the terminal 1 in the future. Session key ShKey01 to be used for encryption during communication can be generated. ShKey01 must be a session key for the encryption algorithm included in the received "CryptoToBeUsed".

In addition, in step 21030, the second SSP 2160 may generate “second terminal authentication information (Device2.Auth)” capable of authenticating itself. 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 the current session generated by the SSP 2 2160. 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 an SSP identifier of the second SSP 2160. In addition, the "second terminal authentication information (Device2.Auth)" may optionally 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. I can.

At this time, some or all of the "second terminal authentication information (Device2.Auth)" mentioned above may be digitally signed so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information, and this digital signature Data may be added as part of the "second 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.

Referring to FIG. 21, in step 21035, the second SSP 2160 passes through the second LBA 2170 and the first LBA 2120 to the first SSP 2110 generated in step 21030. Device2.Auth)" can be delivered. In this case, a "bundle movement code" may be selectively further transmitted.

Referring to FIG. 21, in step 21040, the first SSP 2110 may verify the received “second terminal authentication information (Device2.Auth)”. The first SSP 2110 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp2.Cert.DS". In addition, the first SSP 2110 checks whether the received bundle family identifier (SPB Family ID) and/or the bundle family manager identifier (SPB Family Custodian Object ID) is a value set correctly in association with the bundle to be transmitted. I can. In addition, the first SSP 2110 may store the received transaction ID and/or the SSP identifier of the second SSP 2160. In addition, the first SSP 2110 may bind the received transaction ID or the SSP identifier of the second SSP 2160 with a currently ongoing session or a bundle to be transmitted.

In this process, if encrypted data is included in the "second terminal authentication information (Device2.Auth)", the first SSP 2110 is transmitted to the received ssp2.ePK.KA and its own ssp1.Cert.KA. A session key ShKey01 can be generated using a private key corresponding to the included public key for key agreement or ssp1.eSK.KA, and the encrypted data can be decrypted using this session key, and then the verification process can be performed. In addition, in this process, if a digital signature is included in the "second terminal authentication information (Device2.Auth)", the first SSP 2110 uses the "ssp2.Cert.DS" to determine the validity of the digital signature received. Can be verified.

In addition, in step 21040, although not shown in FIG. 21, the first SSP 2110 includes an asymmetric encryption key pair public key "ssp1.bundle.ePK.KA" and a secret key "ssp1. bundle.eSK.KA" can be created. At this time, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" may be set to the same value as the previously created "ssp1.ePK.KA and ssp1.eSK.KA". Alternatively, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" will be set to the same value as the public key included in the previously used "ssp1.Cert.KA and the corresponding private key". May be. Also, the first SSP 2110 may generate the session key ShKey02 using ssp1.bundle.eSK.KA and ssp2.ePK.KA. If ssp1.eSK.KA or the private key corresponding to the public key included in ssp1.Cert.Ka is reused for ssp1.bundle.eSK.KA, the value of the session key ShKey02 is also of the previously generated ShKey01. Can be set to a value.

In addition, in step 21040, the first SSP 2110 may configure a bundle to be transmitted to the second terminal 2150 and/or metadata associated with the bundle. In this case, the first SSP 2110 may identify a bundle to be transmitted by using the received "bundle movement code". In addition, "ssp1.Cert.DS" may be included in the bundle to be configured. In addition, the bundle to be configured may further include "ssp1.bundle.ePK.KA". In addition, the bundle to be configured may further include a transaction ID identifying a corresponding session. In addition, the bundle to be configured may optionally 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 to-be-transmitted bundle. According to various embodiments, a "bundle movement setting" may be included in the bundle (or metadata associated with the bundle) configured in step 21040.

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

Referring to FIG. 21, in step 21045, a first SSP 2110 may transmit a bundle generated (configured) in step 21040 to a second LBA 2170 via a first LBA 2120. In this case, metadata associated with the transmitted bundle may be selectively further transmitted. In addition, a "bundle movement setting" associated with the transmitted bundle may be further transmitted. For example, the “bundle movement setting” may not be included in the bundle or metadata, but may be transmitted in a separate format (eg, a message).

FIG. 22 is a diagram illustrating a detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.

22 shows the transmission details between devices of the bundle

- There is no need to be pre-notified

- Which does not require or does not require encryption of the content of the notice.

In some cases, this may be a procedure that applies.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 22, the first terminal 2200 includes a first LBA 2220 and a first SSP 2210, and the second terminal 2250 includes a second LBA 2270 and A second SSP 2260 may be included. For example, the first terminal 2200 may be a terminal equipped with a first SSP 2210 and a first LBA 2220 for controlling the first SSP 2210, and the second terminal 2250 2 It may be a terminal in which the SSP 2260 is mounted and the second LBA 2270 for controlling the second SSP 2260 is installed.

Referring to FIG. 22, the following procedures may be performed in step 22000.

One. Bundle installation

Referring to FIG. 22, in step 22000, the second LBA 2270 and the second SSP 2260 may cooperate with each other to install a bundle in the second terminal 2250. In this process, the following procedures can be performed together. If metadata is transmitted, the second LBA 2270 or the second SSP 2260 may verify content included in the metadata. If "bundle movement setting" is transmitted, the second LBA 2270 may transmit the information to the second SSP 2260. If a transaction ID has been transmitted, the second LBA 2270 or the second SSP 2260 may check whether the transaction ID is the same as the transaction ID used in the current session. If 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 2270 or the second SSP 2260 is It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS is transmitted, the second SSP 2260 may verify the validity of this certificate to authenticate the first SSP 2210. If the transmitted data contains encrypted data, the second SSP 2260 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, verification can be performed. If the received data includes a digital signature, the second SSP 2260 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.

2. Check “Registration Settings”

In addition, although not shown in the drawing, the 2nd LBA 2270 and/or the 2nd SSP 2260 uses the "registration setting" of the corresponding bundle to'whether notification is required' and/or'whether or not pre-announcement is required' and/or You can check'whether the notification contents need to be encrypted.' This process is part of step 22000 and can be performed independently of other procedures in step 22000 and in any order. Alternatively, after step 22000, before step 22035 is completed, it may be performed at a moment when judgment is required. A procedure to be described later in this drawing may be a procedure applied when, as a result of confirming the “registration setting”, the transmission details between devices of the bundle do not need to be announced.

Referring to FIG. 22, in step 22005, the second SSP 2260 may set the state of a corresponding bundle to “IN TRANSITION”. "IN TRANSITION" is a state in which the bundle has been successfully installed but is not yet available (also, additional operations such as'an additional operation to be described later in this drawing' and/or'a request from an external server (although not described in this disclosure)') It means a state that can be changed to an available state (Disabled, Enable, Active state) only by.

Referring to FIG. 22, in step 22010, the second LBA 2270 may request a “certificate” from the second SSP 2260.

Referring to FIG. 22, in step 22015, the second SSP 2260 may generate a “certificate”. In Fig. 22, this certificate may be called finalizationRequest. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The finalizationRequest may include a "bundle identifier" of a corresponding bundle in 1810 of FIG. 18.

- The finalizationRequest may include the "SSP identifier" of the second SSP in 1830 of FIG. 18.

- The finalizationRequest may include information indicating that the second SSP has set the state of the bundle to the “IN TRANSITION” state in 1850 of FIG. 18.

- The finalizationRequest may optionally include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- The finalizationRequest may include signature information of the second SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 22, in operation 22020, the second SSP 2260 may transmit a finalization Request to the first SSP 2210. For example, the second SSP 2260 may transmit a finalizationRequest to the first SSP 2210 through the following process. That is, the second SSP 2260 transmits a finalization Request to the second LBA 2270 in response to step 22010, and the second LBA 2270 sends a finalization request to the first SSP 2210 through the first LBA 2220. I can deliver.

Referring to FIG. 22, in step 22025, a first SSP 2210 may verify a received finalizationRequest. This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP. In addition, the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.

In addition, in step 22025, the first SSP 2210 may delete the bundle after completing the verification.

In addition, in step 22025, the first SSP 2210 may generate a "certificate". In Fig. 22, this certificate may be called finalizationResponse. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The finalizationResponse may include a "bundle identifier" of a corresponding bundle in 1810 of FIG. 18. Alternatively, it may include some and/or all data of the finalizationRequest received in the previous step.

- The finalizationResponse may include “SSP identifier” of the first SSP in 1830 of FIG. 18.

- The finalizationResponse may include information indicating that the first SSP has deleted the bundle in 1850 of FIG. 18.

- The finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- The finalizationResponse may include signature information of the first SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Referring to FIG. 22, in operation 22030, a first SSP 2210 may transmit a finalizationResponse to a second SSP 2260. For example, the first SSP 2210 may transmit a finalizationResponse to the second SSP 2260 through the first LBA 2220 and the second LBA 2270.

Referring to FIG. 22, in step 22035, the second SSP 2260 may verify the received finalizationResponse. This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse. In addition, the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle. In addition, this verification process may include a process of checking whether some or all of the data of the finalizationRequest included in the finalizationResponse matches the information transmitted by the user. In addition, the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse. In addition, the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.

In addition, in step 22035, the second SSP 2260 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification. For example, as shown in the drawing, the second SSP 2260 may convert the bundle state to the Disabled state.

Also, in step 22035, the second SSP 2260 may generate a "certificate". In FIG. 22, this certificate may be referred to as spblAttestation. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The spblAttestation may include a "bundle separator" of a corresponding bundle in 1810 of FIG. 18. Alternatively, some and/or all data of the finalizationRequest and/or finalizationResponse may be included.

- spblAttestation may include the “SSP identifier” of the second SSP in 1830 of FIG. 18.

- The spblAttestation may include information indicating that the second SSP has changed the bundle to one of the usable states in 1850 of FIG. 18.

- The spblAttestation may optionally include a time when the second SSP changes the state of the bundle to one of the usable states or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- spblAttestation may include signature information of the second SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

In addition, in step 22035, the second SSP 2260 may generate its own "selected SSP information (sspInforSelected)". The "selected SSP information" may include information on the second SSP that must be provided to notify the server of the bundle transmission result between devices.

At this time, the "selected SSP information" may include information for a certificate negotiation process (certificate negotiation information). This "Certificate Negotiation Information"

- Certificate information that the second SSP 2260 can use to verify the server (spbmVerification)

- Certificate information that the server can use to verify the first SSP (2210) (SenderSpblVerification)

- Certificate information that the server can use to verify the second SSP 2260 (ReceiverSpblVerification)

It may optionally include information such as. In addition, the "certificate negotiation information" may optionally further include a list of key agreement algorithms supported by the second SSP 2260, and may optionally further include a list of encryption algorithms supported by the second SSP 2260. I can.

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

Referring to FIG. 22, in step 22040, the second SSP 2260 may transmit a result (eg, success or failure) of the task performed in step 22035 to the second LBA 2270. In addition, “selected SSP information” generated in step 22035 may be transmitted together.

The process of generating the “selected SSP information” in step 22035 and the process of transmitting the “selected SSP information” in step 22040 may be omitted.

23 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 22.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 23, the second terminal 2350 may include a second LBA 2370 and a second SSP 2360. For example, the second terminal 2350 may be a terminal equipped with a second SSP 2360 and a second LBA 2370 for controlling the second SSP 2360.

In addition, according to various embodiments, the server 2300 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 sometimes used to refer to the server 2300, but as described above, the type of server is not limited to SPBM.

Referring to FIG. 23, in step 23000, a Transport Layer Security (TLS) connection may be established between the SPBM 2300 and the LBA 2370. In this drawing, although it is described that step 23000 is performed before steps 23005 to 23015, step 23000 may be performed independently from steps 23005 to 23015 before step 23020 is performed. For example, step 23000 may be performed between steps 23015 and 23020.

Referring to FIG. 23, in step 23005, the second LBA 2370 may request “selected SSP information (SspInfoSelected)” from the second SSP 2 2360. In this case, step 23005 may be performed automatically or may be performed after receiving an external input. In this case, the'external input' may be given from a user through a UI provided by the second terminal 2350 or may be given to the second terminal 2350 through a push input from a remote server.

Referring to FIG. 23, in step 23010, the second SSP 2360 may generate its own “selected SSP information”. For a description of “selected SSP information”, refer to the description described in FIG. 22.

Referring to FIG. 23, in step 23015, the second SSP 2360 may transmit “selected SSP information” generated in step 23010 to the second LBA 2370.

Steps 23005 to 23015 may not be selectively performed.

Referring to FIG. 23, in step 23020, the second LBA 2370 may transmit “selected SSP information” to the server 2300. If the second LBA 2370 receives “selected SSP information” through steps 22035 to 22040 of FIG. 22, or receives “selected SSP information” through steps 23005 to 23015 of FIG. 23, the second LBA ( 2370) may transmit the received “selected SSP information” to the server 2300. If the second LBA 2370 does not receive “selected SSP information”, the second LBA 2370 may generate “selected SSP information” and transmit it to the server 2300.

Referring to FIG. 23, in step 23025, the server 2300 may check the received “selected SSP information” and generate “server authentication information (SPBM.Auth)” capable of authenticating itself based on this information. . A more detailed procedure for this process is as follows.

The server 2300 may check certificate information capable of verifying itself using the received "spbmVerification" and select at least one key agreement certificate (spbm.Cert.KA). Alternatively, the server 2300 uses the received "list of key agreement algorithms supported by the second SSP 2360" to use the asymmetric encryption key pair public key "spbm.ePK.KA" to be used for key agreement. After creating the private key "spbm.eSK.KA", you can select the public key (spbm.ePK.KA) from this key pair. In addition, the server 2300 may check certificate information capable of verifying itself using the received "spbmVerification" and further select at least one signing certificate (spbm.Cert.DS).

In addition, the server 2300 may check whether the certificate information of the first SSP 2210 to be verified by using the received "SenderSpblVerification" is verifiable by itself. This process may not be selectively performed.

In addition, the server 2300 may check whether the certificate information of the second SSP 2360 to be verified by using the received “ReceiverSpblVerification” is verifiable by itself. Alternatively, after selecting at least one certificate information of the second SSP 2360 that can be verified by using “ReceiverSpblVerification”, the corresponding information may be set as “CiPkIdToBeUsed”.

In addition, the server 2300 may select at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 2360" and then set corresponding information to "CryptoToBeUsed".

In addition, the server 2300 checks the list of the received "version information of the primary platform included in the second SSP 2360 and the standard standard supported by the loader", and among them, there is a version of the standard standard that it also supports. You can check whether it is.

"Server authentication information (SPBM.Auth)" may include at least one of "spbm.Cert.KA", "spbm.ePK.KA", "CiPkIdToBeUsed", and "CryptoToBeUsed" described above. In addition, the "server authentication information (SPBM.Auth)" may optionally further include "spbm.Cert.DS" described above.

At this time, some or all of the "server authentication information (SPBM.Auth)" mentioned above may be digitally signed so that it can be verified using spbm.Cert.DS to ensure the integrity of the information, and this digital signature data is It can be added as part of the "server authentication information".

Referring to FIG. 23, in step 23030, the server 2300 may transmit “server authentication information (SPBM.Auth)” generated in step 23025 to the second SSP 2360 through the second LBA 2370.

Referring to FIG. 23, in step 23035, the second SSP 2360 may verify the received “server authentication information (SPBM.Auth)”. If the second SSP 2360 receives "spbm.Cert.KA", it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2360 receives "spbm.Cert.DS", it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2360 receives "spbm.ePK.KA" and a digital signature for it, the integrity of the received public key spbm.ePK.KA is verified by verifying the digital signature using spbm.Cert.DS. can confirm. In addition, when the second SSP 2360 receives “CiPkIdToBeUsed”, it may check and select at least one signing certificate (ssp2.Cert.DS) capable of verifying itself.

Further, although not shown in the drawing, in step 23035, the second SSP 2360 uses a public key "ssp2.ePK.KA" and a private key "ssp2.eSK." as an asymmetric encryption key pair to be used for key agreement. After creating "KA", you can select the public key (ssp2.ePK.KA) from this key pair. In addition, the second SSP 2360 selects one of the public key for key agreement or spbm.ePK.KA included in spbm.Cert.KA, and then communicates with the server in the future using this value and ssp2.eSK.KA. Session key ShKey03 to be used for middle encryption can be generated. ShKey03 must be the session key for the encryption algorithm contained in the received "CryptoToBeUsed".

In addition, in step 23035, the second SSP 2360 may generate “terminal authentication information (Device.Auth)” capable of authenticating itself. In this case, the "terminal authentication information (Device.Auth)" may include "ssp2.Cert.DS". In addition, the "terminal authentication information (Device.Auth)" may optionally further include "ssp1.Cert.DS". In addition, "terminal authentication information (Device.Auth)" may further include certificate chain information associated with "ssp2.Cert.DS" and/or "ssp1.Cert.DS". In addition, "terminal authentication information (Device.Auth)" may include part and/or all of spblAttestation. In addition, "terminal authentication information (Device.Auth)" may include part and/or all of the finalizationRequest. In addition, "terminal authentication information (Device.Auth)" may include part and/or all of the finalizationResponse. In addition, the "terminal authentication information (Device.Auth)" may further include "ssp2.ePK.KA".

At this time, part or all of the "device authentication information (Device.Auth)" mentioned above may be digitally signed to be verified using ssp2.Cert.DS to ensure the integrity of the information, and this digital signature data may be digitally signed. It can be added as part of "terminal authentication information". In addition, part or all of the “terminal authentication information (Device.Auth)” may be encrypted using the previously generated session key ShKey03.

Referring to FIG. 23, in step 23040, the second SSP 2360 may transmit “terminal authentication information (Device.Auth)” generated in step 23035 to the server 2300 through the second LBA 2370.

Referring to FIG. 23, in step 23045, the server 2300 may verify the received "terminal authentication information (Device.Auth)". The specific procedure of the verification process is as follows. The server 2300 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp1.Cert.DS" and/or "ssp2.Cert.DS". In addition, the server 2300 may verify the signature of the received spblAttestation and/or finalizationRequest and/or finalizationResponse. In addition, the server 2300 may verify the contents of the received spblAttestation and/or finalizationRequest and/or finalizationResponse. In addition, the server 2300 may update the details of the bundle transmitted between devices based on the verified content. For example, the server 2300 may update a mapping relationship between the bundle and the first SSP 2210 to a mapping relationship between the bundle and the second SSP 2360.

In this process, if encrypted data is included in the "device authentication information (Device.Auth)", the server 2300 receives the transmitted ssp2.ePK.KA and the key included in its spbm.Cert.KA. A session key ShKey03 can be generated using a secret key corresponding to the consensus public key or spbm.eSK.KA, and the encrypted data can be decrypted using this session key, and then the verification process can be performed.

Referring to FIG. 23, in step 23050, the server 2300 may transmit a result (eg, success or failure) of a task performed in step 23045 to the second LBA 2370.

FIG. 24 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.

24 shows the transmission details between devices of the bundle

- There is no need to be pre-notified

- This may be a procedure applied when encryption of the content of the notice is not required.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 24, the first terminal 2400 includes a first LBA 2420 and a first SSP 2410, and the second terminal 2450 includes a second LBA 2470 and A second SSP 2460 may be included. As an example, the first terminal 2400 may be a terminal equipped with a first SSP 2410 and a first LBA 2420 for controlling the first SSP 2410, and the second terminal 2450 2 It may be a terminal in which the SSP 2460 is mounted and the second LBA 2470 for controlling the second SSP 2460 is installed.

Referring to FIG. 24, the following procedures may be performed in step 24000.

One. Bundle installation

Referring to FIG. 24, in step 24000, the second LBA 2470 and the second SSP 2460 may cooperate with each other to install a bundle in the second terminal 2450. In this process, the following procedures can be performed together. If metadata is transmitted, the second LBA 2470 or the second SSP 2460 may verify content included in the metadata. If "bundle movement setup" has been transmitted, the second LBA 2470 may transfer this information to the second SSP 2460. If a transaction ID has been transmitted, the second LBA 2470 or the second SSP 2460 may check whether the transaction ID is the same as the transaction ID used in the current session. If 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 2470 or the second SSP 2460 is It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS has been transmitted, the second SSP 2460 may verify the validity of this certificate to authenticate the first SSP 2410. If the transmitted data contains encrypted data, the second SSP 2460 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, you can perform verification. If the received data includes a digital signature, the second SSP 2460 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.

2. Check “Registration Settings”

In addition, although not shown in the drawing, the 2nd LBA 2470 and/or the 2nd SSP 2460 uses the "registration setting" of the corresponding bundle to'whether notification is required' and/or'whether or not pre-announcement is required' and/or You can check'whether the notification contents need to be encrypted.' This process is part of the 24000 step and can be done independently of the other procedures in the 24000 step and in any order. Alternatively, after step 24000, before step 24035 is completed, it may be performed at a moment when judgment is required. A procedure to be described later in this drawing may be a procedure applied when, as a result of confirming the “registration setting”, the transmission details of the bundle between devices do not need to be a pre-announcement and the content of the announcement does not need to be encrypted.

Referring to FIG. 24, in step 24005, the second SSP 2460 may set the state of a corresponding bundle to “IN TRANSITION”. "IN TRANSITION" is a state in which the bundle has been successfully installed but is not yet available (also, additional operations such as'an additional operation to be described later in this drawing' and/or'a request from an external server (although not described in this disclosure)') It means a state that can be changed to an available state (Disabled, Enable, Active state) only by.

Referring to FIG. 24, in step 24010, the second LBA 2470 may request a “certificate” from the second SSP 2460.

Referring to FIG. 24, in step 24015, the second SSP 2460 may generate a “certificate”. In Fig. 24, this certificate may be called finalizationRequest. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The finalizationRequest may include a "bundle identifier" of a corresponding bundle in 1810 of FIG. 18.

- The finalizationRequest may include the "SSP identifier" of the second SSP in 1830 of FIG. 18.

- The finalizationRequest may include information indicating that the second SSP has set the state of the bundle to the “IN TRANSITION” state in 1850 of FIG. 18.

- The finalizationRequest may optionally include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- The finalizationRequest may include signature information of the second SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 2, in operation 24020, the second SSP 2460 may transmit a finalization Request to the first SSP 2410. For example, the second SSP 2460 may transmit a finalizationRequest to the first SSP 2410 through the following process. That is, the second SSP 2460 transmits a finalization Request to the second LBA 2470 in response to step 24010, and the second LBA 2470 sends a finalization request to the first SSP 2410 through the first LBA 2420. I can deliver.

Referring to FIG. 24, in step 24025, a first SSP 2410 may verify a received finalizationRequest. This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP. In addition, the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.

Also, in step 24025, the first SSP 2410 may delete the bundle after completing the verification.

In addition, in step 24025, the first SSP 2410 may generate a "certificate". In Fig. 24, this certificate may be called finalizationResponse. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The finalizationResponse may include a "bundle identifier" of a corresponding bundle in 1810 of FIG. 18. Alternatively, it may include some and/or all data of the finalizationRequest received in the previous step.

- The finalizationResponse may include “SSP identifier” of the first SSP in 1830 of FIG. 18.

- The finalizationResponse may include information indicating that the first SSP has deleted the bundle in 1850 of FIG. 18.

- The finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- The finalizationResponse may include signature information of the first SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Referring to FIG. 24, in step 24030, a first SSP 2410 may transmit a finalizationResponse to a second SSP 2460. For example, the first SSP 2410 may transmit a finalizationResponse to the second SSP 2460 through the first LBA 2420 and the second LBA 2470.

Referring to FIG. 24, in step 24035, the second SSP 2460 may verify the received finalizationResponse. This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse. In addition, the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle. In addition, this verification process may include a process of checking whether some or all of the data of the finalizationRequest included in the finalizationResponse matches the information transmitted by the user. In addition, the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse. In addition, the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.

In addition, in step 24035, the second SSP 2460 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification. For example, as shown in the drawing, the second SSP 2460 may convert the state of the bundle to the Disabled state.

In addition, in step 24035, the second SSP 2460 may generate a "certificate". In FIG. 24, this certificate may be referred to as spblAttestation. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The spblAttestation may include a "bundle separator" of a corresponding bundle in 1810 of FIG. 18. Alternatively, some and/or all data of the finalizationRequest and/or finalizationResponse may be included.

- spblAttestation may include the “SSP identifier” of the second SSP in 1830 of FIG. 18.

- The spblAttestation may include information indicating that the second SSP has changed the bundle to one of the usable states in 1850 of FIG. 18.

- The spblAttestation may optionally include a time when the second SSP changes the state of the bundle to one of the usable states or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- spblAttestation may include signature information of the second SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 24, in step 24040, the second SSP 2460 may transmit spblAttestation generated in step 24035.

25 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 24.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 25, the second terminal 2550 may include a second LBA 2570 and a second SSP 2560. As an example, the second terminal 2550 may be a terminal equipped with a second SSP 2560 and a second LBA 2570 for controlling the second SSP 2560.

In addition, according to various embodiments, the server 2500 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 sometimes used to refer to the server 2500, but as described above, the type of server is not limited to SPBM.

Referring to FIG. 25, in step 25000, a Transport Layer Security (TLS) connection may be established between the SPBM 2500 and the LBA 2570.

Referring to FIG. 25, in step 25005, the second LBA 2570 may transmit part and/or all of spblAttestation and/or finalizationRequest and/or finalizationResponse to the server 2500. In this case, the second LBA 2570 may further transmit “selected SSP information” to the server 2500. For a description of “selected SSP information”, refer to the description of FIG. 22. In addition, the second LBA 2570 may selectively further transmit “ssp2.Cert.DS” to the server 2500. In addition, the second LBA 2570 may selectively further transmit “ssp1.Cert.DS” to the server 2500. In addition, the second LBA 2570 may further include certificate chain information associated with “ssp2.Cert.DS” and/or “ssp1.Cert.DS” to the server 2500. The above information may be configured and transmitted by the second LBA 2570 itself, and although not shown in this figure, the second LBA 2570 may request the corresponding information from the second SSP 2560 and then transmit the received information. Or, although not shown in this drawing, the second LBA 2570 may request a part of the corresponding information from the second SSP 2560, and then combine the received information with the information held by the second LBA 2570 and transmit it.

Referring to FIG. 25, in step 25010, the server 2500 may verify information received in step 25005. The specific procedure of the verification process is as follows. The server 2500 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp1.Cert.DS" and/or "ssp2.Cert.DS". In addition, the server 2500 may verify the signature of the received spblAttestation and/or finalizationRequest and/or finalizationResponse. In addition, the server 2700 may verify the contents of the received spblAttestation and/or finalizationRequest and/or finalizationResponse. In addition, the server 2500 may update the details of the bundle transmitted between devices based on the verified content. For example, the server 2500 may update a mapping relationship between the bundle and the first SSP 2410 to a mapping relationship between the bundle and the second SSP 2500.

Referring to FIG. 25, in step 25015, the server 2500 may transmit the result of the verification operation performed in step 25010 to the second LBA 2570. For example, the server 2500 may transmit the success or failure of verification to the second LBA 2570.

FIG. 26 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.

26 shows the transmission details between devices of the bundle

- Needs to be pre-notified,

- Which does not require or does not require encryption of the content of the notice.

In some cases, this may be a procedure that applies.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 26, the first terminal 2600 includes a first LBA 2620 and a first SSP 2610, and the second terminal 2650 is a second LBA 2670 and A second SSP 2660 may be included. For example, the first terminal 2600 may be a terminal equipped with a first SSP 2610 and a first LBA 2620 for controlling the first SSP 2610, and the second terminal 2650 2 It may be a terminal in which the SSP 2660 is mounted and the second LBA 2670 for controlling the second SSP 2660 is installed.

Referring to FIG. 26, the following procedures may be performed in step 26000.

One. Bundle installation

Referring to FIG. 26, in step 26000, the second LBA 2670 and the second SSP 2660 may cooperate with each other to install a bundle in the second terminal 2650. In this process, the following procedures can be performed together. If metadata is transmitted, the second LBA 2670 or the second SSP 2660 may verify content included in the metadata. If "bundle movement setup" has been transmitted, the second LBA 2670 may transmit this information to the second SSP 2660. If a transaction ID has been transmitted, the second LBA 2670 or the second SSP 2660 may check whether the transaction ID is the same as the transaction ID used in the current session. If 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 2670 or the second SSP 2660 is It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS is transmitted, the second SSP 2660 may verify the validity of this certificate to authenticate the first SSP 2610. If the transmitted data contains encrypted data, the second SSP 2660 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, verification can be performed. If the received data includes a digital signature, the second SSP 2660 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.

2. Check whether pre-registration is required

In addition, although not shown in the drawing, the 2nd LBA 2670 and/or the 2nd SSP 2660 uses the "registration setting" of the corresponding bundle to'whether notification is necessary' and/or'whether or not preliminary notification is required' and/or You can check'whether or not the contents of the notice need to be encrypted.' This process is part of step 26000 and can be done independently of the other procedures in step 26000 and in any order. Alternatively, it may be performed at a moment when judgment is necessary after step 26000 and before step 26035 is completed. A procedure to be described later in this drawing may be a procedure applied when, as a result of confirming the “registration setting”, the transmission details between devices of the bundle need to be announced.

Referring to FIG. 26, in step 26005, the second SSP 2660 may set the state of a corresponding bundle to “IN TRANSITION”. "IN TRANSITION" is a state in which the bundle has been successfully installed but is not yet available (also,'additional operations to be described later in this drawing and additional operations to be described in Fig. 27' and/or'(although not described in this disclosure)) It means a state that can be changed to an available state (Disabled, Enable, Active state) only by an additional operation such as'Request from server'.

Referring to FIG. 26, in step 26010, the second LBA 2670 may request a “certificate” from the second SSP 2660.

Referring to FIG. 26, in step 26015, the second SSP 2660 may generate a “certificate”. In Fig. 26, this certificate may be called finalizationRequest. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The finalizationRequest may include a "bundle identifier" of a corresponding bundle in 1810 of FIG. 18.

- The finalizationRequest may include the "SSP identifier" of the second SSP in 1830 of FIG. 18.

- The finalizationRequest may include information indicating that the second SSP has set the state of the bundle to the “IN TRANSITION” state in 1850 of FIG. 18.

- The finalizationRequest may optionally include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- The finalizationRequest may include signature information of the second SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 26, in step 26020, the second SSP 2660 may transmit a finalization Request to the first SSP 2610. For example, the second SSP 2660 may transmit a finalizationRequest to the first SSP 2610 through the following process. That is, the second SSP 2660 may transmit the finalizationRequest to the second LBA 2670 in response to step 26010, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 2620.

Referring to FIG. 26, in step 26025, the first SSP 2610 may verify the received finalizationRequest. This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP. In addition, the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.

Also, in step 26025, the first SSP 2610 may delete the bundle after completing the verification.

In addition, in step 26025, the first SSP 2610 may generate a "certificate". In Fig. 26, this certificate may be called finalizationResponse. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The finalizationResponse may include a "bundle identifier" of a corresponding bundle in 1810 of FIG. 18. Alternatively, it may include some and/or all data of the finalizationRequest received in the previous step.

- The finalizationResponse may include “SSP identifier” of the first SSP in 1830 of FIG. 18.

- The finalizationResponse may include information indicating that the first SSP has deleted the bundle in 1850 of FIG. 18.

- The finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- The finalizationResponse may include signature information of the first SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Referring to FIG. 26, in step 26030, a first SSP 2610 may transmit a finalizationResponse to a second SSP 2660. For example, the first SSP 2610 may transmit a finalizationResponse to the second SSP 2660 through the first LBA 2620 and the second LBA 2670.

Referring to FIG. 26, in step 26035, the second SSP 2660 may verify the received finalizationResponse. This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse. In addition, the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle. In addition, this verification process may include a process of checking whether the data daily or all of the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse. In addition, the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse. In addition, the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.

In addition, in step 26035, the second SSP 2660 may generate its own "selected SSP information (sspInforSelected)". The "selected SSP information" may include information on the second SSP that must be provided to notify the server of the bundle transmission result between devices.

At this time, the "selected SSP information" may include information for a certificate negotiation process (certificate negotiation information). This "Certificate Negotiation Information"

- Certificate information that the second SSP 2660 can use to verify the server (spbmVerification)

- Certificate information that the server can use to verify the first SSP 2610 (SenderSpblVerification)

- Certificate information that the server can use to verify the second SSP (2660) (ReceiverSpblVerification)

It may optionally include information such as. In addition, the "certificate negotiation information" may optionally further include a list of key agreement algorithms supported by the second SSP 2660, and may optionally further include a list of encryption algorithms supported by the second SSP 2660. I can.

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

Referring to FIG. 26, in step 26040, the second SSP 2660 may transmit a result (eg, success or failure) of the task performed in step 26035 to the second LBA 2670. In addition, “selected SSP information” generated in step 26035 may be transmitted together.

The process of generating “selected SSP information” in step 26035 and the process of delivering “selected SSP information” in step 26040 may be omitted.

FIG. 27 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 26.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 27, the second terminal 2750 may include a second LBA 2770 and a second SSP 2760. As an example, the second terminal 2750 may be a terminal equipped with a second SSP 2760 and a second LBA 2770 for controlling the second SSP 2760.

In addition, according to various embodiments, the server 2700 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 a server, is sometimes used to refer to the server 2700, but as described above, the type of server is not limited to SPBM.

Referring to FIG. 27, in step 27000, a Transport Layer Security (TLS) connection may be established between the SPBM 2700 and the LBA 2770. In this drawing, although it is described that step 27000 is performed before steps 27005 to 27015, step 27000 may be performed independently from steps 27005 to 27015 before step 27020 is performed. For example, step 27000 may be performed between steps 27015 and 27020.

Referring to FIG. 27, in step 27005, the second LBA 2770 may request “selected SSP information (SspInfoSelected)” from the second SSP 2 2760. In this case, step 27005 may be performed automatically or may be performed after receiving an external input. In this case, the'external input' may be given from a user through a UI provided by the second terminal 2750 or may be given to the second terminal 2750 through a push input from a remote server.

Referring to FIG. 27, in step 27010, the second SSP 2760 may generate its own “selected SSP information”. For a description of “selected SSP information”, refer to the description described in FIG. 26.

Referring to FIG. 27, in step 27015, the second SSP 2760 may transmit “selected SSP information” generated in step 27010 to the second LBA 2770.

Steps 27005 to 27015 may be omitted in some cases.

Referring to FIG. 27, in step 27020, the second LBA 2770 may transmit “selected SSP information” to the server 2700. If the second LBA 2770 receives “selected SSP information” through steps 26035 to 26040 of FIG. 26, or receives “selected SSP information” through steps 27005 to 27015 of FIG. 27, the second LBA 2770 ) May transmit the received “selected SSP information” to the server 2700. If the second LBA 2770 has not received “selected SSP information”, the second LBA 2770 may generate “selected SSP information” and transmit it to the server 2700.

Referring to FIG. 27, in step 27025, the server 2700 may check the received “selected SSP information” and generate “server authentication information (SPBM.Auth)” capable of authenticating itself based on this information. . A more detailed procedure for this process is as follows.

The server 2700 may check certificate information capable of verifying itself using the received "spbmVerification" and select at least one key agreement certificate (spbm.Cert.KA). Alternatively, the server 2700 uses the received "list of key agreement algorithms supported by the second SSP 2760" to use the asymmetric encryption key pair public key "spbm.ePK.KA" to be used for key agreement. After creating the private key "spbm.eSK.KA", you can select the public key (spbm.ePK.KA) from this key pair. In addition, the server 2700 may check certificate information capable of verifying itself using the received "spbmVerification" and further select at least one signing certificate (spbm.Cert.DS).

In addition, the server 2700 may check whether the certificate information of the first SSP 2610 to be verified by using the received "SenderSpblVerification" is verifiable by itself.

In addition, the server 2700 may check whether the certificate information of the second SSP 2760 to be verified by using the received “ReceiverSpblVerification” is verifiable by itself. Alternatively, after selecting at least one certificate information of the second SSP 2760 that can be verified by using “ReceiverSpblVerification”, the corresponding information may be set as “CiPkIdToBeUsed”.

In addition, the server 2700 may select at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 2760" and then set corresponding information to "CryptoToBeUsed".

In addition, the server 2700 checks the list of the received "version information of the primary platform included in the second SSP 2760 and the standard standard supported by the loader", and among them, there is a version of the standard standard that it also supports. You can check whether it is.

"Server authentication information (SPBM.Auth)" includes at least one of "spbm.Cert.KA", "spbm.ePK.KA", "spbm.Cert.DS", "CiPkIdToBeUsed", and "CryptoToBeUsed" described above. Can include.

At this time, some or all of the "server authentication information (SPBM.Auth)" mentioned above may be digitally signed so that it can be verified using spbm.Cert.DS to ensure the integrity of the information, and this digital signature data is It can be added as part of the "server authentication information".

Referring to FIG. 27, in step 27030, the server 2700 may transmit “server authentication information (SPBM.Auth)” generated in step 27025 to the second SSP 2760 through the second LBA 2770.

Referring to FIG. 27, in step 27035, the second SSP 2760 may verify the received "server authentication information (SPBM.Auth)". If, when the second SSP 2760 receives "spbm.Cert.KA", it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2760 receives "spbm.Cert.DS", it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2760 receives "spbm.ePK.KA" and a digital signature therefor, it verifies the digital signature using spbm.Cert.DS and the integrity of the received public key spbm.ePK.KA. can confirm. In addition, when the second SSP 2760 receives “CiPkIdToBeUsed”, it may check and select at least one signature certificate (ssp2.Cert.DS) capable of verifying itself.

Further, although not shown in the drawing, in step 27035, the second SSP 2760 uses a public key "ssp2.ePK.KA" and a private key "ssp2.eSK." as an asymmetric encryption key pair to be used for key agreement. After creating "KA", you can select the public key (ssp2.ePK.KA) from this key pair. In addition, the second SSP 2760 selects one of the public key for key agreement or spbm.ePK.KA included in spbm.Cert.KA, and then communicates with the server in the future using this value and ssp2.eSK.KA. Session key ShKey03 to be used for middle encryption can be generated. ShKey03 must be the session key for the encryption algorithm contained in the received "CryptoToBeUsed".

In addition, in step 27035, the second SSP 2760 may generate “terminal authentication information (Device.Auth)” capable of authenticating itself. In this case, the "terminal authentication information (Device.Auth)" may include "ssp2.Cert.DS". In addition, the "terminal authentication information (Device.Auth)" may further include "ssp2.ePK.KA". In addition, the "terminal authentication information (Device.Auth)" may optionally further include "ssp1.Cert.DS". In addition, "terminal authentication information (Device.Auth)" may include part and/or all of the finalizationRequest. In addition, "terminal authentication information (Device.Auth)" may include part and/or all of the finalizationResponse.

At this time, part or all of the "device authentication information (Device.Auth)" mentioned above may be digitally signed to be verified using ssp2.Cert.DS to ensure the integrity of the information, and this digital signature data may be digitally signed. It can be added as part of "terminal authentication information". In addition, part or all of the “terminal authentication information (Device.Auth)” may be encrypted using the previously generated session key ShKey03.

Referring to FIG. 27, in step 27040, the second SSP 2760 may transmit “terminal authentication information (Device.Auth)” generated in step 27035 to the server 2700 through the second LBA 2770.

Referring to FIG. 27, in step 27045, the server 2700 may verify the received "terminal authentication information (Device.Auth)". The specific procedure of the verification process is as follows. The server 2700 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp1.Cert.DS" and/or "ssp2.Cert.DS". Also, the server 2700 may verify the signature of the received finalizationRequest and/or finalizationResponse. Also, the server 2700 may verify the contents of the received finalizationRequest and/or finalizationResponse. In addition, the server 2700 may update the details of the bundle transmitted between devices based on the verified content. For example, the server 2700 may update a mapping relationship between the bundle and the first SSP 2610 to a mapping relationship between the bundle and the second SSP 2760.

In this process, if encrypted data is included in the "device authentication information (Device.Auth)", the server 2700 receives the transmitted ssp2.ePK.KA and the key included in its spbm.Cert.KA. A session key ShKey03 can be generated using a secret key corresponding to the consensus public key or spbm.eSK.KA, and the encrypted data can be decrypted using this session key, and then the verification process can be performed.

In addition, in step 27045, the server 2700 may generate a "certificate". In Fig. 27, this certificate may be referred to as spbmAttestation. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The spbmAttestation may include a "bundle separator" of a corresponding bundle in 1810 of FIG. 18. Alternatively, some and/or all data of the finalizationRequest and/or finalizationResponse received in the previous step may be included.

- The spbmAttestation may include an identifier of a server (eg, an identifier of a service provider and/or an identifier of a bundle management server and/or an address of a server) in 1830 of FIG. 18.

- The spbmAttestation may include information indicating that the server has confirmed the movement history of the bundle in 1850 of FIG. 18.

- The spbmAttestation may optionally include a time when the server confirms the movement history of the bundle or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- The spbmAttestation may include the server's signature information in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a server's signature certificate.

In addition, in step 27045, although not shown in Fig. 27, the server 2700 uses an asymmetric encryption key pair public key "spbm.attestation.ePK.KA" and a private key "spbm.attestation. eSK.KA" can be created. At this time, the key pair "spbm.attestation.ePK.KA and spbm.attestation.eSK.KA" may be set to the same value as the previously created "spbm.ePK.KA and spbm.eSK.KA". Alternatively, the key pair "spbm.attestation.ePK.KA and spbm.attestation.eSK.KA" will be set to the same value as the previously used "public key included in spbm.Cert.KA and the corresponding private key". May be. In addition, the server 2700 may generate a session key ShKey04 using spbm.attestation.eSK.KA and ssp2.ePK.KA. If spbm.eSK.KA or the private key corresponding to the public key included in spbm.Cert.Ka is reused for spbm.attstation.eSK.KA, the value of the session key ShKey04 is also the value of the previously generated ShKey03. Can be set to a value.

In addition, in step 27045, although not shown in FIG. 27, the server 2700 may configure “certificate verification data”. "Certificate verification data" may include "spbm.Cert.DS". Also, an electronic signature value of the server for "spbm.attestation.ePK.KA" and/or "spbm.attestation.ePK.KA" may be further included.

According to various embodiments, some and/or all of the “certificate” and “certificate verification data” generated in step 27045 may be encrypted using ShKey04.

Referring to FIG. 27, in step 27050, the server 2700 may transmit “spbmAttestation” and “certificate verification data” generated in step 27045 to the second SSP 2760 through the second LBA 2770.

Referring to FIG. 27, in step 27055, the second SSP 2760 may verify the received “spbmAttestaion” and/or “certificate verification data”. If the transmitted data contains encrypted data, the second SSP 2760 generates a session key ShKey04 using the transmitted spbm.attestation.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, you can perform verification. If the received data includes a digital signature, the second SSP 2760 may verify the validity of the digital signature using this certificate after verifying spbm.Cert.DS.

In addition, in step 27055, the second SSP 2760 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification. For example, as shown in the drawing, the second SSP 2760 may convert the state of the bundle to the Disabled state.

Referring to FIG. 27, in step 27060, the second SSP 2760 may transmit the result of performing step 27060 to the second LBA 2770. For example, the second SSP 2760 may transmit the verification success or failure result of step 27060 to the second LBA 2770.

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

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

According to various embodiments, the transmission/reception unit 2810 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 2810 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 2810, and components of the transmission/reception unit 2810 are not limited to the RF transmitter and the RF receiver. In addition, the transmission/reception unit 2810 may receive a signal through a wireless channel, output it to the at least one processor 2820, and transmit a signal output from the at least one processor 2820 through a wireless channel.

According to various embodiments, the transmission/reception unit 2810 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 the server, and The authentication information capable of authenticating the data, a bundle movement code, a bundle movement setting, a bundle, and various certificates described in FIGS. 22 to 27 may be transmitted or received.

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

Meanwhile, the SSP 2830 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 2830 may determine whether to transmit a specific bundle by checking the bundle movement setting. In addition, it is possible to determine whether the bundle movement setting is checked and whether the result of the bundle movement between devices of the corresponding bundle should be registered in the server, or whether a notification is required if registration is required.

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 2830 may generate a bundle, and may install the bundle alone or in cooperation with one or more processors 2820. In addition, the SSP 2830 may manage the bundle.

In addition, according to various embodiments, the SSP 2830 may generate various types of certificates described in FIGS. 22 to 27 and verify the received certificates.

In addition, according to various embodiments, the SSP 2830 may change the state of the bundle based on the contents of the received certificate as described in FIGS. 22 to 27.

In addition, according to various embodiments, the SSP 2830 may operate under the control of the processor 2820. Alternatively, the SSP 2830 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 2830 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. Also, the processor 2820 may perform various operations using various programs, contents, data, etc. stored in the memory.

29 is a diagram illustrating a configuration of a server according to an embodiment of the present disclosure. In this case, the server may be a server operated by a service provider, a bundle management server, or a server operated by cooperation between a service provider and a bundle management server, or linked with a service provider and/or a bundle management server. It may be any server that is operated and operated. 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 2910 and at least one processor 2920. However, the configuration of the bundle management server is not limited to FIG. 29, and may include more or fewer components than the components illustrated in FIG. 29. According to some embodiments, the transmission/reception unit 2910, at least one processor 2920, and a memory (not shown) may be implemented in the form of a single chip.

According to some embodiments, the transceiving unit 2910 may transmit and receive signals, information, and data according to various embodiments of the present disclosure to and from the terminal. The transceiver 2910 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 2910, and components of the transmission/reception unit 2910 are not limited to the RF transmitter and the RF receiver. In addition, the transceiver 2910 may receive a signal through a wireless channel, output it to the at least one processor 2920, and transmit a signal output from the at least one processor 2920 through a wireless channel.

Meanwhile, at least one processor 2920 is a component for overall control of the bundle management server. The processor 2920 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 2920 may be referred to as a control unit.

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 2920 may perform various operations using various programs, contents, data, etc. stored in the memory.

FIG. 30 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19 and a procedure in which a transmission result of a bundle is registered in the server.

According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 30, the first terminal 3000 includes a first LBA 3020 and a first SSP 3010, and the second terminal 3050 includes a second LBA 3070 and It may include a second SSP (3060). As an example, the first terminal 3000 may be a terminal equipped with a first SSP 3010 and a first LBA 3020 for controlling the first SSP 3010, and the second terminal 3050 2 It may be a terminal in which the SSP 3060 is mounted and the second LBA 3070 for controlling the second SSP 3060 is installed.

Referring to FIG. 30, the following procedures may be performed in step 30000.

One. Bundle installation

Referring to FIG. 30, in step 30000, the second LBA 3070 and the second SSP 3060 may cooperate with each other to install a bundle in the second terminal 3050. In this process, the following procedures can be performed together. If metadata is transmitted, the second LBA 3070 or the second SSP 3060 may verify the contents included in the metadata. If "bundle movement setting" is transmitted, the second LBA 3070 may transmit the information to the second SSP 3060. If a transaction ID has been transmitted, the second LBA 3070 or the second SSP 3060 may check whether the transaction ID is the same as the transaction ID used in the current session. If 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 3070 or the second SSP 3060 is It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS is transmitted, the second SSP 3060 may verify the validity of this certificate to authenticate the first SSP 3010. If the transmitted data contains encrypted data, the second SSP 3060 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, you can perform verification. If the received data includes a digital signature, the second SSP 3060 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.

2. Check “Registration Settings”

In addition, although not shown in the drawing, the 2nd LBA 3070 and/or the 2nd SSP 3060 uses the "registration setting" of the corresponding bundle to'whether or not to require notification' and/or'whether or not to be announced' and/or You can check'whether the notification contents need to be encrypted.' This process is part of step 30000 and can be performed independently of other procedures in step 30000 and in any order. Or, after step 30000, before notification is made at 30040 or 30050, it may be performed at the moment when it is necessary to check the “registration setting” and make a decision.

Referring to FIG. 30, in step 30005, the second SSP 3060 may set the state of a corresponding bundle to “IN TRANSITION”. "IN TRANSITION" is a state in which the bundle has been successfully installed but cannot be used (also, a state that can be used only by an operation such as'request from the first terminal 3000' and/or'request from an external server' (Disabled, It can mean a state that can be changed to (Enable, Active state).

Referring to FIG. 30, in step 30010, the second LBA 3070 may request a “certificate” from the second SSP 3060.

Referring to FIG. 30, in step 30015, the second SSP 3060 may generate a “certificate”. In Fig. 30, this certificate may be called finalizationRequest. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The finalizationRequest may include a "bundle identifier" of a corresponding bundle in 510 of FIG. 18.

- The finalizationRequest may include “SSP identifier” of the second SSP in 530 of FIG. 18.

- The finalizationRequest may include information indicating that the second SSP has set the state of the bundle to the “IN TRANSITION” state in 1850 of FIG. 18.

- The finalizationRequest may selectively include a time when the second SSP sets the bundle state to the “IN TRANSITION” state in 1870 of FIG. 18 or a time when a certificate is created. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- The finalizationRequest may include signature information of the second SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 22, in step 30020, the second SSP 3060 may transmit a finalization Request to the first SSP 3010. For example, the second SSP 3060 may transmit a finalizationRequest to the first SSP 3010 through the following process. That is, the second SSP 3060 transmits a finalization Request to the second LBA 3070 in a response of step 30010, and the second LBA 3070 sends a finalization request to the first SSP 3010 through the first LBA 3020. I can deliver.

Referring to FIG. 30, in step 30025, the first SSP 3010 may verify the received finalizationRequest. This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP. In addition, the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.

In addition, in step 30025, the first SSP 3010 may set the state of the corresponding bundle to "IN TRANSITION" after completing the verification. "IN TRANSITION" is a state in which the bundle has been successfully installed but cannot be used (also, a state that can be used only by additional operations such as'request from the second terminal 3050' and/or'request from an external server' (Disabled , Enable, Active state).

In addition, in step 30025, the first SSP 3010 may generate a "certificate". In Fig. 30, this certificate may be called finalizationResponse. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- The finalizationResponse may include a "bundle identifier" of a corresponding bundle in 510 of FIG. 18. Alternatively, it may include some and/or all data of the finalizationRequest received in the previous step.

- The finalizationResponse may include “SSP identifier” of the first SSP in 530 of FIG. 18.

- The finalizationResponse may include information indicating that the first SSP has set the bundle state to the “IN TRANSITION” state in 1850 of FIG. 18.

- The finalizationResponse may selectively include a time when the first SSP sets the bundle status to an “IN TRANSITION” state or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- The finalizationResponse may include signature information of the first SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.

Referring to FIG. 30, in step 30030, a first SSP 3010 may transmit a finalizationResponse to a second SSP 3060. For example, the first SSP 3010 may transmit a finalizationResponse to the second SSP 3060 through the first LBA 3020 and the second LBA 3070.

Referring to FIG. 30, in step 30035, the second SSP 3060 may verify the received finalizationResponse. This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse. In addition, the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle. In addition, this verification process may include a process of checking whether some or all of the data of the finalizationRequest included in the finalizationResponse matches the information transmitted by the user. In addition, the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse. In addition, the verification process may further include a process of checking whether command information included in the finalizationResponse sets the state of the bundle to “IN TRANSITION”.

Referring to FIG. 30, a pre-notification procedure may be performed in step 30040. This procedure may be a procedure that is applied when it is set that a notification is required in "Registration Settings". If a notice procedure is carried out, this procedure may be as follows.

First, the second SSP 3060 may generate sspInfoSelected and transmit this information to the second LBA 3070. This process may be omitted if necessary. In this case, the description of sspInfoSelected will be referred to the description of FIG. 26. Thereafter, of the procedure described in FIG. 27, a procedure before “a procedure of changing the state of the bundle to one of the available states (one of Disabled, Enable, and Active)” in step 27055 may be performed.

Referring to FIG. 30, in step 30045, the second SSP 3060 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the second SSP 3060 may convert the state of the bundle to the Disabled state.

In addition, in step 30045, the second SSP 3060 may generate a "certificate". In Fig. 30, this certificate may be called spblAttestation. The structure of this certificate may follow the structure disclosed in FIG. 18.

At this time, one example of possible certificate configuration is as follows.

- spblAttestation may include a "bundle separator" of a corresponding bundle in 510 of FIG. 18. Alternatively, some and/or all data of'finalizationRequest and/or finalizationResponse and/or spbmAttestaion' may be included.

- spblAttestation may include “SSP identifier” of the second SSP in 530 of FIG. 18.

- The spblAttestation may include information indicating that the second SSP has changed the bundle to one of the usable states in 1850 of FIG. 18.

- The spblAttestation may optionally include a time when the second SSP changes the state of the bundle to one of the usable states or a time when a certificate is created in 1870 of FIG. 18. Alternatively, information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.

- spblAttestation may include signature information of the second SSP in 1890 of FIG. 18. This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.

Referring to FIG. 30, in step 30050, a post-notification procedure may be performed. This procedure may be applied when it is set in “Registration Settings” that no notice is required. If a post-notification procedure is carried out, this procedure may be as follows.

a. When it is set that encryption of the notice contents is required in "Registration Settings"

First, the second SSP 3060 may generate sspInfoSelected and transmit this information to the second LBA 3070. This process may be omitted if necessary. In this case, the description of sspInfoSelected will be referred to the description of FIG. 22. Thereafter, the procedure described in FIG. 23 may be performed.

b. When it is set that encryption of the notice contents is not required in "Registration Settings"

First, the second SSP 3060 may transmit spblAttestation to the second LBA 3070. Thereafter, the procedure described in FIG. 25 may be performed.

Referring to FIG. 30, in step 30055, the second SSP 3060 may transmit spblAttestation to the first SSP 3010 through the second LBA 3070 and the first LBA 3020.

Referring to FIG. 30, in step 30060, the first SSP 3010 may verify the received spblAttestation. This verification process may include checking the validity of the signature of the second SSP included in the spblAttestation. In addition, the verification process may further include a process of checking whether the "bundle separator" included in spblAttestation matches the bundle identifier of the corresponding bundle. In addition, the verification process may further include a process of checking whether the "SSP identifier" included in the spblAttestation is a correct identifier of the second SSP. In addition, the verification process may further include a process of checking whether command information included in spblAttestation sets the bundle status to one of the usable statuses.

Also, in step 30060, the first SSP 3010 may delete the bundle.

The procedure for generating spblAttestation in step 30045 and/or step 30055 and/or step 30060 may be omitted as necessary.

If the notification process described in step 30040 or 30050 is not completed (for example, when a notification is sent to the server but does not receive a response thereto), the second terminal may repeatedly retransmit the notification to the server. The retransmission process may be performed until this maximum value is satisfied according to the preset maximum number of retransmissions, or may be repeated until a response is received from the server.

According to the “registration setting”, when a pre-notification is required, but the bundle is not available in both devices of the first terminal 3000 and the second terminal 3050 because the process 30040 is not normally performed, the request of the server illustrated in FIG. 29 Accordingly, the state of the bundle installed in the first terminal 3000 and/or the second terminal 3050 may be changed from “IN TRANSITION” to one of the usable states (eg, a disabled state).

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 the processor, 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 some of the computer program products 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 of the constituent elements (eg, modules or programs) according to various embodiments may be composed of singular or plural entities, and some sub-elements of the aforementioned sub-elements are omitted, or other sub-elements are various. It may be further included in the embodiment. 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 (20)

In the operating method of the first terminal,
Transmitting a bundle to a second terminal;
Receiving, from the second terminal, a first certificate generated including bundle status information of the second terminal;
Verifying the received first certificate;
After verifying the first certificate, generating a second certificate including bundle status information of the first terminal; And
And transmitting the second certificate to the second terminal.
The method of claim 1,
The bundle state information of the first terminal, characterized in that the bundle state of the first terminal is set to at least one of DELETE, IN TRANSITION, and SUSPENSION.
The method of claim 2,
When the bundle state of the first terminal is set to IN TRANSITION, receiving a third certificate generated from the second terminal including information on the change of the bundle state of the second terminal;
Verifying the received third certificate; And
And deleting (DELETE) the bundle of the first terminal after verifying the third certificate.
The method of claim 1,
A fourth certificate including information on a verification result of the first certificate and the second certificate is generated by the second terminal,
The fourth certificate is transmitted to the server, and
And the fourth certificate is verified by the server.
The method of claim 1,
A fifth certificate including a result of authentication with the server is generated by the server,
The fifth certificate is transmitted to the second terminal, and
And the fifth certificate is verified by the second terminal.
In the operation method of the second terminal,
Receiving a bundle from a first terminal;
Installing the bundle;
Generating a first certificate including bundle status information of a second terminal;
Transmitting the first certificate to the first terminal;
Receiving, from the first terminal, a second certificate generated including bundle status information of the first terminal;
Verifying the received second certificate; And
And after verifying the second certificate, changing the bundle state setting information of the second terminal.
The method of claim 6,
The step of changing the bundle state setting information of the second terminal is a step of changing the bundle state of the second terminal to at least one of an enabled, a driven state, and a disabled,
The bundle state information of the first terminal, characterized in that the bundle state of the first terminal is set to at least one of DELETE, IN TRANSITION, and SUSPENSION.
The method of claim 7,
Generating a third certificate including information on change of the bundle state of the second terminal when the bundle state of the first terminal is set to IN TRANSITION; And
And transmitting the third certificate to the first terminal.
The method of claim 6,
Generating a fourth certificate including information on a verification result of the first certificate and the second certificate; And
And transmitting the fourth certificate to a server.
The method of claim 6,
Receiving, from a server, a fifth certificate generated including a result of authentication with the server;
Verifying the received fifth certificate; And
And after verifying the fifth certificate, changing the bundle state setting information of the second terminal.
In the first terminal,
A transceiver capable of transmitting and receiving at least one signal; And
Including a control unit coupled to the transmission and reception unit,
The control unit:
To the second terminal, transmitting the bundle,
Receiving from the second terminal, a first certificate generated including the bundle status information of the second terminal,
Verify the received first certificate,
After verifying the first certificate, a second certificate including bundle status information of the first terminal is generated, and
And transmitting the second certificate to the second terminal.
The method of claim 11,
The first terminal, characterized in that the bundle state information of the first terminal comprises that the bundle state of the first terminal is set to at least one of DELETE, IN TRANSITION, and SUSPENSION.
The method of claim 12, wherein the control unit:
When the bundle state of the first terminal is set to IN TRANSITION, a third certificate generated including information on the bundle state change of the second terminal is received from the second terminal, and
Verify the received third certificate, and
After verifying the third certificate, the first terminal, characterized in that further configured to delete (DELETE) the bundle of the first terminal.
The method of claim 11,
A fourth certificate including information on a verification result of the first certificate and the second certificate is generated by the second terminal,
The fourth certificate is transmitted to the server, and
The first terminal, wherein the fourth certificate is verified by the server.
The method of claim 11,
A fifth certificate including a result of authentication with the server is generated by the server,
The fifth certificate is transmitted to the second terminal, and
The first terminal, wherein the fifth certificate is verified by the second terminal.
In the second terminal,
A transceiver capable of transmitting and receiving at least one signal; And
Including a control unit coupled to the transmission and reception unit,
The control unit:
Receiving a bundle from the first terminal,
Install the above bundle,
Generate a first certificate including the bundle status information of the second terminal,
To the first terminal, transmitting the first certificate,
Receiving from the first terminal, a second certificate generated including the bundle status information of the first terminal,
Verify the received second certificate, and
And after verifying the second certificate, changing the bundle state setting information of the second terminal.
The method of claim 16, wherein the control unit:
It is configured to change the bundle state of the second terminal to at least one of an enabled, a driven state, and a disabled,
The bundle state information of the first terminal, wherein the bundle state of the first terminal is set to at least one of DELETE, IN TRANSITION, and SUSPENSION.
The method of claim 17, wherein the control unit:
When the bundle state of the first terminal is set to IN TRANSITION, a third certificate including information on the change of the bundle state of the second terminal is generated, and
The second terminal, further configured to transmit the third certificate to the first terminal.
The method of claim 16, wherein the control unit:
Generating a fourth certificate including information on a verification result of the first certificate and the second certificate, and
The second terminal, further configured to transmit the fourth certificate to the server.
The method of claim 16, wherein the control unit:
Receiving, from the server, a fifth certificate generated including the result of authentication with the server,
Verify the received fifth certificate, and,
And after verifying the fifth certificate, the second terminal is further configured to change the bundle state setting information of the second terminal.

Images