Method and apparatus for setting the status of a packet after packet transmission between devices

Abstract

The present disclosure relates to a communication method and system for integrating a fifth generation (5G) communication system supporting higher data rates than a fourth generation (4G) system with Internet of Things (IoT) technology. The present disclosure can be applied to smart services based on 5G communication technology and IoT-related technologies, such as smart homes, smart buildings, smart cities, smart cars, connected cars, healthcare, digital education, smart retail, safety and security services. The present disclosure describes a method and apparatus for setting the state of a packet after the packet has been sent between smart secure media.

Description

Technical Field

[0001] The present disclosure relates to smart secure media, and more particularly, to a method and apparatus for configuring a state of a bundle after a bundle is transmitted between smart secure media.

[0002] The present disclosure relates to smart secure media, and more particularly, to a method and apparatus for registering a packet transmission result in a server after packet transmission between smart secure media. Background Art

[0003] In order to meet the increased demand for wireless data traffic since the deployment of 4G communication systems, efforts have been made to develop improved 5G or pre-5G (pre-5G) communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "super 4G networks" or "post-LTE systems". 5G communication systems are considered to be implemented in higher frequency (millimeter wave) bands (e.g., 60GHz bands) in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple input multiple output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed in 5G communication systems. In addition, in 5G communication systems, system network improvements are being developed based on advanced small cells, cloud radio access networks (RANs), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, collaborative communications, collaborative multi-point (CoMP), receiving-end interference elimination, etc. In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coded modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0004] The Internet is a human-centric connected network in which people generate and consume information, which is now developing into the Internet of Things (IoT), in which distributed entities (such as things) exchange and process information without human intervention. The Internet of Everything (IoE) has now emerged, which is a combination of IoT technology and big data processing technology connected to cloud servers. Since technical elements such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology" and "security technology" have been required by IoT implementation, sensor networks, machine-to-machine (M2M) communication, machine type communication (MTC), etc. have been recently studied. Such an IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected objects. Through the integration and combination between existing information technology (IT) and various industrial applications, IoT can be applied to various fields, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, health care, smart appliances and advanced medical services.

[0005] Accordingly, various attempts have been made to apply 5G communication systems to IoT networks. Technologies such as sensor networks, machine type communications (MTC), and machine-to-machine (M2M) communications can be implemented through beamforming, MIMO, and array antennas. Cloud radio access networks (RANs) as an application of the above-mentioned big data processing technologies can also be seen as an example of the integration of 5G technology and IoT technology. Summary of the invention

[0006] Technical issues

[0007] The disclosed embodiments provide an apparatus and method for configuring a bundle state after performing bundle transmission when moving a bundle between security modules included in two electronic devices.

[0008] Furthermore, the disclosed embodiments provide an apparatus and method for registering a packet transmission result in a server after performing the packet transmission when a packet is moved between security modules included in two electronic devices.

[0009] Technical Solution

[0010] According to an embodiment of the present disclosure, a method for operating a first terminal includes: sending a packet to a second terminal; receiving a first certificate generated from the second terminal including packet status information of the second terminal; verifying the received first certificate; after verifying the first certificate, generating a second certificate including the packet status information of the first terminal; and sending the second certificate to the second terminal.

[0011] In some examples, the package status information of the first terminal may include that the package status of the first terminal is configured as at least one of DELETE, IN TRANSITION, and SUSPENSION.

[0012] In some examples, the method may also include: receiving a generated third proof from the second terminal, the third proof including information about a change in the packet state of the second terminal when the packet state of the first terminal is configured to be in transition; verifying the received third proof; and deleting the packet of the first terminal after verifying the third proof.

[0013] In some examples, a fourth certificate including information about a verification result of the first certificate and the second certificate may be generated by the second terminal, the fourth certificate may be sent to the server, and the fourth certificate may be verified by the server.

[0014] In some examples, a fifth certificate including an authentication result with the server may be generated by the server; the fifth certificate may be sent to the second terminal, and the fifth certificate may be verified by the second terminal.

[0015] According to another embodiment of the present disclosure, a method for operating a second terminal includes receiving a package from a first terminal; installing the package; generating a first certificate including package status information of the second terminal; sending the first certificate to the first terminal; receiving the generated second certificate including the package status information of the first terminal from the first terminal; verifying the received second certificate; and after verifying the second certificate, changing the package status configuration information of the second terminal.

[0016] According to another embodiment of the present disclosure, a first terminal includes a transceiver configured to send and receive at least one signal; and a controller coupled to the transceiver, wherein the controller is configured to send a packet to a second terminal, receive a generated first certificate including packet status information of the second terminal from the second terminal; verify the received first certificate; after verifying the first certificate, generate a second certificate including the packet status information of the first terminal, and send the second certificate to the second terminal.

[0017] According to another embodiment of the present disclosure, the second terminal includes a transceiver configured to send and receive at least one signal; and a controller coupled to the transceiver, wherein the controller is configured to receive a package from the first terminal, install the package, generate a first certificate including package status information of the second terminal, send the first certificate to the first terminal, receive the generated second certificate including the package status information of the first terminal from the first terminal, verify the received second certificate, and change the package status configuration information of the second terminal after verifying the second certificate.

[0018] Beneficial Effects

[0019] According to various embodiments of the present disclosure, a package installed in one device may be transferred and installed to another device in a secure and efficient manner, and after the transfer and installation are completed, the package status may be configured.

[0020] Furthermore, according to various embodiments of the present disclosure, a package installed in one device may be transferred and installed to another device in a secure and efficient manner, and after the transfer and installation are completed, the transfer result of the package may be registered in the server. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a conceptual diagram illustrating an SSP according to an embodiment of the present disclosure.

[0022] Figure 2 is a conceptual diagram showing the internal structure of an SSP according to an embodiment of the present disclosure.

[0023] Figure 3 is a diagram showing an example of components in a terminal for the terminal to download and install a package to an SSP according to an embodiment of the present disclosure.

[0024] Figure 4 is a diagram illustrating an example of a method in which two terminals operate with each other in order to transmit a packet between the two terminals according to an embodiment of the present disclosure.

[0025] Figure 5 is a diagram illustrating a configuration of a "proof" according to some embodiments of the present disclosure.

[0026] Figure 6 is a diagram conceptually illustrating a process for transmitting a packet from one terminal to another terminal according to an embodiment of the present disclosure.

[0027] Figure 7 It is shown Figure 6 A diagram of the detailed process of preparing for packet transmission during the process presented in FIG.

[0028] Figure 8 It is shown in Figure 6 A diagram showing the detailed process of sending a packet during the process presented in FIG.

[0029] Fig. 9 It is shown Figure 6 The figure shows the detailed process of packet transmission completion during the process presented in the figure.

[0030] Fig.10 It is shown Figure 6 Another detailed process diagram of the process of completing packet transmission during the process presented in FIG.

[0031] Fig.11 It is shown Figure 6Another detailed process diagram of the process of completing packet transmission during the process presented in FIG.

[0032] Fig.12 It is shown Figure 6 A diagram showing another detailed process of completing packet transmission in the process shown.

[0033] Fig.13 is a diagram showing an example of a process for making a package whose use has been suspended available again.

[0034] Fig.14 is a diagram showing an example of another process for making a package whose use has been suspended available again.

[0035] Fig.15 is a diagram showing an example of another process for making a package whose use has been suspended available again.

[0036] Fig.16 is a diagram showing a configuration of a terminal according to some embodiments of the present disclosure.

[0037] Fig.17 It is shown Figure 6 Another detailed process diagram of the process of completing packet transmission during the process presented in FIG.

[0038] Fig.18 is a diagram illustrating a configuration of a "proof" according to some embodiments of the present disclosure.

[0039] Fig.19 is a diagram conceptually illustrating a process for transmitting a packet from one terminal to another terminal according to an embodiment of the present disclosure.

[0040] Fig. 20 It is shown Fig.19 A diagram of the detailed process of preparing for packet transmission during the process presented in FIG.

[0041] Fig.21 It is shown in Fig.19 A diagram showing the detailed process of sending a packet during the process presented in FIG.

[0042] Fig. 22 It is shown in Fig.19 A diagram showing the detailed process of completing packet transmission during the process shown.

[0043] Fig.23 It is shown in Fig. 22 A diagram of the process of registering the packet transmission results in the server after the process presented in .

[0044] Fig.24 It is shown Fig.19 FIG. 4 is a diagram of another detailed process of completing the transmission of a packet during the process shown in FIG.

[0045] Fig.25 It is shown in Fig.24 A diagram of the process of registering the packet transmission results in the server after the process presented in .

[0046] Fig.26 It is shown Fig.19 FIG. 4 is a diagram of another detailed process of completing the transmission of a packet during the process shown in FIG.

[0047] Fig. 27 It is shown in Fig.26 A diagram of the process of registering the packet transmission results in the server after the process presented in .

[0048] Fig.28 is a diagram showing a configuration of a terminal according to some embodiments of the present disclosure.

[0049] Fig.29 is a diagram showing a configuration of a server according to some embodiments of the present disclosure.

[0050] Fig.30 It is shown in Fig.19 A diagram of another detailed process of a process of completing packet transmission and a process for registering a packet transmission result in a server among the processes presented in FIG. DETAILED DESCRIPTION

[0051] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0052] When 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 convey the main idea of ​​the present disclosure more clearly without obscuring the main idea of ​​the present disclosure by omitting unnecessary descriptions.

[0053] For the same reason, some components are exaggerated, omitted or schematically shown in the drawings. In addition, the size of each component does not fully reflect the actual size. In each figure, the same reference numerals represent the same or corresponding components.

[0054] The advantages and features of the present disclosure and methods for achieving them will become apparent with reference to the embodiments described in detail below in conjunction with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below, but can be implemented in various different forms, and only these embodiments make the present disclosure complete, and these embodiments are provided to fully inform the scope of the present disclosure to those of ordinary skill in the art to which the present disclosure belongs, and the present disclosure is limited only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0055] In this case, it will be understood that each block of the message flow diagram and the combination of the message flow diagrams can be executed by computer program instructions. Because these computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, the instructions executed by the processor of the computer or other programmable data processing device generate means for performing the functions described in the (multiple) message flow diagram blocks. Because these computer program instructions can be stored in a computer-usable or computer-readable memory, which can instruct the computer or other programmable data processing device to implement the functions in a specific manner, the instructions stored in the computer-usable or computer-readable memory can generate a product containing instruction means for performing the functions described in the (multiple) message flow diagram blocks. Because the computer program instructions can be installed on a computer or other programmable data processing device, a series of operating steps are performed on the computer or other programmable data processing device to generate a computer-executed process; therefore, the instructions for executing the computer or other programmable data processing device can provide steps for performing the functions described in the (multiple) message flow diagram blocks.

[0056] In addition, each block may represent a module, a fragment or a part of a code including one or more executable instructions for performing a specified (multiple) logical function. In addition, it should be noted that in some alternative embodiments, the functions described in the block may not appear in order. For example, two blocks shown one by one may actually be performed substantially simultaneously, or these blocks may sometimes be performed in reverse order according to the corresponding functions.

[0057] In this case, the term "-unit" used in this embodiment means software or hardware components, such as FPGA or ASIC, and "-unit" performs certain roles. However, "-unit" is not limited to software or hardware. "-unit" can be configured to reside in an addressable storage medium, or can be configured to copy one or more processors. Therefore, as an example, "unit" includes components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcodes, circuits, data, databases, data structures, tables, arrays and variables such as software components, object-oriented software components, class components and task components. The functions provided in components and "-units" can be combined into smaller numbers of components and "-units", or can be further divided into additional components and "-units". In addition, components and "-units" can be implemented to copy one or more CPUs in a device or a secure multimedia card.

[0058] In addition, in the present disclosure, each embodiment is described by taking SSP as an example of a security medium, but the scope of the present disclosure is not limited to the scope of SSP. For example, it is obvious to those skilled in the art that the various embodiments to be described below can be applied substantially the same as or similar to other security media that perform substantially the same or similar functions as SSP.

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

[0060] "Secure Element (SE)" refers to a security module configured as a single chip that can store security information (e.g., mobile communication network access keys, user identification information such as ID / passport, credit card information, encryption keys, etc.), and can use the stored security information to install and operate control modules (e.g., network access control modules such as USIM, encryption modules, key generation modules, etc.). SE can be used in various electronic devices (e.g., smart phones, tablet PCs, wearable devices, cars, IoT devices, etc.), and provides security services (e.g., mobile communication network access, payment, user authentication, etc.) through security information and control modules.

[0061] SE can be divided into universal integrated circuit card (UICC), embedded security element (eSE) and smart security platform (SSP). The smart security platform is an integrated form of UICC and eSE, and can be subdivided into removable, embedded and integrated types. They are integrated into specific components or system on chip (SoC) according to the type of connection or installation in the electronic device.

[0062] "Universal Integrated Circuit Card (UICC)" is a smart card inserted and used in a mobile communication terminal, and may be referred to as a UICC card. UICC may include an access control module for accessing a network of a mobile communication service provider. Examples of access control modules may include a universal user identity module (USIM), a user identity module (SIM), and an IP multimedia service identity module (ISIM). UICCs including USIMs are generally referred to as USIM cards. Similarly, UICCs including SIM modules are generally referred to as SIM cards. SIM modules may be loaded when UICCs are produced, or SIM modules of mobile communication services that users want to use at a desired time may be downloaded to UICC cards. UICC cards may be used by downloading and installing multiple SIM modules and selecting at least one of them. Such UICC cards may or may not be fixed to a terminal. A UICC fixed to a terminal and used in a terminal is referred to as an embedded UICC (eUICC), and in particular, a UICC built into a communication processor, an application processor, or a system on chip (SoC) of a terminal may be referred to as an integrated UICC (iUICC), which includes a single processor structure in which two processors are integrated. Generally, eUICC and iUICC may refer to a UICC card that is fixed to a terminal and used, and can be selected by remotely downloading a SIM module. In the present disclosure, UICC cards that can remotely download and select a SIM module are collectively referred to as eUICC or iUICC. That is, in a UICC card that can be selected by remotely downloading a SIM module, a UICC card that is fixed or not fixed to a terminal is collectively used as an eUICC or iUICC. In addition, the downloaded SIM module information is collectively used as the term eUICC profile, iUICC profile, or more simply, the term profile.

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

[0064] "Embedded Security Element (eSE)" refers to a fixed SE that is fixed to an electronic device for use. eSE is usually produced specifically for terminal manufacturers at the request of terminal manufacturers, and can be produced to include an operating system and a framework. eSE remotely downloads and installs a small application type service control module, and can be used for various security services such as electronic wallets, ticketing, electronic passports, and digital keys. In the present disclosure, single-chip type SEs attached to electronic devices that can remotely download and install service control modules are collectively referred to as eSEs.

[0065] "Smart Security Platform (SSP)" is capable of integrating UICC and eSE functions in a single chip, and can be divided into removable SSP (rSSP), embedded SSP (eSSP) and integrated SSP (iSSP) embedded in SoC. The SSP may include a main platform (PP) and at least one secondary platform package (SPB) operating on the PP, and the main platform may include at least one of a hardware platform or a low-level operating system (LLOS), and the secondary platform package may include a high-level operating system (HLOS) or at least one of the applications running on the HLOS. The secondary platform package is also called an SPB or a package. The package can access resources such as the central processor and memory of the PP through the main platform interface (PPI) provided by the PP, thereby running on the PP. In the package, communication applications such as a subscriber identity module (SIM), a universal SIM (USIM) and an IP multimedia SIM (ISIM) can be loaded, and various applications such as electronic wallets, ticketing, electronic passports, digital keys, etc. can be loaded. In the present disclosure, SSP may be referred to as a smart security medium.

[0066] Depending on the package to be downloaded and installed, the SSP can be used for the above-mentioned UICC or eSE purposes, and multiple packages can be installed in a single SSP and operated simultaneously to mix the use of UICC and eSE. That is, when the package including the profile operates, the SSP can be used as a UICC for accessing the network of the mobile communication service provider. The corresponding UICC package can be operated by downloading and selecting at least one profile (such as eUICC or iUICC) into the package from the remote end. In addition, when a package including a service control module (the service control module is loaded with an application that can provide services such as an electronic wallet, ticketing, electronic passport, or digital key) operates on the SSP, the SSP can be used for the purpose of eSE. Multiple service control modules can be integrated, installed and operated in one package, or can be installed and operated as independent packages.

[0067] The SSP may be installed by downloading a package from a secondary platform package manager (SPB manager) using an over-the-air (OTA) technology, or a package to be installed may be received from another terminal. In the present disclosure, the method of installing a downloaded or received package may be equally applicable to a removable SSP (rSSP) that can be inserted into and removed from a terminal, a fixed SSP (eSSP) that can be installed in a terminal, and an integrated SSP (iSSP) included in a SoC installed in a terminal.

[0068] "SSP Identifier (SSPID)" is an object identifier of an SSP embedded in a terminal, and may be referred to as sspID. In addition, when the terminal and the SSP chip are not separated, as in an embodiment of the present disclosure, the SSPID may be a terminal ID. In addition, the SSPID may refer to a specific package identifier (SPB ID) in the SSP. In more detail, the SSPID may refer to a package identifier of a management package or a secondary platform package loader (SPBL), which installs other packages in the SSP and manages the activation, deactivation, and deletion of other packages. In addition, the SSPID may refer to a primary platform identifier in the SSP. An SSP may have multiple SSP identifiers, and the multiple SSP identifiers may be values ​​derived from a single unique SSP identifier.

[0069] A "Secondary Platform Package (SPB)" is driven using the resources of the Primary Platform (PP) of the SSP, for example, a UICC package may mean that applications, file systems, authentication key values, etc. stored in an existing UICC, and the operating system (HLOS) in which they operate are packaged into a software form. In the present disclosure, an SPB may be referred to as a package.

[0070] In the present disclosure, the "state" of a terminal may be as follows.

[0071] [Enable]

[0072] In the present disclosure, the operation of enabling a package by a terminal or an external server may mean an operation of configuring the terminal to receive a service provided by the package (e.g., a communication service, a credit card payment service, a user authentication service, etc.) by changing the state of the corresponding SPB to enabled. A package in an enabled state may be represented as an "enabled package". A package in an enabled state may be stored in a storage space inside or outside the SSP in an encrypted state.

[0073] [Activity]

[0074] According to the external input of the package (e.g., user input, push, application request in the terminal, authentication request from the communication operator, PP management message, etc.) or the operation inside the package (e.g., timer, polling), the package enabled in the present disclosure can be changed to an activity. An activity package can mean that the package is loaded from the storage space inside or outside the SSP into the active memory inside the SSP, uses the security CPU inside the SSP to process security information, and provides security services to the terminal.

[0075] [Disable]

[0076] In the present disclosure, the operation of disabling a package by a terminal or an external server may refer to an operation of configuring such that the terminal may not be able to receive the service provided by the package by changing the package state to disabled. A disabled SPB may be represented as a "disabled package". The disabled package may be stored in an encrypted state in a storage space inside or outside the SSP.

[0077] [delete]

[0078] In the present disclosure, the operation of deleting a package by a terminal or an external server may mean changing the state of the package to deleted or configuring the terminal or external server to no longer drive, enable or disable the operation of the package by deleting the relevant data of the package including the package. A package in a deleted state may be represented as a "deleted package".

[0079] "Package image (or image)" may be used interchangeably with package, or may be used as a term that represents a data object of a specific package, and may be referred to as a package TLV or a package image TLV. When a package image is encrypted using encryption parameters, it may be referred to as a protected package image (PBI) or a protected package image TLV (PBI TLV). When a package image is encrypted using encryption parameters that can only be decrypted by a specific SSP, it may be referred to as a bound package image (BBI) or a bound package image TLV (BBI TLV). A package image TLV may be a set of data that represents the information that constitutes a package in a TLV (tag, length, value) format.

[0080] "Packet delimiter" may be referred to as a matching factor of a packet identifier (SPB ID), a packet family identifier (SPB family ID), a packet family manager identifier (SPB family custodian object ID), a packet matching ID, an event identifier (event ID). The packet identifier (SPBID) may indicate an object identifier for each packet. The packet family identifier may indicate an identifier used to classify the type of packet (for example, a telecommunications packet for accessing a mobile communication company's network). In the present disclosure, the packet family identifier may be referred to as a family ID, Fid, or FID. The packet family manager identifier may indicate an identifier that identifies a subject that manages the packet family identifier (for example, a communication service provider, a terminal manufacturer, a specific organization, etc.). In the present disclosure, the packet family manager identifier may be referred to as OID or Oid. The packet delimiter may be used as a value that can index a packet in a packet management server or a terminal.

[0081] "Package metadata" is a term that refers to a set of information that can reference or describe a package. Package metadata can include the above-mentioned package delimiters. In addition, package metadata can also include information about the properties, characteristics, or configuration of the package. Package metadata can be denoted as "metadata".

[0082] The "package management server" may include the functions of generating a package according to a request from a service provider or other package management server, encrypting the generated package, generating a package remote management instruction, or encrypting the generated package remote management instruction. The package management server providing the above functions may be represented as at least one of a secondary platform package manager (SPBM), a remote package manager (RBM), an image delivery server (IDS), a subscription manager data preparation (SM-DP), a subscription manager data preparation enhancement (SM-DP+), a manager package server, a management subscription manager data preparation enhancement (management SM-DP+), a package encryption server, a package generation server, a package provider (BP), a package provider, or a package provisioning credential holder (BPC holder).

[0083] In the present disclosure, the package management server may perform functions of downloading, installing or updating packages from the SSP, and managing the configuration of keys and certificates for remote management of the package status. The package management server providing the above functions may be represented as at least one of a secondary platform package manager (SPBM), a remote package manager (RBM), an image delivery server (IDS), a subscription manager secure routing (SM-SR), a subscription manager secure routing enhanced (SM-SR+), an eUICC profile manager, or an off-card entity of a profile management credential holder (PMC holder), or an eUICC manager (EM).

[0084] In the present disclosure, an open relay server may receive an event registration request (register event request) from one or more package management servers or an open relay server. In addition, one or more open relay servers may be used in a complex manner, and in this case, the first open relay server may receive an event registration request not only from the package management server but also from the second open relay server. In the present disclosure, the functions of the open relay server may be integrated into the package management server. The open relay server providing the above functions may be represented as at least one of a secondary platform package manager (SPBM), a remote package manager (RBM), a secondary platform package discovery server (SPBDS), a package discovery server (BDS), a subscription manager discovery service (SM-DS), a discovery service (DS), a root SM-DS, or an alternative SM-DS.

[0085] In the present disclosure, a package management server may collectively refer to a combination of functions of generating, encrypting and transmitting packages or package remote management instructions and functions of managing SSP and configuration of installed packages. In addition, a package management server may collectively refer to the combined functions of an open relay server. Therefore, in various embodiments of the present disclosure, the operations of a package management server and an open relay server may be performed in one package management server. In addition, each function may be divided and performed by multiple package management servers separated from each other. In addition, in the specification of the present disclosure, a package management server or an open relay server may be represented as a package server. A package server may be one of a package management server and an open relay server, or may be a device including both a package management server and an open relay server.

[0086] "Service provider" may refer to a business entity that issues a request for package generation to a package management server and provides services to a terminal through a package. For example, a service provider may represent a mobile operator that provides communication network access services through a package in which a communication application is loaded, and may collectively refer to all of the business support system (BSS), operation support system (OSS), point of sale terminal (POS) and other IT systems of the communication operator. In addition, in the present disclosure, a service provider is not limited to representing only one specific business entity, but may be used as a term referring to a group or association (or consortium) of one or more business entities or a representative of the group or association. In addition, in the present disclosure, a service provider may be referred to as an operator (OP or Op.), a package owner (BO), an image owner (IO), etc., and each service provider may receive a configuration or allocation of at least one of a name and / or a unique identifier (OID). When a service provider refers to one or more business groups, associations or representatives, the name or object identifier of any group, association or representative may be a name or object identifier shared by all business entities affiliated with the group or association or all business entities cooperating with the representative.

[0087] "User" can be used as a term to refer to a service provider who owns the terminal or a terminal user who owns the terminal. Generally speaking, the former can be referred to as an M2M device, while the latter can be referred to as a consumer device. In the case of an M2M device, although it does not own the device, there may be a terminal user who transfers or leases the device from the service provider and uses it, and in this case, the user may be different from or the same as the service provider.

[0088] "User intent" can be used as a general term for the user's intent to manage a package locally or remotely. In addition, in the case of local management, user intent refers to the end-user intent, while in the case of remote management, user intent can be used as a term to refer to the service provider's intent.

[0089] "End-user consent" can be used as a term to indicate user consent to perform local or remote management.

[0090] "Terminal" may be used as a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, user unit, subscriber station (SS), wireless device, wireless communication device, wireless transmit / receive unit (WTRU), mobile node, mobile device or other terms. Various embodiments of the terminal may include a cellular phone, a smart phone with wireless communication function, a personal digital assistant (PDA) with wireless communication function, a wireless modem, a portable computer with wireless communication function, a photographing device such as a digital camera with wireless communication function, a game device with wireless communication function, a music storage and playback device with wireless communication function, an Internet home device capable of wirelessly accessing and browsing the Internet, and a portable unit or terminal incorporating a combination of these functions. In addition, the terminal may include a machine-to-machine (M2M) device and a machine type communication (MTC) terminal / device, but is not limited thereto. In the present disclosure, a terminal may be referred to as an electronic device.

[0091] In the present disclosure, an SSP that can be installed by downloading a package can be embedded in an electronic device. When the SSP is not embedded in the electronic device, the SSP physically separated from the electronic device can be inserted into the electronic device and connected to the electronic device. For example, the SSP can be inserted into the 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 that can be installed by downloading a package. The SSP can be embedded in the terminal, and when the terminal and the SSP are separated, the SSP can be inserted into the terminal, and can be inserted into the terminal to be connected to the terminal.

[0092] "Local Package Assistant (LBA)" may refer to software or an application installed in a terminal or electronic device in order to control an SSP. The software or application may be referred to as a Local Package Manager (LBM).

[0093] "Secondary Platform Package Loader (SPBL)" may refer to a management package that installs other packages in an SSP and manages their enabling, disabling, and deletion. An LBA of a terminal or remote server may install, enable, disable, or delete a specific package through a loader. In the present disclosure, the operation of a loader may be described as the operation of an SSP including the loader.

[0094] "Event" can be a general term for package download, remote package management or other package or SSP management / processing instructions. Events can be referred to as remote package supply operations (RBP operations or RBP operations) or event records, and each event can be referred to as data including a corresponding event identifier (event ID, EventID) or a matching identifier (matching ID, MatchingID), the address (FQDN, IP address or URL) of the package management server or open relay server storing the event, or at least one of each server identifier. Package download can be used interchangeably with package installation. In addition, event type can be used as a term to indicate whether a specific event is a package download, remote package management (e.g., delete, enable, disable, replace, update, etc.) or other package or SSP management / processing instructions, and can be referred to as an operation type (OperationType), an operation class (OperationClass), an event request type, an event class, an event request class, etc.

[0095] "Local Package Management (LBM)" may be referred to as package local management, local management, local management command, local command, local package management package (LBM package), package local management package, local management package, local management command package, or local command package. LBM may be used to install any package through software installed in a terminal, change the state of a particular package (enable, disable, delete), or update the content of a particular package (e.g., package nickname or package metadata, etc.). LBM may include one or more local management commands, and in this case, the package for each local management command may be the same or different for each local management command.

[0096] "Remote Package Management (RBM)" may be referred to as package remote management, remote management, remote management command, remote command, remote package management package (RBM package), package remote management package, remote management package, remote management command package, or remote command package. RBM may be used to install any package, change the state of a particular package (enable, disable, delete), or update the content of a particular package (e.g., package nickname or package metadata). RBM may include one or more remote management commands, and the package for each remote management command may be the same or different for each remote management command.

[0097] "Target package" may be used as a term to refer to a package that is to be the target of a local management command or a remote management command.

[0098] "Package rule" may be used as a term to refer to information that a terminal should recognize when performing local management or remote management on a target packet. In addition, the packet rule may be used interchangeably with terms such as packet policy, rule, and policy.

[0099] "Certificate" or digital certificate can refer to a digital certificate for mutual authentication based on an asymmetric key consisting of a pair of public keys (PK) and private keys (SK). Each certificate can include one or more public keys (PK), a public key identifier (PKID) corresponding to each public key, an identifier (certificate issuer ID) of the certificate issuer (CI) that issues the corresponding certificate, and a digital signature. In addition, the certificate issuer can be referred to as a certification issuer, a certificate authority (CA), a certification authority, etc. In the present disclosure, public key (PK) and public key identifier (PKID) can be used interchangeably and have the same meaning, which refers to a specific public key or a certificate including a public key, a part of a specific public key, a part of a certificate including a public key, an operation result (e.g., hash value) of a specific public key, an operation result (e.g., hash) value of a certificate including a corresponding public key, or an operation result (e.g., hash) value of a part of a specific public key, an operation result (e.g., hash) value of a part of a certificate including a corresponding public key, or a storage space for storing data.

[0100] When a certificate (primary certificate) issued by a "certificate issuer" is used to issue other certificates (secondary certificates), or when a secondary certificate is used to jointly issue a third-level or higher-level certificate, a "certificate chain" or certificate hierarchy can indicate the correlation between the corresponding certificates. In this case, the CI certificate used to issue the initial certificate can be referred to as a certificate root, a top-level certificate, a root CI, a root CI certificate, a root CA, or a root CA certificate.

[0101] In describing the present disclosure, when 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.

[0102] Hereinafter, various embodiments of a method and apparatus for moving and installing a package between terminals will be described.

[0103] Figure 1 is a conceptual diagram illustrating an SSP according to an embodiment of the present disclosure.

[0104] According to various embodiments, Figure 1 In the example of , 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 integrating the two processors. For another example, the SSP 120 may be a removable type 122 in the form of an independent chip that is not integrated into the SoC, or may be an embedded type 124 pre-embedded in the terminal 110.

[0105] According to various embodiments, the SSP 120 included in the terminal may include at least one of one or more telecommunication packages, one or more payment packages, or one or more electronic ID packages. Figure 1 As shown, when a plurality of telecommunication packages 140 and 150 are included in the SSP 120, the terminal 110 can use the mobile communication network by enabling the plurality of telecommunication packages 140 and 150 to operate simultaneously or in a time-division manner according to the configuration. In addition, when the payment package 170 and the electronic ID package 180 are included in the SSP 120, the terminal 110 can use the payment package 170 to use online payment through a terminal app (application) or use offline payment through an external credit card point of sale (PoS) device, and use the electronic ID package 180 to verify the identity of the terminal owner.

[0106] Figure 2 is a conceptual diagram showing the internal structure of a smart security platform (SSP) according to an embodiment of the present disclosure.

[0107] According to various embodiments, as in Figure 2 In the example of FIG. 1 , the SSP 210 may include a primary platform (PP) 220 and at least one secondary platform bundle (SPB) 230 and 240 operating thereon.

[0108] According to various embodiments, the host platform 220 may include hardware (not disclosed) and at least one low-level operating system (LLOS) 222 .

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

[0110] According to various embodiments, each of the secondary platform packages 230 and 240 may access resources such as a central processor and a memory of the main platform 220 using a main platform interface (PPI) 250 to be driven in the SSP 210 .

[0111] Figure 3 is a diagram illustrating an example of internal components of a terminal for enabling the terminal to download a package to an SSP and install the package in the SSP according to an embodiment of the present disclosure.

[0112] According to various embodiments, Figure 3 In an example, the terminal 310 may include the SSP 330 and / or the LBA 312 for controlling the SSP 330. For example, the terminal 310 may be a terminal in which the SSP 330 is installed and in which the LBA 312 for controlling the SSP 330 is installed. For example, the SSP 330 may be embedded in the terminal 310, or may be removable from the terminal 310.

[0113] According to various embodiments, SSP 330 may include at least one of a main platform 331 , a secondary platform package loader (SPBL) 333 , or one or more secondary platform packages 335 , 337 , or 339 .

[0114] According to various embodiments, the secondary platform package 335, 337, or 339 may not be installed inside the SSP 330 when the terminal is released, but may be remotely downloaded and installed after release.

[0115] According to various embodiments, Figure 3 In the example of FIG. 3 , each package may have a different package family identifier and / or package family manager identifier 341, 342, or 343. These package family identifiers and package family manager identifiers may be used as information required to download and install the package. That is, SSP 330 or SPBL 333 may allow or deny downloading and installation of a specific package based on the package family identifier and the package family manager identifier.

[0116] Figure 4 is a diagram illustrating an example of a method in which two terminals operate with each other in order to transmit a packet between the two terminals according to an embodiment of the present disclosure.

[0117] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Figure 4 In the example of , the first terminal 400 may include an LBA 410 and an SSP 420, and the second terminal 450 may include an LBA 460 and an SSP 470.

[0118] According to various embodiments, a user may send a command to a terminal, or may receive information that the user should receive from a terminal. For example, as in operations 4010 and 4060, a first user 440 and a second user 490 may send a command to LBAs 410 and 460 of a first terminal 400 and a second terminal 450, or may receive information that the user should receive from LBAs 410 and 460.

[0119] According to various embodiments, the above operation may include a process in which a user selects a package to be sent. In addition, the above operation may also include a process in which information of a package to be sent by the user is identified. In addition, the above operation may also include an operation of approving whether to send a package to be sent by the user. In addition, the above operation may also include an operation of approving whether to send a package to be received by the user.

[0120] Furthermore, according to various embodiments, the above operations may include a process in which the user selects a package in order to resume use of the suspended package. Furthermore, the above operations may also include a process in which information about the package for which the user has received a request to resume use may be identified. Furthermore, the above operations may also include an operation in which the user is approved to use the package again. Furthermore, the above operations may also include an operation in which the user approves to resume use of the package for which the request to resume use has been received.

[0121] The above-mentioned operations of selection and approval may not all be operated as independent operations, and one or more operations may be selected and operated independently of each other.

[0122] Furthermore, in operations 4020 and 4070 , the LBAs 410 and 460 may issue commands to the SSPs 420 and 470 , or may transmit and receive data to and from the SSPs 420 and 470 .

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

[0124] 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, as a result, the LBA may receive a result transmitted by the SSP.

[0125] According to various embodiments, in the above operation, the LBA may define new commands and data based on a user's command or a command or data received from another terminal or an external server, and transmit them to the SSP. In the above operation, when the LBA defines new commands and data based on a user's command or a command or data received from another terminal or an external server and transmits them to the SSP, as a result, the LBA may receive a result transmitted by the SSP.

[0126] According to various embodiments, in the above operations, the LBA and the SSP may transmit and receive data to and from each other, and install a package.

[0127] According to various embodiments, in operation 4050, the two LBAs 410 and 460 may be connected to each other to give a command to each other, or to send and receive data to and from each other. In this case, the connection in operation 4050 may be a direct device-to-device connection between terminals, and although not shown, it may be an indirect connection between devices in which an external entity (e.g., an external server) is connected between the two LBAs 410 and 460.

[0128] A more detailed description of the above-mentioned connection method between two LBAs is given with reference to the following drawings.

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

[0130] According to various embodiments, in the above operations, the SSP may identify a packet transmission configuration. In addition, in the above operations, the SSP may generate and utilize a packet transmission code. The above packet transmission configuration related operations and the packet transmission code related operations are independent functions, and the two functions may not be performed, either of the two functions may be performed, or both of the two functions may be performed. Even when both functions are performed, the two functions may be performed as completely independent functions.

[0131] According to various embodiments, in the above operation, the SSP may generate its SSP information, or verify the SSP information received from the counterpart terminal and / or server. In addition, in the above operation, the SSP may generate authentication data capable of verifying itself, or may verify the authentication data received from the counterpart terminal.

[0132] According to various embodiments, in the above operation, the SSP may generate a reference Figure 5 The "proof" described in the SSP and verifies the received "proof". Examples of various "proofs" that the SSP can generate / verify are described later. Figures 10 to 15 and 22 to 27.

[0133] According to various embodiments, in the above operation, the SSP may configure the state of the package. The states and configuration conditions of various packages that can be configured by the SSP refer to the following description. Figures 10 to 15 and 22 to 27.

[0134] According to various embodiments, in the above operations, the SSP may generate a packet.

[0135] Figure 5 is a diagram illustrating a configuration of a "proof" according to some embodiments of the present disclosure.

[0136] According to various embodiments, the proof may optionally include a "packet delimiter" (510). For example, the proof may optionally include a packet identifier (SPB ID), which is one of the packet delimiters, such as Figure 5 shown.

[0137] According to various embodiments, the proof may optionally further include another proof (530). Various examples of another proof included in the proof are described later. Figure 10-15 Description.

[0138] According to various embodiments, the certificate may optionally further include an "SSP Identifier (SSPID)" (540).

[0139] According to various embodiments, the proof may optionally further include information about operations performed by the SSP (550). Various examples of operations performed by the SSP are described later. Figures 10 to 15 Description.

[0140] According to various embodiments, if necessary, the proof may optionally further include data (520) in addition to the above-mentioned proofs 530, 540, and 550. Various examples of other data that may be included in the proof are described later. Figure 10-15 Description.

[0141] According to various embodiments, the proof may include digital signature data (560) of the above information. The signature data may be an electronic signature generated by a signing certificate of the SSP.

[0142] Figure 6 is a diagram conceptually illustrating a process for transmitting a packet from one terminal to another terminal according to an embodiment of the present disclosure.

[0143] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Figure 6 In the example of , the first terminal 600 may include a first LBA 620 and a first SSP 610, and the second terminal 650 may include a second LBA 670 and a second SSP 660. For example, the first terminal 600 may be a terminal in which the first SSP 610 is installed and in which the first LBA 620 for controlling the first SSP 610 is installed, and the second terminal 650 may be a terminal in which the second SSP 660 is installed and in which the second LBA 670 for controlling the second SSP 660 is installed.

[0144] refer to Figure 6 In step 6000, the first SSP 610 and the first LBA 620 of the first terminal 600 and the second LBA 670 of the second terminal 650 may perform a preparation process (packet transmission preparation process) required for packet transmission. For a more detailed description of this process, refer to the later described Figure 7 Detailed description.

[0145] refer to Figure 6 In step 6005, a process (packet transmission process) of sending a packet from the first terminal 600 to the second terminal 650 may be performed. A more detailed description of this process is provided in detail later. Figure 8 Detailed description.

[0146] refer to Figure 6 In step 6010, the first terminal 600 and the second terminal 660 may perform the installation process of the sent package and the process of configuring the status of the package (package transmission completion process). The detailed description of the process is referred to in the following description. Figures 9 to 12 Detailed description.

[0147] Figure 7 It is shown Figure 6 More specifically, Figure 7 1 is a diagram exemplarily illustrating a process in which a terminal undergoes a preparation process required to send a packet to another terminal according to an embodiment of the present disclosure. Figure 7 The process may be referred to as a packet transmission preparation process.

[0148] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Figure 7 In the example of , the first terminal 700 may include a first LBA 720 and a first SSP 710, and the second terminal 750 may include a second LBA 770 and a second SSP 760. For example, the first terminal 700 may be a terminal in which the first SSP 710 is installed and in which the first LBA 720 for controlling the first SSP 710 is installed, and the second terminal 750 may be a terminal in which the second SSP 760 is installed and in which the second LBA 770 for controlling the second SSP 760 is installed.

[0149] According to various embodiments, the first terminal 700 may have a pre-installed package and also have metadata associated with the package.

[0150] According to various embodiments, the first terminal 700 may be associated with the corresponding package to have at least one of a package identifier (SPBID), a package family identifier (SPB family ID), or a package family manager identifier (SPB family custodian object ID).

[0151] According to various embodiments, the first terminal 700 may have a "packet transmission configuration" associated with the corresponding packet. The packet transmission configuration may optionally contain information related to whether the packet can be sent between devices. In addition, the packet transmission configuration may optionally further include information about whether the packet can be reused in multiple terminals. For example, when a packet is "prohibited from being reused in multiple terminals at the same time", that is, when "a packet should only be used in one terminal at any one time", the packet transmission configuration may include information about this.

[0152] refer to Figure 7In step 7000, information about packets to be sent between devices may be transferred to the first LBA 720. For example, Figure 7 As shown, the transmission process can be performed through a process in which the user directly selects a package through a UI provided by the first terminal 700, or can be input from a remote server to the first LBA 720 through push input, or the first LBA 720 can access the remote server to read the corresponding information.

[0153] refer to Figure 7 At step 7005, information associated with the packet selected by step 7000 may be transferred from the first LBA 720 to the first SSP 710. For example, Figure 7 As shown, information related to the selected packet may be transferred from the first LBA 720 to the first SSP 710 through the Select SPB command. In this case, the information transferred from the first LBA 720 to the first SSP 710 may include information for identifying the packet selected in step 7000.

[0154] refer to Figure 7 In step 7010, the first SSP 710 may identify whether the packet requested to be transmitted can be transmitted between devices. This process may be performed by identifying the packet in which transmission is requested based on the information received in step 7005 and identifying the "packet transmission configuration" associated with the packet. In this process, when the "packet transmission configuration" includes "information on whether the packet can be reused in multiple terminals", the first SSP 710 may recognize this fact.

[0155] In addition, in step 7010, the first SSP 710 may optionally configure a "packet transmission code". The "packet transmission code" is a code used to refer to a packet in the process of sending a packet between devices, and should be a value capable of identifying the packet. The first SSP 710 may bind the above-mentioned "packet transmission code" and information of the packet to be sent.

[0156] refer to Figure 7 In step 7015, the response result to step 7005 can be sent from the first SSP 710 to the first LBA 720. For example, Figure 7 As shown, a response to the Select SPB command may be transmitted from the first SPB 710 to the first LBA 720 via a Select SPB Response. The response value may include the “Packet Transfer Code” described in step 7010.

[0157] refer to Figure 7, in step 7020, information required for packet transmission between devices may be transmitted from the first LBA 720 of the first terminal 700 to the second LBA 770 of the second terminal 750. In this case, the information transmitted from the first LBA 720 to the second LBA 770 may include a "packet transmission code". In addition, the information transmitted from the first LBA 820 to the second LBA 870 may optionally further include information required for a connection to be established between the first LBA 720 and the second LBA 770 in a future step 7025. In addition, the information transmitted from the first LBA 720 to the second LBA 770 may optionally further include information indicating that packet transmission between devices is to be performed.

[0158] The information transmitted from the first LBA 720 to the second LBA 770 through the above step 7020 may be transmitted in various ways. For example, the first LBA 720 may provide the user with the information to be transmitted to the second LBA 770 through the UI of the first terminal 700, and the user may input the received information to the second LBA 770 using the UI of the second terminal 750. Alternatively, the first LBA 720 may make the information to be transmitted to the second LBA 770 in the form of an image (e.g., a QR code) to display the image on the screen of the first terminal 700, and the user may scan the image using the second terminal 750 to transmit the information to the second LBA 770. However, the method of transmitting information from the first LBA 720 to the second LBA 770 is not limited to the above method.

[0159] refer to Figure 7 In step 7025, a connection may be established (or configured) between the first LBA 720 and the second LBA 770. When the information required for the connection is sent in step 7020, the first LBA 720 and the second LBA 770 may establish a connection using the 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 may be a remote connection in which a remote server (e.g., a relay server) is located between the first LBA 720 and the second LBA 770.

[0160] refer to Figure 7Although step 7025 is shown as the last step, this step is independent of the other steps described above, namely steps 7000, 7005, 7010, 7015, and 7020, and can be performed without regard to the order of the other steps. For example, step 7025 can be performed between steps 7015 and 7020, in which case the information sent from the first LBA 720 to the second LBA 770 in step 7020 can be sent via the connection established in step 7025.

[0161] Figure 8 It is shown Figure 6 More specifically, Figure 8 Schematic diagram showing a process of sending a packet from one terminal to another terminal according to an embodiment of the present disclosure. Figure 8 The process can be referred to as a packet transmission process.

[0162] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Figure 8 In the example of , the first terminal 800 may include a first LBA 820 and a first SSP 810, and the second terminal 850 may include a second LBA 870 and a second SSP 860. For example, the first terminal 800 may be a terminal in which the first SSP 810 is installed and in which the first LBA 820 for controlling the first SSP 810 is installed, and the second terminal 850 may be a terminal in which the second SSP 860 is installed and in which the second LBA 870 for controlling the second SSP 860 is installed.

[0163] refer to Figure 8 In step 8000, the second LBA 870 may request “SSP information (SspInfo)” from the second SSP 860. When the second LBA 870 requests “SspInfo” from the second SSP 860 in step 8000, the second LBA 870 may inform the second SSP 860 that packet movement between devices will be performed.

[0164] In addition, step 8000 can be Figure 8 The process shown in the figure is automatically executed immediately after the process is completed, or it can be executed after receiving external input. In this case, the "external input" can be performed by a process in which the user directly selects the package to be received through the UI provided by the second terminal 850, or it can be input from the remote server to the second LBA 870 through push input, or the second LBA 870 can access the remote server to read the corresponding information.

[0165] refer to Figure 8In step 8005, the second SSP 860 may generate its "SspInfo". "SspInfo" may include information about the second SSP to be provided for packet transmission. In this case, "SspInfo" may include information (certificate negotiation information) for a certificate negotiation process (which the second SSP 860 should undergo before receiving the packet). "Certificate negotiation information" may include certificate information (SenderSpblVerification) that the second SSP 860 may use to verify another SSP and certificate information (ReceiverSpblVerification) that another SSP may use to verify itself. In addition, "Certificate negotiation information" may optionally further include a list of key negotiation algorithms supported by the second SSP 860, and may optionally further include a list of encryption algorithms supported by the second SSP 860. In addition, "SspInfo" may optionally further include SSP version information, which includes at least one of version information of standard specifications supported by the loader and the main platform included in the second SSP 960.

[0166] refer to Figure 8 In step 8010, the second SSP 860 may transmit the “SspInfo” generated in step 8005 to the first SSP 810 through the second LBA 870 and the first LBA 820.

[0167] According to the above steps 8000 to 8010, the second LBA 870 may request the second SSP 860 for “SspInfo”, the second SSP 860 may generate its “SspInfo”, and then transmit the “SspInfo” to the first SSP 810 through the second LBA 870 and the first LBA 820. However, according to this embodiment, the process of transmitting the “SspInfo” from the second terminal 850 to the first terminal 800 may be as follows. For example, after the second LBA 870 generates the “SspInfo” itself, the second LBA may transmit the “SspInfo” to the first SSP 810 through the first LBA 820.

[0168] refer to Figure 8 In step 8015, the first SSP 810 may identify the received "SspInfo" and generate "first terminal authentication information (Device1.Auth)", based on which it can authenticate itself. A more detailed process of this process is as follows.

[0169] The first SSP 810 may use the received “SenderSpblVerification” to identify certificate information capable of verifying itself, and select at least one key agreement certificate (ssp1.Cert.KA). Alternatively, the first SSP 810 may use the received “key agreement algorithm list supported by the second SSP 860” to generate a public key “ssp1.ePK.KA” and a private key “ssp1.eSK.KA” as an asymmetric encryption key pair to be used for key agreement, and then select the public key (ssp1.ePK.KA) in the key pair. In addition, the first SSP 810 may use the received “SenderSpblVerification” to identify certificate information capable of verifying itself, and further select at least one signature certificate (ssp1.Cert.DS).

[0170] In addition, the first SSP 810 may select at least one certificate information of the second SSP 860 to perform verification using the received 'ReceiverSpblVerification' and then configure the corresponding information as 'CiPkIdToBeUsed'.

[0171] In addition, the first SSP 810 may use the received “encryption algorithm list supported by the second SSP 860” to select at least one encryption algorithm to be used in the future, and then configure the corresponding information as “CryptoToBeUsed”.

[0172] Furthermore, the first SSP 810 may identify the received list of “version information of standard specifications supported by the loader and the main platform included in the second SSP 860” and identify whether a version of the standard specification supported by itself exists in the list.

[0173] The "first terminal authentication information (Device1.Auth)" may include at least one of the "ssp1.Cert.KA", "ssp1.ePK.KA", "CiPkIdToBeUsed" or "CryptoToBeUsed" described above. In addition, the "first terminal authentication information (Device1.Auth)" may optionally further include the above-mentioned "ssp1.Cert.DS". In addition, the "first terminal authentication information (Device1.Auth)" may optionally further include at least one of a packet family identifier (SPB family ID) or a packet family manager identifier (SPB family custodian object ID) associated with the packet to be transmitted in the future.

[0174] In this case, all or part of the above-mentioned "first terminal authentication information (Device1.Auth)" may be a digital signature that can be verified using ssp1.Cert.DS to ensure the integrity of the information, and the digital signature data may be added as part of the "first terminal authentication information".

[0175] refer to Figure 8 In step 8020 , the first SSP 810 may transmit the “first terminal authentication information (Device1.Auth)” generated in step 8015 to the second LBA 870 via the first LBA 820 .

[0176] refer to Figure 8 In step 8025, the second LBA 870 may transmit the “first terminal authentication information (Device1.Auth)” to the second SSP 860. In addition, the second LBA 870 may also transmit the “packet transmission code” to the second SSP 860.

[0177] refer to Figure 8 , in step 8030, the second SSP 860 may verify the received "first terminal authentication information (Device1.Auth)". When the second SSP 860 receives "ssp1.Cert.KA", the second SSP 860 may identify the signature of the corresponding certificate to identify the validity of the certificate. In addition, when the second SSP 860 receives "ssp1.ePK.KA" and its digital signature, the second SSP 860 may first check the validity of ssp1.Cert.DS, and then use the certificate to identify the digital signature, thereby identifying the integrity of the received public key ssp1.ePK.KA. In addition, the second SSP 860 may identify the received "CiPkIdToBeUsed" and select at least one signed certificate (ssp2.Cert.DS) that can verify itself.

[0178] In addition, although not shown in the figure, in step 8030, the second SSP 960 may generate a public key "ssp2.ePK.KA" and a private key "ssp2.eSK.KA" as a key pair for asymmetric encryption to be used for key negotiation, and then select a public key (ssp2.ePK.KA) in the key pair. In addition, the second SSP 860 may select ssp1.ePK.KA or one of the public keys for key negotiation included in ssp1.Cert.KA, and then generate a session key ShKey01, which will be used for encryption in the future while using this value and ssp2.eSK.KA to communicate with the first terminal. ShKey01 should be a session key for the encryption algorithm included in the received "CryptoToBeUsed".

[0179] Furthermore, 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". Furthermore, the "second terminal authentication information (Device2.Auth)" may also include "ssp2.ePK.KA". Furthermore, the "second terminal authentication information (Device2.Auth)" may further include a transaction ID indicating a current session generated by the second SSP 860. Furthermore, the "second terminal authentication information (Device2.Auth)" may also include a "package transfer code". Furthermore, the "second terminal authentication information (Device2.Auth)" may further include an SSP identifier of the second SSP 960. Furthermore, the "second terminal authentication information (Device2.Auth)" may optionally further include at least one of a package family identifier (SPB family ID) or a package family manager identifier (SPB family custodian object ID) associated with a package to be transmitted in the future.

[0180] In this case, part or all of the above-mentioned "second terminal authentication information (Device2.Auth)" can be a digital signature that can be verified using ssp2.Cert.DS to ensure the integrity of the information, and the digital signature data can be added as part of the "second terminal authentication information". In addition, part or all of the "second terminal authentication information (Device2.Auth)" can be encrypted using the previously generated session key ShKey01.

[0181] refer to Figure 8 In step 8035, the second SSP 860 may send the "second terminal authentication information (Device2.Auth)" generated in step 8030 to the first SSP 810 via the second LBA 870 and the first LBA 820. In this case, a "packet transmission code" may be further sent optionally.

[0182] refer to Figure 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 signature of the received "ssp2.Cert.DS" to verify the validity of the corresponding certificate. In addition, the first SSP 810 may check whether the received package family identifier (SPB family ID) and / or package family manager identifier (SPB family custodian object ID) are correctly configured values ​​associated with the package to be sent by itself. 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 to the currently ongoing session or the package to be sent.

[0183] In this process, when the encrypted data is included in the "second terminal authentication information (Device2.Auth)", the first SSP 810 can use ssp1.eSK.KA or a private key corresponding to the public key for key negotiation included in its ssp1.Cert.KA and the received ssp2.ePK.KA to generate a session key ShKey01, decrypt the encrypted data using the session key, and then perform a verification process. In addition, in this process, when the digital signature is included in the "second terminal authentication information (Device2.Auth)", the first SSP 810 can use "ssp2.Cert.DS" to verify the validity of the received digital signature.

[0184] Furthermore, in step 8040, although Figure 8Although not shown in the figure, the first SSP 810 can generate a public key "ssp1.bundle.ePK.KA" and a private key "ssp1.bundle.eSK.KA" as a key pair for asymmetric encryption to be used for key negotiation. In this case, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" can be configured to the same value as the previously generated "ssp1.ePK.KA and ssp1.eSK.KA". Alternatively, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" can be configured to the same value as the value of "the public key included in the previously used ssp1.Cert.KA and the corresponding private key". In addition, the first SSP 810 can generate a session key ShKey02 using ssp1.bundle.eSK.KA and ssp2.ePK.KA. When the "private key corresponding to the public key included in ssp1.Cert.Ka" or ssp1.eSK.KA for ssp1.bundle.eSK.KA is reused, the value of the session key ShKey02 can also be configured to the value of ShKey01 generated previously.

[0185] In addition, in step 8040, the first SSP 810 may configure a package to be sent to the second terminal 850 and / or metadata associated with the package. In this case, the first SSP 810 may use the received "package transmission code" to identify the package to be sent by itself. In addition, the package to be configured may include "ssp1.Cert.DS". In addition, the package to be configured may also include "ssp1.bundle.ePK.KA". In addition, the package to be configured may also include a transaction ID for identifying a corresponding session. In addition, the package to be configured may optionally further include at least one of a package identifier (SPB ID), a package family identifier (SPB family ID), or a package family manager identifier (SPB family custodian object ID) associated with the package to be transmitted. According to various embodiments, the package configured in step 8040 (or metadata associated with the package) may include "package transmission configuration".

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

[0187] refer to Figure 8In step 8045, the first SSP 810 may transmit the packet generated (configured) in step 8040 to the second LBA 870 via the first LBA 820. In this case, metadata associated with the transmitted packet may be further transmitted selectively. In addition, a "packet transmission configuration" associated with the transmitted packet may be further transmitted. For example, the "packet transmission configuration" may be transmitted in a separate format (e.g., a message) without being included in the packet or metadata.

[0188] Fig. 9 It is shown Figure 6 The detailed process of the process of completing the transmission of the packet in the process presented in FIG. More specifically, Fig. 9 One possible example of a diagram illustrating a process of installing a package in a terminal and a process of configuring a package state after sending the package according to an embodiment of the present disclosure is shown.

[0189] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig. 9 In the example of , the first terminal 900 may include a first LBA 920 and a first SSP 910, and the second terminal 950 may include a second LBA 970 and a second SSP 960. For example, the first terminal 900 may be a terminal in which the first SSP 910 is installed and in which the first LBA 920 for controlling the first SSP 910 is installed, and the second terminal 950 may be a terminal in which the second SSP 960 is installed and in which the second LBA 970 for controlling the second SSP 960 is installed.

[0190] 1. Installing Packages

[0191] refer to Fig. 9In step 9000, the second LBA 970 and the second SSP 960 may cooperate with each other to install the package in the second terminal 950. In this process, the following steps may be performed together. When sending metadata, the second LBA 970 or the second SSP 960 may verify the content included in the metadata. When sending "Package Transfer Configuration", the second LBA 970 may transfer information to the second SSP 960. When sending a transaction ID, 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. When sending at least one of a package identifier (SPB ID), a package family identifier (SPB family ID), or a package family manager identifier (SPB family custodian object ID), the second LBA 970 or the second SSP 960 may identify whether the information matches the information of the package currently to be received. When sending ssp1.Cert.DS, the second SSP 960 may verify the validity of the certificate to authenticate the first SSP 910. When the received data includes encrypted data, the second SSP 960 can generate a session key ShKey02 using the received ssp1.bundle.ePK.KA and its ssp2.eSK.KA, decrypt the encrypted data using the session key, and then perform verification. When the received data includes a digital signature, the second SSP 960 can verify ssp1.Cer.DS and then verify the validity of the digital signature using the certificate.

[0192] 2. Identify whether the package can be reused

[0193] In addition, although not shown in the figure, the second LBA 970 and / or the second SSP 960 can selectively determine whether the packet can be reused in multiple terminals. Some possible determination methods are as follows. As one possible example, when the packet transmission configuration includes information about whether the packet can be reused in multiple terminals, the second LBA 970 and / or the second SSP 960 can identify the information to make a determination. As another possible example, the second LBA 970 and / or the second SSP 960 can use the received packet family identifier (SPB family ID) and / or the packet family manager identifier (SPB family custodian object ID) to identify whether the packet can be reused in multiple terminals. This process is part of step 9000 and can be performed regardless of the order of the processes performed in step 9000, or can be performed after step 9000.

[0194] 3. Configuration package status

[0195] If the packet can be reused in multiple terminals, the process of additionally configuring the packet state may not be necessary. Alternatively, even when the second LBA 970 and / or the second SSP 960 determines / does not determine whether the packet can be reused, depending on the implementation of the second LBA 970 and / or the second SSP 960, the process of additionally configuring the packet state may not be necessary.

[0196] Fig.10 It is shown Figure 6 Another detailed process diagram of the process of completing the transmission of the packet in the process presented in FIG. More specifically, Fig.10 is another example of a diagram illustrating a process of installing a package in a terminal and a process of configuring a package state after transmitting the package according to an embodiment of the present disclosure.

[0197] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.10 In the example of , the first terminal 1000 may include a first LBA 1020 and a first SSP 1010, and the second terminal 1050 may include a second LBA 1070 and a second SSP 1060. For example, the first terminal 1000 may be a terminal in which the first SSP 1010 is installed and in which the first LBA 1020 for controlling the first SSP 1010 is installed, and the second terminal 1050 may be a terminal in which the second SSP 1060 is installed and in which the second LBA 1070 for controlling the second SSP 1060 is installed.

[0198] 1. Installing Packages

[0199] refer to Fig.10 In step 10000, the second LBA 1070 and the second SSP 1060 may cooperate with each other to install the package in the second terminal 1050. For a detailed description, refer to Fig. 9 The "package installation" process.

[0200] 2. Identify whether the package can be reused

[0201] In addition, although not shown in the figure, the second LBA 1070 and / or the second SSP 1060 can selectively determine whether the packet can be reused in multiple terminals. Fig. 9 The process of "identifying whether a package can be reused".

[0202] 3. Configuration package status

[0203] If the packet cannot be reused in multiple terminals, the packet state is additionally configured as follows. Alternatively, even when the second LBA 1070 and / or the second SSP 1060 determines / uncertains whether the packet can be reused, the process of additionally configuring the packet state can be performed according to the implementation of the second LBA 1070 and / or the second SSP 1060, as described below.

[0204] refer to Fig.10 In step 10005, the second SSP 1060 may configure the package state as "in transition". "In transition" means a state in which the package has been successfully installed but is not yet available (in addition, a state that can be changed to an available state (disabled, enabled, active state) only by additional operations such as "a request from another terminal (for example, a request made by sending a "finalizationResponse" or a recoveryRequest") and / or "a request from an external server (although not described in the present disclosure)").

[0205] refer to Fig.10 , in step 10010, the second LBA 1070 may request “proof” from the second SSP 1060.

[0206] refer to Fig.10 , in step 10015, the second SSP 1060 may generate a "proof". Fig.10 In this case, the proof can be called a finalizationRequest. The structure of the proof can follow Figure 5 The structure disclosed in .

[0207] In this case, one example of a possible proof configuration is as follows.

[0208] -The finalizationRequest may include in 510 a "packet delimiter" for the packet.

[0209] - FinalizationRequest may include in 540 the "SSP Identifier" of the second SSP.

[0210] - FinalizationRequest may include information in 550 indicating that the second SSP has configured the package state to be a "transitioning" state.

[0211] - FinalizationRequest may optionally include in 520 the time at which the second SSP changed the state of the package to the "in transition" state or the time at which the proof was generated.

[0212] - FinalizationRequest may include signature information of the second SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the second SSP.

[0213] refer to Fig.10 In step 10020, the second SSP 1060 may transmit the finalizationRequest to the first SSP 1010. For example, the second SSP 1060 may transmit the finalizationRequest to the first SSP 1010 through the following process. That is, in response to step 10010, the second SSP 1060 may transmit the finalizationRequest to the second LBA 1070, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1020.

[0214] refer to Fig.10 , in step 10025, the first SSP 1010 may verify the received finalizationRequest. The verification process may include the step of checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may also include the process of checking whether the "packet delimiter" included in the finalizationRequest matches the packet delimiter of the corresponding packet. In addition, the verification process may also include the process of checking whether the "SSP identifier" included in the finalizationRequest is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information included in the finalizationRequest is instruction information for changing the packet state to the "transitioning" state.

[0215] Additionally, in step 10025, the first SSP 1010 may delete the package after the verification is complete.

[0216] Additionally, in step 10025, the first SSP 1010 may generate a "certificate". Fig.10 In , the proof can be called finalizationResponse. The structure of the proof can follow Figure 5 The structure disclosed in .

[0217] In this case, one example of a possible proof configuration is as follows.

[0218] The -finalizationResponse may include in 510 a "packet delimiter" for the packet.

[0219] - The finalizationResponse may include in 540 the "SSP Identifier" of the first SSP.

[0220] - The finalizationResponse may include information in 550 indicating that the first SSP has deleted the package.

[0221] - The finalizationResponse may optionally include in 520 the time at which the first SSP deleted the package or the time at which the proof was generated.

[0222] - FinalizationResponse may include signature information of the first SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the first SSP.

[0223] Furthermore, another example of a possible proof configuration is as follows.

[0224] - FinalizationResponse may include the received FinalizationRequest in 530. In this case, some information of the received FinalizationRequest may be omitted as needed. For example, in some cases, the signature information of the second SSP included in the FinalizationRequest may be omitted. In addition, for example, in some cases, the time information included in the FinalizationRequest may be omitted.

[0225] - The finalizationResponse may include in 540 the "SSP Identifier" of the first SSP.

[0226] - The finalizationResponse may include information in 550 indicating that the first SSP has deleted the package.

[0227] - The finalizationResponse may optionally include in 520 the time at which the first SSP deleted the package or the time at which the proof was generated.

[0228] - FinalizationResponse may include signature information of the first SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the first SSP.

[0229] refer to Fig.10In step 10030, the first SSP 1010 may transmit the finalizationResponse to the second SSP 1060. For example, the first SSP 1010 may transmit the finalizationResponse to the second SSP 1060 via the first LBA 1020 and the second LBA 1070.

[0230] refer to Fig.10 , in step 10035, the second SSP 1060 may verify the received finalizationResponse. The verification process may include the step of checking the validity of the signature of the first SSP contained in the finalizationResponse. In addition, the verification process may optionally further include the process of checking whether the "packet delimiter" included in the finalizationResponse matches the packet delimiter of the corresponding packet. In addition, the verification process may optionally further include the process of checking whether the finalizationRequest included in the finalizationResponse matches the information that it itself has sent. In addition, the verification process may also include the process of identifying the "SSP identifier" contained in the finalizationResponse. In addition, the verification process may also include the process of identifying whether the instruction information included in the finalizationResponse is the instruction information to delete the packet.

[0231] In addition, in step 10035, after the verification is completed, the second SSP 1060 can change the package state to one of the available states (one of disabled, enabled and active). For example, as shown in the figure, the second SSP 1060 can convert the package state to a disabled state.

[0232] refer to Fig.10 In step 10040 , the second SSP 1060 may send the result (eg, success or failure) of the operation performed in step 10035 to the second LBA 1070 .

[0233] Fig.11 It is shown Figure 6 Another detailed process diagram of the process of completing the transmission of the packet in the process presented in FIG. More specifically, Fig.11 is another example of a diagram illustrating a process of installing a package in a terminal and a process of configuring a package state after sending the package according to an embodiment of the present disclosure.

[0234] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.11In the example of , the first terminal 1100 may include a first LBA 1120 and a first SSP 1110, and the second terminal 1150 may include a second LBA 1170 and a second SSP 1160. For example, the first terminal 1100 may be a terminal in which the first SSP 1110 is installed and in which the first LBA 1120 for controlling the first SSP 1110 is installed, and the second terminal 1150 may be a terminal in which the second SSP 1160 is installed and in which the second LBA 1170 for controlling the second SSP 1160 is installed.

[0235] 1. Installing Packages

[0236] refer to Fig.11 In step 11000, the second LBA 1170 and the second SSP 1160 may cooperate with each other to install the package in the second terminal 1150. For a detailed description, refer to Fig. 9 The "package installation" process.

[0237] 2. Identify whether the package can be reused

[0238] In addition, although not shown in the figure, the second LBA 1170 and / or the second SSP 1160 can selectively determine whether the packet can be reused in multiple terminals. Fig. 9 The process of "identifying whether the package can be reused".

[0239] 3. Configuration package status

[0240] If the packet cannot be reused in multiple terminals, the packet state is additionally configured as follows. Optionally, even when the second LBA 1170 and / or the second SSP 1160 determines / uncertains whether the packet can be reused, the process of additionally configuring the packet state can be performed according to the implementation of the second LBA 1170 and / or the second SSP 1160, as described below.

[0241] refer to Fig.11 In step 11005, the second SSP 1160 may configure the packet status as "in transition". For a description of the "in transition" status, refer to the description of step 10005.

[0242] refer to Fig.11 , in step 11010, the second LBA 1170 may request “proof” from the second SSP 1160.

[0243] refer to Fig.11 , in step 11015, the second SSP 1160 may generate a "proof". Fig.11In , the proof can be called finalizationRequest. The structure of the proof can follow Figure 5 The structure disclosed in .

[0244] In this case, one example of a possible proof configuration is as follows.

[0245] -The finalizationRequest may include in 510 a "packet delimiter" for the packet.

[0246] - FinalizationRequest may include in 540 the "SSP Identifier" of the second SSP.

[0247] - FinalizationRequest may include information in 550 indicating that the second SSP has configured the package state to be a "transitioning" state.

[0248] - FinalizationRequest may optionally include in 520 the time at which the second SSP changed the state of the package to the "in transition" state or the time at which the proof was generated.

[0249] - FinalizationRequest may include signature information of the second SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the second SSP.

[0250] refer to Fig.11 In step 11020, the second SSP 1160 may transmit the finalizationRequest to the first SSP 1110. For example, the second SSP 1160 may transmit the finalizationRequest to the first SSP 1110 through the following process. That is, in response to step 11010, the second SSP 1160 may transmit the finalizationRequest to the second LBA 1170, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1120.

[0251] refer to Fig.11, in step 11025, the first SSP 1110 may verify the received finalizationRequest. The verification process may include the step of checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may also include the process of checking whether the "packet delimiter" included in the finalizationRequest matches the packet delimiter of the corresponding packet. In addition, the verification process may also include the process of checking whether the "SSP identifier" included in the finalizationRequest is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information included in the finalizationRequest is instruction information for changing the packet state to the "transitioning" state.

[0252] Furthermore, in step 11025, after the verification is completed, the first SSP 1110 may configure the package state to a "transitioning" state.

[0253] Additionally, in step 11025, the first SSP 1110 may generate a "proof". Fig.11 In , the proof can be called finalizationResponse. The structure of the proof can follow Figure 5 The structure disclosed in .

[0254] In this case, one example of a possible proof configuration is as follows.

[0255] The -finalizationResponse may include in 510 a "packet delimiter" for the packet.

[0256] - The finalizationResponse may include in 540 the "SSP Identifier" of the first SSP.

[0257] - The finalizationResponse may include in 550 information indicating that the first SSP has changed the state of the package to the "in transition" state.

[0258] The -finalizationResponse may optionally include in 520 the time at which the first SSP changed the state of the package or the time at which the proof was generated.

[0259] - FinalizationResponse may include signature information of the first SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the first SSP.

[0260] Furthermore, another example of a possible proof configuration is as follows.

[0261] - FinalizationResponse may include the received FinalizationRequest in 530. In this case, some information of the received FinalizationRequest may be omitted as needed. For example, in some cases, the signature information of the second SSP included in the FinalizationRequest may be omitted. In addition, for example, in some cases, the time information included in the FinalizationRequest may be omitted.

[0262] - The finalizationResponse may include in 540 the "SSP Identifier" of the first SSP.

[0263] - The finalizationResponse may include in 550 information indicating that the first SSP has changed the state of the package to the "in transition" state.

[0264] The -finalizationResponse may optionally include in 520 the time at which the first SSP changed the state of the package or the time at which the proof was generated.

[0265] - FinalizationResponse may include signature information of the first SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the first SSP.

[0266] refer to Fig.11 In step 11030, the first SSP 1110 may transmit the finalizationResponse to the second SSP 1160. For example, the first SSP 1110 may transmit the finalizationResponse to the second SSP 1160 via the first LBA 1120 and the second LBA 1170.

[0267] refer to Fig.11, in step 11035, the second SSP 1160 may verify the received finalizationResponse. The verification process may include the step of checking the validity of the signature of the first SSP included in the finalizationResponse. In addition, the verification process may optionally further include the process of checking whether the "packet delimiter" included in the finalizationResponse matches the packet delimiter of the corresponding packet. In addition, the verification process may optionally further include the process of checking whether the finalizationRequest included in the finalizationResponse matches the information sent by the second SSP 1160. In addition, the verification process may also include the process of identifying the "SSP identifier" included in the finalizationResponse. In addition, the verification process may further include the process of identifying whether the instruction information included in the finalizationResponse is correct.

[0268] In addition, in step 11035, after the verification is completed, the second SSP 1160 can change the package state to one of the available states (one of disabled, enabled and active). For example, as shown in the figure, the second SSP 1160 can convert the package state to a disabled state.

[0269] Additionally, in step 11035, the second SSP 1160 may generate a "proof". Fig.10 In , the proof can be called spblAttestation. The structure of the proof can be followed Figure 5 The structure disclosed in .

[0270] In this case, one example of a possible proof configuration is as follows.

[0271] -spblAttestation may include in 510 the "Packet Delimiter" of the packet.

[0272] -spblAttestation may include in 540 the "SSP Identifier" of the second SSP.

[0273] -spblAttestation may include information in 550 indicating that the second SSP has changed the package status to an available status.

[0274] -spblAttestation may optionally include in 520 the time at which the second SSP changed the state of the package or the time at which the attestation was generated.

[0275] - spblAttestation may include signature information of the second SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the second SSP.

[0276] Furthermore, another example of a possible proof configuration is as follows.

[0277] -spblAttestation may include the received finalizationResponse in 530. In this case, some information of the received finalizationResponse may be omitted as needed. For example, in some cases, portions of the signature information included in the finalizationResponse may be omitted. In addition, for example, portions of the time information included in the finalizationResponse may be omitted in some cases.

[0278] -spblAttestation may include in 540 the "SSP Identifier" of the second SSP.

[0279] -spblAttestation may include information in 550 indicating that the second SSP has changed the package status to an available status.

[0280] -spblAttestation may optionally include in 520 the time at which the second SSP changed the state of the package or the time at which the attestation was generated.

[0281] - spblAttestation may include signature information of the second SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the second SSP.

[0282] refer to Fig.11 In step 11040, the second SSP 1160 may transmit the spblAttestation to the first SSP 1110. For example, the second SSP 1160 may transmit the spblAttestation to the first SSP via the second LBA 1170 and the first LBA 1120.

[0283] refer to Fig.11, in step 11045, the first SSP 1110 may verify the received spblAttestation. The verification process may include the step of checking the validity of the signature of the second SSP contained in the spblAttestation. In addition, the verification process may also include the process of checking whether the "packet delimiter" included in the spblAttestation matches the packet delimiter of the corresponding packet. In addition, the verification process may optionally further include the process of checking whether the finalizationResponse included in the spblAttestation matches the information already sent by the first SSP 1110. In addition, the verification process may also include the step of checking whether the "SSP identifier" contained in the spblAttestation is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information included in the spblAttestation is instruction information for changing the package state to an available state.

[0284] Additionally, in step 11045, the first SSP 1110 may delete the package after the verification is complete.

[0285] Fig.12 It is shown Figure 6 Another detailed process diagram of the process of completing the transmission of the packet in the process presented in FIG. More specifically, Fig.12 is another example of a diagram illustrating a process of installing a package in a terminal and a process of configuring a package state after sending the package according to an embodiment of the present disclosure.

[0286] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.12 In the example of , the first terminal 1200 may include a first LBA 1220 and a first SSP 1210, and the second terminal 1250 may include a second LBA 1270 and a second SSP 1260. For example, the first terminal 1200 may be a terminal in which the first SSP 1210 is installed and in which the first LBA 1220 for controlling the first SSP 1210 is installed, and the second terminal 1250 may be a terminal in which the second SSP 1260 is installed and in which the second LBA 1270 for controlling the second SSP 1260 is installed.

[0287] 1. Installing Packages

[0288] refer to Fig.12 In step 12000, the second LBA 1270 and the second SSP 1260 may cooperate with each other to install the package in the second terminal 1250. For a detailed description, refer to Fig. 9 The "package installation" process.

[0289] 2. Identify whether the package can be reused

[0290] In addition, although not shown in the figure, the second LBA 1270 and / or the second SSP 1260 can selectively determine whether the packet can be reused in multiple terminals. Fig. 9 The process of "identifying whether a package can be reused".

[0291] 3. Configuration package status

[0292] If the packet cannot be reused in multiple terminals, the packet state is additionally configured as follows. Alternatively, even when the second LBA 1270 and / or the second SSP 1260 determines / uncertains whether the packet can be reused, the process of additionally configuring the packet state can be performed according to the implementation of the second LBA 1270 and / or the second SSP 1260, as described below.

[0293] refer to Fig.12 In step 12005, the second SSP 1260 may configure the packet status as "in transition". For a description of the "in transition" status, refer to the description of step 10005.

[0294] refer to Fig.12 , in step 12010, the second LBA 1270 may request “proof” from the second SSP 1260.

[0295] refer to Fig.12 , in step 12015, the second SSP 1260 may generate a "proof". Fig.12 In , the proof can be called finalizationRequest. The structure of the proof can follow Figure 5 The structure disclosed in .

[0296] In this case, one example of a possible proof configuration is as follows.

[0297] -The finalizationRequest may include in 510 a "packet delimiter" for the packet.

[0298] - FinalizationRequest may include in 540 the "SSP Identifier" of the second SSP.

[0299] - FinalizationRequest may include information in 550 indicating that the second SSP has configured the package state to be a "transitioning" state.

[0300] - FinalizationRequest may optionally include in 520 the time at which the second SSP changed the state of the package to the "in transition" state or the time at which the proof was generated.

[0301] - FinalizationRequest may include signature information of the second SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the second SSP.

[0302] refer to Fig.12 In step 12020, the second SSP 1260 may transmit the finalizationRequest to the first SSP 1210. For example, the second SSP 1260 may transmit the finalizationRequest to the first SSP 1210 through the following process. That is, in response to step 12010, the second SSP 1260 may transmit the finalizationRequest to the second LBA 1270, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1220.

[0303] refer to Fig.12 , in step 12025, the first SSP 1210 may verify the received finalizationRequest. The verification process may include the step of checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may also include the process of checking whether the "packet delimiter" included in the finalizationRequest matches the packet delimiter of the corresponding packet. In addition, the verification process may also include the process of checking whether the "SSP identifier" included in the finalizationRequest is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information included in the finalizationRequest is instruction information for changing the packet state to the "transitioning" state.

[0304] Furthermore, in step 12025, after the verification is completed, the first SSP 1210 may configure the package state to a "pause" state. "Pause" means a state in which the package is unavailable (in addition, a state that can be changed to an available state (disabled, enabled, active state) only by "a request from another terminal (e.g., a request made by sending recoveryRequest)" and / or "a request from an external server (although not described in the present disclosure)"). Furthermore, although not shown in the figure, the above-mentioned "pause" state may be replaced with a "converting" state.

[0305] Additionally, in step 12025, the first SSP 1210 may generate a "proof". Fig.12 In , the proof can be called finalizationResponse. The structure of the proof can follow Figure 5 The structure disclosed in .

[0306] In this case, one example of a possible proof configuration is as follows.

[0307] The -finalizationResponse may include in 510 a "packet delimiter" for the packet.

[0308] - The finalizationResponse may include in 540 the "SSP Identifier" of the first SSP.

[0309] - The finalizationResponse may include information in 550 indicating that the first SSP has changed the state of the package to a "suspended" (or transitioning) state.

[0310] The -finalizationResponse may optionally include in 520 the time at which the first SSP changed the state of the package or the time at which the proof was generated.

[0311] - FinalizationResponse may include signature information of the first SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the first SSP.

[0312] Furthermore, another example of a possible proof configuration is as follows.

[0313] - FinalizationResponse may include the received FinalizationRequest in 530. In this case, some information of the received FinalizationRequest may be omitted as needed. For example, in some cases, the signature information of the second SSP included in the FinalizationRequest may be omitted. In addition, for example, in some cases, the time information included in the FinalizationRequest may be omitted.

[0314] - The finalizationResponse may include in 540 the "SSP Identifier" of the first SSP.

[0315] - The finalizationResponse may include information in 550 indicating that the first SSP has changed the state of the package to a "suspended" (or transitioning) state.

[0316] The -finalizationResponse may optionally include in 520 the time at which the first SSP changed the state of the package or the time at which the proof was generated.

[0317] - FinalizationResponse may include signature information of the first SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the first SSP.

[0318] refer to Fig.12 In step 12030, the first SSP 1210 may transmit the finalizationResponse to the second SSP 1260. For example, the first SSP 1210 may transmit the finalizationResponse to the second SSP 1260 via the first LBA 1220 and the second LBA 1270.

[0319] refer to Fig.12 , in step 12035, the second SSP 1260 may verify the received finalizationResponse. The verification process may include the step of checking the validity of the signature of the first SSP contained in the finalizationResponse. In addition, the verification process may optionally further include the process of checking whether the "packet delimiter" contained in the finalizationResponse matches the packet delimiter of the corresponding packet. In addition, the verification process may optionally further include the process of checking whether the finalizationRequest contained in the finalizationResponse matches the information that the second SSP 1260 has sent. In addition, the verification process may also include the process of identifying the "SSP identifier" contained in the finalizationResponse. In addition, the verification process may further include the process of identifying whether the instruction information included in the finalizationResponse is correct.

[0320] In addition, in step 12035, after the verification is completed, the second SSP 1260 can change the package state to one of the available states (one of disabled, enabled and active). For example, as shown in the figure, the second SSP 1260 can convert the package state to a disabled state.

[0321] refer to Fig.12In step 12040, the second SSP 1260 may send the result (eg, success or failure) of the operation performed in step 12035 to the second LBA 1270.

[0322] Fig.13 is a diagram showing an example of a process for making a package that has been suspended available again. More specifically, Fig.13 is an example of a diagram showing a process for configuring a package in a “transitioning” state or a “suspended” state to be in an available state again.

[0323] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.13 In the example of , the first terminal 1300 may include a first LBA 1320 and a first SSP 1310, and the second terminal 1350 may include a second LBA 1370 and a second SSP 1360. For example, the first terminal 1300 may be a terminal in which the first SSP 1310 is installed and in which the first LBA 1320 for controlling the first SSP 1310 is installed, and the second terminal 1350 may be a terminal in which the second SSP 1360 is installed and in which the second LBA 1370 for controlling the second SSP 1360 is installed.

[0324] In execution Fig.13 Prior to the process disclosed in , possible examples of situations where the package status is configured as the "transitioning" state or the "paused" state are as follows. Fig.11 In the step of completing the transmission of the packet disclosed in , when step 11025 is executed but step 11045 is not executed, the packet state in the first terminal 1300 will be configured as the "transitioning" state. As another example, when Fig.12 When step 12025 is executed in the step of completing the transmission of the packet disclosed in the first terminal 1300, the packet status in the first terminal 1300 will be configured as a "converting" state or a "pause" state.

[0325] refer to Fig.13 In step 13000, information about the package requested to be restored for use may be transmitted to the second LBA 1370. The transmission process may be performed by a process in which a user directly selects a package through a UI provided by the second terminal 1350, or may be input from a remote server to the second LBA 1370 through a push input, or the second LBA 1370 may access the remote server to read the corresponding information.

[0326] refer to Fig.13In step 13005, information about the packet selected in step 13000 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 packet selected in step 13000.

[0327] refer to Fig.13 In step 13010, the second SSP 1360 may delete the corresponding package. In addition, the second SSP 1360 may generate a "proof". Fig.13 In this case, the proof can be called recoveryRequest. The structure of the proof can follow Figure 5 The structure disclosed in .

[0328] In this case, one example of a possible proof configuration is as follows.

[0329] -recoveryRequest may include in 510 a "packet delimiter" for the packet.

[0330] - The recoveryRequest may include in 540 the "SSP Identifier" of the second SSP.

[0331] - The recoveryRequest may include in 550 information indicating that the second SSP has deleted the package.

[0332] - The recoveryRequest may optionally include in 520 the time in which the second SSP deleted the package or the time in which the proof was generated.

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

[0334] refer to Fig.13 In step 13015, the second SSP 1360 may transmit the recoveryRequest to the first SSP 1310. For example, the second SSP 1360 may transmit the recoveryRequest to the first SSP 1310 through the following process. That is, in response to step 13005, the second SSP 1360 may transmit the recoveryRequest to the second LBA 1370, and the second LBA 1370 may transmit the recoveryRequest to the first SSP 1310 via the first LBA 1320.

[0335] refer to Fig.13In step 13020, the first SSP 1310 may verify the received recoveryRequest. The verification process may include the step of checking the validity of the signature of the second SSP 1360 contained in the recoveryRequest. In addition, the verification process may further include a process of identifying a "packet delimiter" contained in the recoveryRequest. In addition, the verification process may also include a process of checking an "SSP identifier" contained in the recoveryRequest. In addition, the verification process may further include a process of identifying whether the instruction information included in the recoveryRequest is instruction information for deleting a packet.

[0336] In addition, in step 13020, after the verification is completed, the first SSP 1310 can change the package state to one of the available states (one of disabled, enabled and active). For example, as shown in the figure, the first SSP 1310 can convert the package state to a disabled state.

[0337] refer to Fig.13 In step 13025, the first SSP 1310 may send the result (eg, success or failure) of the operation performed in step 13020 to the first LBA 1320.

[0338] Fig.14 is a diagram showing an example of another process for making a package whose use has been suspended available again.

[0339] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.14 In the example of , the first terminal 1400 may include a first LBA 1420 and a first SSP 1410, and the second terminal 1450 may include a second LBA 1470 and a second SSP 1460. For example, the first terminal 1400 may be a terminal in which the first SSP 1410 is installed and in which the first LBA 1420 for controlling the first SSP 1410 is installed, and the second terminal 1450 may be a terminal in which the second SSP 1460 is installed and in which the second LBA 1470 for controlling the second SSP 1460 is installed.

[0340] In execution Fig.14 Prior to the process disclosed in , possible examples of situations where the package status is configured as the "transitioning" state or the "paused" state are as follows. Fig.11 In the step of completing the transmission of the packet disclosed in , when step 11025 is executed but step 11045 is not executed, the state of the packet in the first terminal 1400 will be configured as the "transitioning" state. As another example, in Fig.12In the step of completing the transmission of the packet disclosed in , when step 12025 is executed, the state of the packet in the first terminal 1400 will be configured as a "converting" state or a "pause" state.

[0341] refer to Fig.14 In step 14000, information about the package requested to be restored for use may be transmitted to the second LBA 1470. The transmission process may be performed by a process in which a user directly selects a package through a UI provided by the second terminal 1450, or may be input from a remote server to the second LBA 1470 through a push input, or the second LBA 1470 may access the remote server to read the corresponding information.

[0342] refer to Fig.14 In step 14005, information about the packet selected in step 14000 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 packet selected in step 14000.

[0343] refer to Fig.14 In step 14010, the second SSP 1460 may configure the package state to a "transitioning" state. In addition, the second SSP 1460 may generate a "proof" associated with the package state change. Fig.14 In this case, the proof can be called recoveryRequest. The structure of the proof can follow Figure 5 The structure disclosed in .

[0344] In this case, one example of a possible proof configuration is as follows.

[0345] -recoveryRequest may include in 510 a "packet delimiter" for the packet.

[0346] - The recoveryRequest may include in 540 the "SSP Identifier" of the second SSP.

[0347] -recoveryRequest may include in 550 information indicating that the second SSP has configured the package state to the "in transition" state.

[0348] -recoveryRequest may optionally include in 520 the time at which the second SSP changed the state of the package or the time at which the proof was generated.

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

[0350] refer to Fig.14 In step 14015, the second SSP 1460 may transmit the recoveryRequest to the first SSP 1410. For example, the second SSP 1460 may transmit the recoveryRequest to the first SSP 1410 through the following process. That is, in response to step 14005, the second SSP 1460 may transmit the recoveryRequest to the second LBA 1470, and the second LBA 1470 may transmit the recoveryRequest to the first SSP 1410 via the first LBA 1420.

[0351] refer to Fig.14 , in step 14020, the first SSP 1410 may verify the received recoveryRequest. The verification process may include the step of checking the validity of the signature of the second SSP 1460 included in the recoveryRequest. In addition, the verification process may further include a process of identifying a "packet delimiter" included in the recoveryRequest. In addition, the verification process may also include a process of identifying an "SSP identifier" included in the recoveryRequest. In addition, the verification process may also include a process of identifying whether the instruction information included in the recoveryRequest is instruction information for changing the package state to the "transitioning" state.

[0352] In addition, in step 14020, after the verification is completed, the first SSP 1410 can change the package state to one of the available states (one of disabled, enabled and active). For example, as shown in the figure, the first SSP 1410 can convert the package state to a disabled state.

[0353] Additionally, in step 14020, the first SSP 1410 may generate a "proof". Fig.14 In this case, the proof can be called recoveryResponse. The structure of the proof can follow Figure 5 The structure disclosed in .

[0354] In this case, one example of a possible proof configuration is as follows.

[0355] -recoveryResponse may include in 510 a "packet delimiter" of the corresponding packet.

[0356] - The recoveryResponse may include in 540 the "SSP Identifier" of the first SSP.

[0357] - The recoveryResponse may include in 550 information indicating that the first SSP has changed the package state to an available state.

[0358] - The recoveryResponse may optionally include in 520 the time in which the first SSP changed the state of the package or the time in which the proof was generated.

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

[0360] Furthermore, another example of a possible proof configuration is as follows.

[0361] -recoveryResponse may include the received recoveryRequest in 530. In this case, some information of the received recoveryRequest may be omitted as needed. For example, the signature information of the second SSP included in the recoveryRequest may be omitted in some cases. In addition, for example, the time information included in the recoveryRequest may be omitted in some cases.

[0362] - The recoveryResponse may include in 540 the "SSP Identifier" of the first SSP.

[0363] - The recoveryResponse may include in 550 information indicating that the first SSP has changed the package state to an available state.

[0364] - The recoveryResponse may optionally include in 520 the time in which the first SSP changed the state of the package or the time in which the proof was generated.

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

[0366] refer to Fig.14In step 14025, the first SSP 1410 may transmit the recoveryResponse to the second SSP 1460. For example, the first SSP 1410 may transmit the recoveryResponse to the second SSP 1460 via the first LBA 1420 and the second LBA 1470.

[0367] refer to Fig.14 , in step 14030, the second SSP 1460 may verify the received recoveryResponse. The verification process may include the step of checking the validity of the signature of the first SSP 1460 contained in the recoveryResponse. In addition, the verification process may optionally further include the process of checking whether the "packet delimiter" contained in the recoveryResponse matches the packet delimiter of the corresponding packet. In addition, the verification process may optionally further include the process of checking whether the recoveryRequest contained in the recoveryResponse matches the information that the second SSP 1460 has sent. In addition, the verification process may also include the process of identifying the "SSP identifier" contained in the recoveryResponse. In addition, the verification process may further include the process of identifying whether the instruction information included in the recoveryResponse is correct instruction information.

[0368] Additionally, in step 14030, the second SSP 1460 may delete the package after the verification is complete.

[0369] refer to Fig.14 In step 14035, the second SSP 1460 may send the result (eg, success or failure) of the operation performed in step 14030 to the second LBA 1470.

[0370] Fig.15 is a diagram showing an example of another process for making a package whose use has been suspended available again.

[0371] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.15In the example of , the first terminal 1500 may include a first LBA 1520 and a first SSP 1510, and the second terminal 1550 may include a second LBA 1570 and a second SSP 1560. For example, the first terminal 1500 may be a terminal in which the first SSP 1510 is installed and in which the first LBA 1520 for controlling the first SSP 1510 is installed, and the second terminal 1550 may be a terminal in which the second SSP 1560 is installed and in which the second LBA 1570 for controlling the second SSP 1560 is installed.

[0372] In execution Fig.15 Prior to the process disclosed in , possible examples of situations where the package status is configured as the "transitioning" state or the "paused" state are as follows. Fig.11 In the step of completing the transmission of the packet disclosed in , when step 11025 is executed but step 11045 is not executed, the state of the packet in the first terminal 1500 will be configured as the "transitioning" state. As another example, in Fig.12 In the step of completing the transmission of the packet disclosed in , when step 12025 is executed, the state of the packet in the first terminal 1500 will be configured as a "converting" state or a "paused" state.

[0373] refer to Fig.15 In step 15000, information about the package requested to be restored to use may be transmitted to the second LBA. The transmission process may be performed by a process in which a user directly selects a package through a UI provided by the second terminal 1550, or may be input from a remote server to the second LBA 1570 through a push input, or the second LBA 1570 may access the remote server to read the corresponding information.

[0374] refer to Fig.15 In step 15005, information about the packet selected in step 15000 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 packet selected in step 15000.

[0375] refer to Fig.15 In step 15010, the second SSP 1560 may change the packet state to "pause". In this case, although not shown in the figure, the above-mentioned "pause" state may be replaced by a "converting" state.

[0376] Additionally, the second SSP 1560 may generate a "proof". Fig.15 In this case, the proof can be called recoveryRequest. The structure of the proof can follow Figure 5 The structure disclosed in .

[0377] In this case, one example of a possible proof configuration is as follows.

[0378] -recoveryRequest may include in 510 a "packet delimiter" for the packet.

[0379] - The recoveryRequest may include in 540 the "SSP Identifier" of the second SSP.

[0380] -recoveryRequest may include information in 550 indicating that the second SSP has changed the package state to "suspended" or "transitioning".

[0381] -recoveryRequest may optionally include in 520 the time at which the second SSP changed the state of the package or the time at which the proof was generated.

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

[0383] refer to Fig.15 In step 15015, the second SSP 1560 may transmit the recoveryRequest to the first SSP 1510. For example, the second SSP 1560 may transmit the recoveryRequest to the first SSP 1510 through the following process. That is, in response to step 15005, the second SSP 1560 may transmit the recoveryRequest to the second LBA 1570, and the second LBA 1570 may transmit the recoveryRequest to the first SSP 1510 via the first LBA 1520.

[0384] refer to Fig.15 , in step 15020, the first SSP 1510 may verify the received recoveryRequest. The verification process may include the step of checking the validity of the signature of the second SSP 1560 contained in the recoveryRequest. In addition, the verification process may further include a process of identifying a "packet delimiter" contained in the recoveryRequest. In addition, the verification process may further include a process of identifying an "SSP identifier" contained in the recoveryRequest. In addition, the verification process may further include a process of identifying whether the instruction information included in the recoveryRequest is instruction information for correctly changing the package state.

[0385] In addition, in step 15020, after the verification is completed, the first SSP 1510 can change the package state to one of the available states (one of disabled, enabled and active). For example, as shown in the figure, the first SSP 1510 can change the package state to a disabled state.

[0386] refer to Fig.15 In step 15025, the first SSP 1510 may send the result (eg, success or failure) of the operation performed in step 15020 to the first LBA 1520.

[0387] Fig.16 is a diagram showing a configuration of a terminal according to an embodiment of the present disclosure.

[0388] like Fig.16 As shown, the terminal may include a transceiver 1610 and at least one processor 1620. In addition, the terminal may also 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 be referred to as a "controller". However, the configuration of the terminal is not limited to Fig.16 The configuration shown and may include Fig.16 The components shown may be more or less than the components shown. According to some embodiments, the transceiver 1610, at least one processor 1620, and a memory (not shown) may be implemented in the form of a single chip. In addition, when the SSP 1630 is embedded in a terminal, the transceiver 1610, at least one processor 1620, and a memory (not shown) may be implemented in the form of a single chip including the SSP 1630.

[0389] According to various embodiments, the transceiver 1610 may send signals, information, data, etc. to a transceiver of another terminal or an external server according to various embodiments of the present disclosure, and receive signals, information, data, etc. from a transceiver of another terminal or an external server. The transceiver 1610 may include an RF transmitter for up-converting and amplifying the frequency of a signal to be transmitted, and an RF receiver for low-noise amplifying a received signal and down-converting its frequency. However, this is only an embodiment of the transceiver 1610, and the components of the transceiver 1610 are not limited to the RF transmitter and the RF receiver. In addition, the transceiver 1610 may receive a signal through a wireless channel, output the signal to at least one processor 1620, and send a signal output from at least one processor 1620 through a wireless channel.

[0390] According to various embodiments, the transceiver 1610 can transmit or receive information of an SSP included in another terminal, authentication information capable of authenticating another terminal, authentication information capable of authenticating itself, a packet transmission code, a packet transmission configuration, a packet, and Figures 10 to 15 The various proofs described in .

[0391] At least one processor 1620 is a component for overall control of the terminal. As described above, according to various embodiments of the present disclosure, at least one processor 1620 may control the overall operation of the terminal.

[0392] The SSP 1630 may include a processor or controller for installing and controlling packages, or may have applications installed therein.

[0393] According to various embodiments, at least one processor or controller in SSP 1630 may identify a packet transmission configuration to determine whether to send a specific packet. In addition, at least one processor or controller may identify a packet transmission configuration to identify whether a packet can be reused in multiple terminals.

[0394] Furthermore, according to various embodiments, at least one processor or controller in the SSP may generate a packet transmission code to control the transmission process of a specific packet.

[0395] Furthermore, according to various embodiments, at least one processor or controller in the SSP may generate its SSP information, and identify and verify SSP information of another SSP received from the outside.

[0396] Furthermore, according to various embodiments, at least one processor or controller in the SSP may generate authentication information capable of authenticating itself and authenticate authentication information of another SSP received from the outside.

[0397] Furthermore, according to various embodiments, the SSP 1330 may generate a package alone or in cooperation with one or more processors 1620, and install the package. Furthermore, the SSP 1630 may manage the package.

[0398] In addition, according to various embodiments, SSP 1630 may generate a reference Figures 10 to 15 Describe the various types of certificates and verify received certificates.

[0399] In addition, according to various embodiments, SSP 1630 may change the state of the package based on the contents of the received proof, such as reference Figures 10 to 15 as described.

[0400] In addition, 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 packages, or may install applications therein. Some or all of the applications may be installed in the SSP 1630 or a memory (not shown).

[0401] The terminal may also include a memory (not shown), and the memory (not shown) may store data such as basic programs, applications, and configuration information for terminal operation. In addition, the memory may include a flash memory type, a hard disk type, a multimedia micro card type, a card type memory (e.g., SD or XD memory), a magnetic memory, a disk, an optical disk, a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), a programmable read-only memory (PROM), or at least one storage medium in an electrically erasable programmable read-only memory (EEPROM). In addition, the processor 1620 may use various programs, contents, data, etc. stored in the memory to perform various operations.

[0402] Fig.17 It is shown Figure 6 Another detailed process diagram of the process of completing the transmission of the packet in the process presented in FIG. More specifically, Fig.17 is another example of a diagram illustrating a process of installing a package in a terminal and a process of configuring a package state after sending the package according to an embodiment of the present disclosure.

[0403] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.17 In the example of , the first terminal 1700 may include a first LBA 1720 and a first SSP 1710, and the second terminal 1750 may include a second LBA 1770 and a second SSP 1760. For example, the first terminal 1700 may be a terminal in which the first SSP 1710 is installed and in which the first LBA 1720 for controlling the first SSP 1710 is installed, and the second terminal 1750 may be a terminal in which the second SSP 1760 is installed and in which the second LBA 1770 for controlling the second SSP 1760 is installed.

[0404] 1. Installation package

[0405] refer to Fig.17 In step 17000, the second LBA 1770 and the second SSP 1760 may cooperate with each other to install the package in the second terminal 1750. For a detailed description, refer to Fig. 9 The "package installation" process.

[0406] 2. Identify whether the package can be reused

[0407] In addition, although not shown in the figure, the second LBA 1770 and / or the second SSP 1760 may selectively determine whether the packet can be reused in multiple terminals. Fig. 9 The process of "identifying whether a package can be reused".

[0408] 3.Configure package status

[0409] If the packet cannot be reused in multiple terminals, the packet state is additionally configured as follows. Alternatively, even when the second LBA 1770 and / or the second SSP 1760 determines / uncertains whether the packet can be reused, the process of additionally configuring the packet state can be performed according to the implementation of the second LBA 1770 and / or the second SSP 1760, as described below.

[0410] refer to Fig.17 In step 17005, the second SSP 1760 may configure the package state to "in transition". "In transition" refers to a state in which the package has been successfully installed but is unavailable (in addition, a state that can be changed to an available state (disabled, enabled, active state) only by additional operations such as "a request from another terminal (e.g., a request made by sending 'finalizationResponse or recoveryRequest')" and / or "a request from an external server").

[0411] refer to Fig.17 , in step 17010, the second LBA 1770 may request “proof” from the second SSP 1760.

[0412] refer to Fig.17 , in step 17015, the second SSP 1760 may generate a "proof". Fig.17 In , the proof can be called finalizationRequest. The structure of the proof can follow Figure 5 The structure disclosed in .

[0413] In this case, one example of a possible proof configuration is as follows.

[0414] -The finalizationRequest may include in 510 a "packet delimiter" for the packet.

[0415] - FinalizationRequest may include in 540 the "SSP Identifier" of the second SSP.

[0416] - FinalizationRequest may include information in 550 indicating that the second SSP has configured the package state to be a "transitioning" state.

[0417] - FinalizationRequest may optionally include the time in which the second SSP changed the package state to the "in transition" state or the time in which the attestation was generated in 520. Alternatively, the finalizationRequest may optionally further include information about a certificate to be used later for digital signing.

[0418] - FinalizationRequest may include signature information of the second SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the second SSP.

[0419] refer to Fig.17 In step 17020, the second SSP 1760 may transmit the finalizationRequest to the first SSP 1710. For example, the second SSP 1760 may transmit the finalizationRequest to the first SSP 1710 through the following process. That is, in response to step 17010, the second SSP 1760 may transmit the finalizationRequest to the second LBA 1770, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1720.

[0420] refer to Fig.17 , in step 17025, the first SSP 1710 may verify the received finalizationRequest. The verification process may include the step of checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may also include the process of checking whether the "packet delimiter" included in the finalizationRequest matches the packet delimiter of the corresponding packet. In addition, the verification process may also include the process of checking whether the "SSP identifier" included in the finalizationRequest is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information included in the finalizationRequest is instruction information for changing the packet state to the "transitioning" state.

[0421] Additionally, in step 17025, the first SSP 1710 may delete the package.

[0422] Additionally, in step 17025, the first SSP 1710 may generate a "proof". Fig.17 In , the proof can be called finalizationResponse. The structure of the proof can follow Figure 5 The structure disclosed in .

[0423] In this case, one example of a possible proof configuration is as follows.

[0424] The -finalizationResponse may include in 510 a "packet delimiter" for the packet.

[0425] - The finalizationResponse may include in 540 the "SSP Identifier" of the first SSP.

[0426] - The finalizationResponse may include information in 550 indicating that the first SSP has deleted the package.

[0427] - The finalizationResponse may optionally include in 520 the time in which the first SSP deleted the package or the time in which the certificate was generated. Alternatively, the finalizationResponse may optionally further include information about the certificate used later for digital signing.

[0428] - FinalizationResponse may include signature information of the first SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the first SSP.

[0429] Furthermore, another example of a possible proof configuration is as follows.

[0430] - FinalizationResponse may include part and / or all of the data of finalizationRequest in 530 .

[0431] - The finalizationResponse may include in 540 the "SSP Identifier" of the first SSP.

[0432] - The finalizationResponse may include information in 550 indicating that the first SSP has deleted the package.

[0433] - The finalizationResponse may optionally include in 520 the time in which the first SSP deleted the package or the time in which the certificate was generated. Alternatively, the finalizationResponse may optionally further include information about the certificate used later for digital signing.

[0434] - FinalizationResponse may include signature information of the first SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the first SSP.

[0435] refer to Fig.17 In step 17030, the first SSP 1710 may transmit the finalizationResponse to the second SSP 1760. For example, the first SSP 1710 may transmit the finalizationResponse to the second SSP 1760 via the first LBA 1720 and the second LBA 1770.

[0436] refer to Fig.17 , in step 17035, the second SSP 1760 may verify the received finalizationResponse. The verification process may include the step of checking the validity of the signature of the first SSP contained in the finalizationResponse. In addition, the verification process may optionally further include the process of checking whether the "packet delimiter" contained in the finalizationResponse matches the packet delimiter of the corresponding packet. In addition, the verification process may optionally further include the process of checking whether some and / or all of the information of the finalizationRequest contained in the finalizationResponse matches the information already sent by the second SSP 1760. In addition, the verification process may also include the process of identifying the "SSP identifier" contained in the finalizationResponse. In addition, the verification process may also include the process of identifying whether the instruction information included in the finalizationResponse is the instruction information to delete the packet.

[0437] In addition, in step 17035, the second SSP 1760 may change the package state to one of the available states (one of disabled, enabled, and active). For example, as shown, the second SSP 1760 may convert the package state to a disabled state.

[0438] Additionally, in step 17035, the second SSP 1760 may generate a "proof". Fig.17In , the proof can be called spblAttestation. The structure of the proof can be followed Figure 5 The structure disclosed in .

[0439] In this case, one example of a possible proof configuration is as follows.

[0440] -spblAttestation may include in 510 the "Packet Delimiter" of the packet.

[0441] -spblAttestation may include in 540 the "SSP Identifier" of the second SSP.

[0442] -spblAttestation may include information in 550 indicating that the second SSP has changed the package status to an available status.

[0443] - spblAttestation may optionally include the time where the second SSP changed the state of the package or the time where the attestation was generated in 520. Alternatively, spblAttestation may optionally further include information about a certificate used later for digital signing.

[0444] - spblAttestation may include signature information of the second SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the second SSP.

[0445] Furthermore, another example of a possible proof configuration is as follows.

[0446] - spblAttestation may include part and / or all of the data of "finalizationRequest and / or finalizationResponse" in 530.

[0447] -spblAttestation may include in 540 the "SSP Identifier" of the second SSP.

[0448] -spblAttestation may include in 540 information indicating that the second SSP has changed the package status to an available status.

[0449] - spblAttestation may optionally include the time where the second SSP changed the state of the package or the time where the attestation was generated in 520. Alternatively, spblAttestation may optionally further include information about a certificate used later for digital signing.

[0450] - spblAttestation may include signature information of the second SSP in 560. The signature may be signature information obtained by digitally signing the above information with a signature certificate of the second SSP.

[0451] refer to Fig.17 In step 17040, the second SSP 1760 may transmit the spblAttestation to the first SSP 1710. For example, the second SSP 1760 may transmit the spblAttestation to the first SSP 1710 via the second LBA 1770 and the first LBA 1720.

[0452] refer to Fig.17 , in step 17045, the first SSP 1710 may verify the received spblAttestation. The verification process may include the step of checking the validity of the signature of the second SSP contained in the spblAttestation. In addition, the verification process may also include the process of checking whether the "packet delimiter" contained in the spblAttestation matches the packet delimiter of the corresponding packet. In addition, the verification process may optionally further include the process of checking whether some and / or all of the information of the finalizationRequest and / or finalizationResponse included in the spblAttestation matches the information sent by the first SSP 1710. In addition, the verification process may also include the process of checking whether the "SSP identifier" contained in the spblAttestation is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information included in the spblAttestation is instruction information for changing the package state to an available state.

[0453] Additionally, in step 17045, the first SSP 1710 may delete the finalizationResponse.

[0454] As needed, the step of generating spblAttestation in step 17035 and / or step 17040 and / or step 17045 may be omitted.

[0455] When the certificate transmission fails in step 17020, step 17030 and / or step 17040, the corresponding certificate may be retransmitted to the other party device.

[0456] In this case, as many retransmissions as the preconfigured maximum number of retransmissions may be attempted. Alternatively, repeated attempts may be made until it is recognized that the corresponding proof has been sent to another terminal. Alternatively, depending on the implementation of the terminal, the proof may be repeatedly retransmitted until the corresponding proof is deleted. For example, the first terminal may repeatedly attempt to retransmit the finalizationResponse until the finalizationResponse is deleted in step 17045.

[0457] When retransmission is attempted, if the connection between the two devices is disconnected, the two devices can establish a new connection and then send and receive corresponding proofs. In this case, the two terminals can use the records sent and received during past communications to select and / or verify the target of the newly established connection, determine what data to send and receive with the newly established connection target, and verify the validity and / or content of the data received from the other terminal.

[0458] In this case, the retransmission may be automatically initiated by an operation within the terminal, may be initiated by a request from an external server, or may be initiated by a user input.

[0459] Fig.18 is a diagram illustrating a configuration of a "proof" according to some embodiments of the present disclosure.

[0460] According to various embodiments, the attestation may optionally include "attestation information" (1810). Various examples of data included in the attestation information are described later. Figures 22 to 27 Description.

[0461] According to various embodiments, the certificate may optionally further include a "publisher ID of the subject that issued the certificate" (1830). Various examples of the subject that issued the certificate refer to the later described Figures 22 to 27 Description.

[0462] According to various embodiments, the certificate may optionally further include "commands regarding operations to be performed by the certificate issuer" (1850). Various examples of operations to be performed by the certificate issuer are described later. Figures 22 to 27 Description.

[0463] According to various embodiments, the proof may optionally further include other data in addition to the above information (1870). Various examples of other data that may be included in the proof are described later. Figures 22 to 27 Description.

[0464] According to various embodiments, the proof may include digital signature data of the above information (1890). The signature data may be an electronic signature generated by a certificate used to prove the signature of the publisher.

[0465] Fig.19 is a diagram conceptually illustrating a process for transmitting a packet from one terminal to another terminal according to an embodiment of the present disclosure.

[0466] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.19 In the example of , the first terminal 1900 may include a first LBA 1920 and a first SSP 1910, and the second terminal 1950 may include a second LBA 1970 and a second SSP 1960. For example, the first terminal 1900 may be a terminal in which the first SSP 1910 is installed and in which the first LBA 1920 for controlling the first SSP 1910 is installed, and the second terminal 1950 may be a terminal in which the second SSP 1960 is installed and in which the second LBA 1970 for controlling the second SSP 1960 is installed.

[0467] refer to Fig.19 In step 19000, the first SSP 1910 and the first LBA 1920 of the first terminal 1900 and the second LBA 1970 of the second terminal 1950 may perform a preparation process (packet transmission preparation process) required for packet transmission. For a more detailed description of this process, refer to the later described Fig. 20 Detailed description.

[0468] refer to Fig.19 , a process (packet transmission process) for transmitting a packet from the first terminal 1900 to the second terminal 1950 may be performed in step 19005. A more detailed description of the process is provided in the following description. Fig.21 Detailed description.

[0469] refer to Fig.19 In step 19010, the first terminal 1900 and the second terminal 1960 may perform a process for installing the sent package and a process for configuring the package status (package transmission completion process). The detailed description of the process is referred to in the following description. Fig. 22 , 24 and 26 for detailed description.

[0470] Fig. 20 It is shown Fig.19 More specifically, Fig. 201 is a diagram exemplarily illustrating a process in which a terminal undergoes a preparation process required to send a packet to another terminal according to an embodiment of the present disclosure. Fig. 20 The process can be called a packet transmission preparation process.

[0471] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig. 20 In the example of , the first terminal 2000 may include a first LBA 2020 and a first SSP 2010, and the second terminal 2050 may include a second LBA 2070 and a second SSP 2060. For example, the first terminal 2000 may be a terminal in which the first SSP 2010 is installed and in which the first LBA 2020 for controlling the first SSP 2010 is installed, and the second terminal 2050 may be a terminal in which the second SSP 2060 is installed and in which the second LBA 2070 for controlling the second SSP 2060 is installed.

[0472] According to various embodiments, the first terminal 2000 may have a pre-installed package and also have metadata associated with the package.

[0473] According to various embodiments, the first terminal 2000 may have at least one of a package identifier (SPBID), a package family identifier (SPB family ID), or a package family manager identifier (SPB family custodian object ID) associated with the corresponding package.

[0474] According to various embodiments, the first terminal 2000 may have a “packet transmission configuration” associated with the corresponding packet. The packet transmission configuration may optionally include information related to whether the packet can be transmitted between devices.

[0475] In addition, the packet transmission configuration may optionally further include a "registration configuration" for a process of registering the transmission result of the packet between the devices in the server. Various examples of possible "registration configurations" are as follows.

[0476] -Whether to notify: Whether to notify the server of the packet transmission results between devices.

[0477] - Whether to require advance notification: After sending a packet from one device to a new device, before using the packet in the new device, configuration as to whether the transmission history should be notified to the server or whether the transmission history can be used in the new device before notifying the server

[0478] -Whether notification content needs to be encrypted: Whether the data sent during the notification process needs to be encrypted so that only the server receiving the notification and the SSP making the notification can view the configuration of the content.

[0479] The "registration configuration" may be configured by the service provider, by the package management server, or by collaboration between the service provider and the package management server. In addition, the package transmission configuration may be included as data within the package, included in the metadata of the package, or may exist as independent data. In addition, the package transmission configuration may include an electronic signature of the service provider and / or the package management server.

[0480] refer to Fig. 20 In step 20000, information about a packet to be sent between devices may be transferred to the first LBA 2020. For example, Fig. 20 As shown, the transmission process can be performed by the user directly selecting a package through a UI provided by the first terminal 2000, or can be input from a remote server to the first LBA 2020 through push input, or the first LBA 2020 can access the remote server to read the corresponding information.

[0481] refer to Fig. 20 In step 20005, information related to the packet selected by step 20000 may be transmitted from the first LBA 2020 to the first SSP 2010. For example, Fig. 20 As shown, information related to the selected packet may be transferred from the first LBA 2020 to the first SSP 2010 through the Select SPB command. In this case, the information transferred from the first LBA 2020 to the first SSP 2010 may include information for identifying the packet selected in step 20000.

[0482] refer to Fig. 20 In step 20010, the first SSP 2010 may identify whether the packet requested for transmission may be sent between the devices. This process may be performed by identifying the packet requested for transmission based on the information received in step 20005, and identifying a "packet transmission configuration" associated with the packet.

[0483] In addition, in step 20010, the first SSP 2010 may optionally configure a "packet transmission code". The "packet transmission code" is a code used to reference a packet in the process of sending a packet between devices, and should be a value that can identify the packet. The first SSP 2010 may bind the above-mentioned "packet transmission code" with the information of the packet to be sent.

[0484] refer to Fig. 20 In step 20015, the response result to step 20005 can be sent from the first SSP 2010 to the first LBA 2020. For example, Fig. 20As shown, a response to the Select SPB command may be transmitted from the first SPB 2010 to the first LBA 2020 via a Select SPB Response. The response value may include the “Packet Transfer Code” described in step 20010.

[0485] refer to Fig. 20 In step 20020, information required for packet transmission between devices may be transmitted from the first LBA 2020 of the first terminal 2000 to the second LBA 2070 of the second terminal 2050. In this case, the information transmitted from the first LBA 2020 to the second LBA 2070 may include a "packet transmission code". In addition, the information transmitted from the first LBA 2020 to the second LBA 2070 may optionally further include information required for a connection to be established between the first LBA 720 and the second LBA 2070 in a future step 20025.

[0486] The information transmitted from the first LBA 2020 to the second LBA 2070 through the above step 20020 may be transmitted in various ways. For example, the first LBA may provide the information to be transmitted to the second LBA to the user through the UI of the first terminal 2000, and the user may input the received information to the second LBA using the UI of the second terminal 2050. Alternatively, the first LBA may make the information to be transmitted to the second LBA in the form of an image (e.g., a QR code) to display the image on the screen of the first terminal, and the user may scan the image using the second terminal 2050 to transmit the information to the second LBA 2070. However, the method of transmitting information from the first LBA 2020 to the second LBA 2070 is not limited to the above method.

[0487] refer to Fig. 20 In step 20025, a connection may be established (or configured) between the first LBA 2020 and the second LBA 2070. When the information required for the connection has been sent in step 20020, the first LBA 2020 and the second LBA 2070 may establish a connection using the 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 may be a remote connection in which a remote server (e.g., a relay server) is located between the first LBA 2020 and the second LBA 2070.

[0488] refer to Fig. 20Although step 20025 is shown as the last step, this step is independent of the other steps described above, namely steps 20000, 20005, 20010, 20015, and 20020, and can be performed without regard to the order of the other steps. For example, step 20025 can be performed between steps 20015 and 20020, in which case the information sent from the first LBA 2020 to the second LBA 2070 in step 20020 can be sent via the connection established in step 20025.

[0489] Fig.21 It is shown Fig.19 More specifically, Fig.21 Schematic diagram showing a process of sending a packet from one terminal to another terminal according to an embodiment of the present disclosure. Fig.21 The process can be called packet transmission process.

[0490] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.21 In the example of , the first terminal 2100 may include a first LBA 2120 and a first SSP 2110, and the second terminal 2150 may include a second LBA 2170 and a second SSP 2160. For example, the first terminal 2100 may be a terminal in which the first SSP 2110 is installed and in which the first LBA 2120 for controlling the first SSP 2110 is installed, and the second terminal 2150 may be a terminal in which the second SSP 2160 is installed and in which the second LBA 2170 for controlling the second SSP 2160 is installed.

[0491] refer to Fig.21 In step 21000, the second LBA 2170 may request “SspInfo” from the second SSP 2160. When the second LBA 2170 requests “SspInfo” from the second SSP 2160 in step 21000, the second LBA 2170 may inform the second SSP 2160 that packet transfer between devices will be performed.

[0492] In addition, step 21000 can be referred to Fig.21 The process described above may be automatically executed immediately after receiving the external input, or may be executed after receiving the external input. In this case, the "external input" may be executed by a process in which a user directly selects a package to be received through a UI provided by the second terminal 2150, or may be input from a remote server to the second LBA 2170 through a push input, or the second LBA 2170 may access the remote server to read the corresponding information.

[0493] refer to Fig.21 , in step 21005, the second SSP 2160 may generate its "SspInfo". "SspInfo" may include information about the second SSP to be provided for packet transmission. In this case, "SspInfo" may include information about the certificate negotiation process that the second SSP 2160 should go through before receiving the packet (certificate negotiation information). "Certificate negotiation information" may include certificate information (SenderSpblVerification) that the second SSP 2160 can use to verify another SSP and certificate information (ReceiverSpblVerification) that another SSP can use to verify itself. In addition, "Certificate negotiation information" may optionally further include a list of key agreement algorithms supported by the second SSP 2160, and optionally further include a list of encryption algorithms supported by the second SSP 2160. In addition, "SspInfo" may optionally further include SSP version information, which includes at least one of version information of standard specifications supported by the main platform and loader included in the second SSP 2160.

[0494] refer to Fig.21 In step 21010, the second SSP 2160 may transmit the “SspInfo” generated in step 21005 to the first SSP 2110 via the second LBA 2170 and the first LBA 2120.

[0495] According to the above steps 21000 and 21010, the second LBA 2170 may request the second SSP 2160 for "SspInfo", and the second SSP 2160 may generate its "SspInfo", and then transmit the "SspInfo" to the first SSP 2110 via the second LBA 2170 and the first LBA 2120. However, according to an embodiment, the process of transmitting the "SspInfo" from the second terminal 2150 to the first terminal 2100 may be as follows. For example, after the second LBA 2170 generates the "SspInfo" itself, the second LBA 2170 may transmit the "SspInfo" to the first SSP 2110 via the first LBA 2120.

[0496] refer to Fig.21 In step 21015, the first SSP 2110 may identify the received "SspInfo" and generate "first terminal authentication information (Device1.Auth)" capable of authenticating itself based on the information. A more detailed process of this process is as follows.

[0497] The first SSP 2110 may use the received “SenderSpblVerification” to identify certificate information capable of verifying itself, and select at least one key agreement certificate (ssp1.Cert.KA). Alternatively, the first SSP 2110 may use the received “key agreement algorithm list supported by the second SSP 2160” to generate a public key “ssp1.ePK.KA” and a private key “ssp1.eSK.KA” as a key pair for asymmetric encryption to be used for key agreement, and then select the public key (ssp1.ePK.KA) in the key pair. In addition, the first SSP 2110 may use the received “SenderSpblVerification” to identify certificate information capable of verifying itself, and further select at least one signature certificate (ssp1.Cert.DS).

[0498] In addition, the first SSP 2110 may select at least one certificate information of the second SSP 2160 to perform verification using the received 'ReceiverSpblVerification' and configure the corresponding information as 'CiPkIdToBeUsed'.

[0499] In addition, the first SSP 2110 may use the received “encryption algorithm list supported by the second SSP 2160” to select at least one encryption algorithm to be used in the future, and then configure the corresponding information as “CryptoToBeUsed”.

[0500] Furthermore, the first SSP 2110 may identify the received list of “version information of standard specifications supported by the main platform and loader included in the second SSP 2160” and identify whether there is a version of the standard specification supported by itself therein.

[0501] The "first terminal authentication information (Device1.Auth)" may include at least one of the above-mentioned "ssp1.Cert.KA", "ssp1.ePK.KA", "CiPkIdToBeUsed" or "CryptoToBeUsed". In addition, the "first terminal authentication information (Device1.Auth)" may optionally further include "ssp1.Cert.DS". In addition, the "first terminal authentication information (Device1.Auth)" may optionally further include at least one of a packet family identifier (SPB family ID) or a packet family manager identifier (SPB family custodian object ID) associated with the packet to be sent in the future.

[0502] In this case, part or all of the above-mentioned "first terminal authentication information (Device1.Auth)" may be a digital signature that can be verified using ssp1.Cert.DS to ensure the integrity of the information, and the digital signature data may be added as part of the "first terminal authentication information".

[0503] refer to Fig.21 In step 21020 , the first SSP 2110 may transmit the “first terminal authentication information (Device1.Auth)” generated in step 21015 to the second LBA 2170 via the first LBA 2120 .

[0504] refer to Fig.21 In step 21025, the second LBA 2170 may transmit the “first terminal authentication information (Device1.Auth)” to the second SSP 2160. In addition, the second LBA 2170 may also transmit the “packet transmission code” to the second SSP 2160.

[0505] refer to Fig.21 , in step 21030, the second SSP 2160 may verify the received "first terminal authentication information (Device1.Auth)". When the second SSP 2160 receives "ssp1.Cert.KA", the second SSP 2160 may identify the signature of the corresponding certificate to identify the validity of the certificate. In addition, when the second SSP 2160 receives "ssp1.ePK.KA" and its digital signature, the second SSP 2160 may first check the validity of ssp1.Cert.DS, and then use the certificate to identify the digital signature to identify the integrity of the received public key ssp1.ePK.KA. In addition, the second SSP 2160 may identify the received "CiPkIdToBeUsed" and select at least one signing certificate (ssp2.Cert.DS) that can verify itself.

[0506] In addition, although not shown in the figure, in step 21030, the second SSP 2160 may generate a public key "ssp2.ePK.KA" and a private key "ssp2.eSK.KA" as a key pair for asymmetric encryption to be used for key negotiation, and then select a public key (ssp2.ePK.KA) in the key pair. In addition, the second SSP 2160 may select one of ssp1.ePK.KA and a public key for key negotiation included in ssp1.Cert.KA, and then use the value and ssp2.eSK.KA to generate a session key ShKey01 to be used for encryption during future communications with the first terminal.

[0507] Furthermore, 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". Furthermore, the "second terminal authentication information (Device2.Auth)" may also include "ssp2.ePK.KA". Furthermore, the "second terminal authentication information (Device2.Auth)" may further include a transaction ID indicating a current session generated by the second SSP 2160. Furthermore, the "second terminal authentication information (Device2.Auth)" may also include a "package transfer code". Furthermore, the "second terminal authentication information (Device2.Auth)" may further include an SSP identifier of the second SSP 2160. Furthermore, the "second terminal authentication information (Device2.Auth)" may optionally further include at least one of a package family identifier (SPB family ID) or a package family manager identifier (SPB family custodian object ID) associated with a package to be transmitted in the future.

[0508] In this case, part or all of the above-mentioned "second terminal authentication information (Device2.Auth)" can be a digital signature that can be verified using ssp2.Cert.DS to ensure the integrity of the information, and the digital signature data can be added as part of the "second terminal authentication information". In addition, part or all of the "second terminal authentication information (Device2.Auth)" can be encrypted using the previously generated session key ShKey01.

[0509] refer to Fig.21 In step 21035, the second SSP 2160 may transmit the "second terminal authentication information (Device2.Auth)" generated in step 21030 to the first SSP 2110 via the second LBA 2170 and the first LBA 2120. In this case, a "packet transmission code" may be further sent optionally.

[0510] refer 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 signature of the received "ssp2.Cert.DS" to verify the validity of the corresponding certificate. In addition, the first SSP 2110 may check whether the received package family identifier (SPB family ID) and / or package family manager identifier (SPB family custodian object ID) are correctly configured values ​​associated with the package to be sent by itself. 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 the currently ongoing session or the package to be sent.

[0511] In this process, when the encrypted data is included in the "second terminal authentication information (Device2.Auth)", the first SSP 2110 can use ssp1.eSK.KA or a private key corresponding to the public key for key negotiation included in its ssp1.Cert.KA and the received ssp2.ePK.KA to generate a session key ShKey01, decrypt the encrypted data using the session key, and then perform a verification process. In addition, in this process, when the digital signature is included in the "second terminal authentication information (Device2.Auth)", the first SSP 2110 can use "ssp2.Cert.DS" to verify the validity of the received digital signature.

[0512] Furthermore, in step 21040, although Fig.21, but the first SSP 2110 may generate a public key "ssp1.bundle.ePK.KA" and a private key "ssp1.bundle.eSK.KA" as a key pair for asymmetric encryption to be used for key negotiation. In this case, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" may be configured to be the same value as the previously generated "ssp1.ePK.KA and ssp1.eSK.KA". Alternatively, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" may be configured to be the same value as the previously used "public key included in ssp1.Cert.KA and the corresponding private key". In addition, the first SSP 2110 may generate a session key ShKey02 using ssp1.bundle.eSK.KA and ssp2.ePK.KA. When "a private key corresponding to a public key included in ssp1.eSK.KA or ssp1.Cert.Ka" is reused for ssp1.bundle.eSK.KA, the value of the session key ShKey02 may also be configured as the value of ShKey01 generated previously.

[0513] In addition, in step 21040, the first SSP 2110 may configure a package to be sent to the second terminal 2150 and / or metadata associated with the package. In this case, the first SSP 2110 may use the received "package transmission code" to identify the package to be sent by itself. In addition, the package to be configured may include "ssp1.Cert.DS". In addition, the package to be configured may also include "ssp1.bundle.ePK.KA". In addition, the package to be configured may also include a transaction ID for identifying a corresponding session. In addition, the package to be configured may optionally further include at least one of a package identifier (SPB ID), a package family identifier (SPB family ID), or a package family manager identifier (SPB family custodian object ID) associated with the package to be sent. According to various embodiments, the package configured in step 21040 (or metadata associated with the package) may include "package transmission configuration".

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

[0515] refer to Fig.21In step 21045, the first SSP 2110 may transmit the packet generated (configured) in step 21040 to the second LBA 2170 via the first LBA 2120. In this case, metadata associated with the transmitted packet may be further transmitted optionally. In addition, a "packet transmission configuration" associated with the transmitted packet may be further transmitted. For example, the "packet transmission configuration" may be transmitted in a separate format (e.g., a message) without being included in the packet or metadata.

[0516] Fig. 22 It is shown Fig.19 A diagram showing the detailed process of completing packet transmission during the process shown.

[0517] Fig. 22 The process is shown to be applied when the transmission history of packets between devices is as follows

[0518] - No prior notice required

[0519] - Require or not require encryption of notification content

[0520] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig. 22 In the example of , the first terminal 2200 may include a first LBA 2220 and a first SSP 2210, and the second terminal 2250 may include a second LBA 2270 and a second SSP 2260. For example, the first terminal 2200 may be a terminal in which the first SSP 2210 is installed and in which the first LBA 2220 for controlling the first SSP 2210 is installed, and the second terminal 2250 may be a terminal in which the second SSP 2260 is installed and in which the second LBA 2270 for controlling the second SSP 2260 is installed.

[0521] refer to Fig. 22 , the following process can be performed in step 22000.

[0522] 1. Installation package

[0523] refer to Fig. 22In step 22000, the second LBA 2270 and the second SSP 2260 may cooperate with each other to install the package in the second terminal 2250. In this process, the following steps may be performed together. When the metadata is transmitted, the second LBA 2270 or the second SSP 2260 may verify the content included in the metadata. When the "package transmission configuration" is transmitted, the second LBA 2270 may transmit the information to the second SSP 2260. When the transaction ID is 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. When at least one of the package identifier (SPB ID), the package family identifier (SPB family ID), or the package family manager identifier (SPB family custodian object ID) is transmitted, the second LBA 2270 or the second SSP 2260 may identify whether the information matches the information of the package currently to be received. When ssp1.Cert.DS is sent, the second SSP 2260 may verify the validity of the certificate to authenticate the first SSP 2210. When the received data includes encrypted data, the second SSP 2260 may generate a session key ShKey02 using the received ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and decrypt the encrypted data using the session key, and then perform verification. When the received data includes a digital signature, the second SSP 2260 may verify ssp1.Cer.DS and then verify the validity of the digital signature using the certificate.

[0524] 2. Identify the "Registration Configuration"

[0525] In addition, although not shown in the figure, the second LBA 2270 and / or the second SSP 2260 can identify whether "notification is required", whether "pre-notification is required", and / or whether the notification content needs to be encrypted using the "registration configuration" of the packet. This process is part of step 22000 and can be performed independently of the order of other processes performed in step 22000. Alternatively, after step 22000, before step 22035 is completed, the process can be performed at a time that needs to be determined. The process that will be described later in the drawings can be a process to be applied when the transmission history of packets between devices does not need to be notified in advance as a result of identifying the "registration configuration".

[0526] refer to Fig. 22In step 22005, the second SSP 2260 may configure the package state to "in transition". "In transition" means a state in which the package has been successfully installed but is not yet available (in addition, a state that can be changed to an available state (disabled, enabled, active state) only by "additional operations to be described later in this figure" and / or additional operations such as "requests from external servers (although not described in this disclosure)".

[0527] refer to Fig. 22 , in step 22010, the second LBA 2270 may request “proof” from the second SSP 2260.

[0528] refer to Fig. 22 , in step 22015, the second SSP 2260 may generate a "proof". Fig. 22 In , the proof can be called finalizationRequest. The structure of the proof can follow Fig.18 The structure disclosed in .

[0529] In this case, one example of a possible proof configuration is as follows.

[0530] -finalizationRequest can be Fig.18 1810 includes a "packet delimiter" of the corresponding packet.

[0531] -finalizationRequest can be Fig.18 1830 includes the "SSP identifier" of the second SSP.

[0532] -finalizationRequest can be Fig.18 1850 includes information instructing the second SSP to configure the packet state to the "transitioning" state.

[0533] -finalizationRequest can optionally be in Fig.18 The finalizationRequest 1870 includes the time when the second SSP changes the package state to the "transitioning" state or the time when the certificate is generated. Alternatively, the finalizationRequest may include information about the certificate used for signing (for the electronic signature described later) and information about the certificate chain related thereto.

[0534] -finalizationRequest can be Fig.18 The signature information of the second SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the second SSP.

[0535] refer to Fig. 22 In step 22020, the second SSP 2260 may transmit the finalizationRequest to the first SSP 2210. For example, the second SSP 2260 may transmit the finalizationRequest to the first SSP 2210 through the following process. That is, in response to step 22010, the second SSP 2260 may transmit the finalizationRequest to the second LBA 2270, and the second LBA 2270 may transmit the finalizationRequest to the first SSP 2210 via the first LBA 2220.

[0536] refer to Fig. 22 , in step 22025, the first SSP 2210 may verify the received finalizationRequest. The verification process may include the step of checking the validity of the signature of the second SSP contained in the finalizationRequest. In addition, the verification process may also include the process of checking whether the "packet delimiter" contained in the finalizationRequest matches the packet delimiter of the corresponding packet. In addition, the verification process may also include the process of checking whether the "SSP identifier" contained in the finalizationRequest is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information contained in the finalizationRequest is instruction information for changing the packet state to the "transitioning" state.

[0537] Additionally, in step 22025, the first SSP 2210 may delete the package after the verification is complete.

[0538] Additionally, in step 22025, the first SSP 2210 may generate a "proof". Fig. 22 In , the proof can be called finalizationResponse. The structure of the proof can follow Fig.18 The structure disclosed in .

[0539] In this case, one example of a possible proof configuration is as follows.

[0540] - FinalizationResponse can be Fig.18 The “packet delimiter” of the corresponding packet is included in 1810. Alternatively, the finalizationResponse may include part and / or all of the data of the finalizationRequest received in the previous step.

[0541] - FinalizationResponse can be Fig.18 1830 includes the "SSP identifier" of the first SSP.

[0542] - FinalizationResponse can be Fig.18 1850 includes information indicating that the first SSP has deleted the package.

[0543] -finalizationResponse can optionally be in Fig.18 The time when the first SSP deleted the package or the time when the certificate was generated in 1870. Alternatively, the finalizationResponse may include information about the certificate used for signing (for the electronic signature described later) and information about the certificate chain related thereto.

[0544] - FinalizationResponse can be Fig.18 The signature information of the first SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the first SSP.

[0545] refer to Fig. 22 In step 22030, the first SSP 2210 may transmit the finalizationResponse to the second SSP 2260. For example, the first SSP 2210 may transmit the finalizationResponse to the second SSP 2260 via the first LBA 2220 and the second LBA 2270.

[0546] refer to Fig. 22In step 22035, the second SSP 2260 may verify the received finalizationResponse. The verification process may include the step of checking the validity of the signature of the first SSP contained in the finalizationResponse. In addition, the verification process may optionally further include the process of checking whether the "packet delimiter" contained in the finalizationResponse matches the packet delimiter of the corresponding packet. In addition, the verification process may include the process of checking whether part or all of the data of the finalizationRequest contained in the finalizationResponse matches the information sent by the second SSP 2260. In addition, the verification process may also include the process of identifying the "SSP identifier" contained in the finalizationResponse. In addition, the verification process may also include the process of identifying whether the instruction information contained in the finalizationResponse is the instruction information for deleting the packet.

[0547] In addition, in step 22035, after the verification is completed, the second SSP 2260 can change the package state to one of the available states (one of disabled, enabled and active). For example, as shown in the figure, the second SSP 2260 can convert the package state to a disabled state.

[0548] Additionally, in step 22035, the second SSP 2260 may generate a "proof". Fig. 22 In , the proof can be called spblAttestation. The structure of the proof can be followed Fig.18 The structure disclosed in .

[0549] In this case, one example of a possible proof configuration is as follows.

[0550] -spblAttestation can be Fig.18 The "packet delimiter" of the corresponding packet is included in 1810. Alternatively, spblAttestation may include part and / or all of the data of finalizationRequest and / or finalizationResponse.

[0551] -spblAttestation can be Fig.18 1830 includes the "SSP identifier" of the second SSP.

[0552] -spblAttestation can be Fig.18 1850 includes information indicating that the second SSP has changed the package state to one of the available states.

[0553] -spblAttestation can optionally be Fig.18 The 1870 includes the time when the second SSP changes the package state to one of the available states, or the time when the attestation is generated. Alternatively, the spblAttestation may include information about the certificate used for signing (for the electronic signature described later), and information about the certificate chain associated therewith.

[0554] -spblAttestation can be Fig.18 The signature information of the second SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the second SSP.

[0555] In addition, in step 22035, the second SSP 2260 may generate its "selected SSP information (sspInforSelected)". The "selected SSP information" may include information on the second SSP to be provided in order to inform the server of the result of the packet transmission between the devices.

[0556] In this case, the "selected SSP information" may include information used for the certificate negotiation process (certificate negotiation information). The "certificate negotiation information" may optionally include information such as

[0557] - The second SSP 2260 can be used to verify the server's certificate information (spbmVerification)

[0558] -The server can be used to verify the certificate information of the first SSP 2210 (SenderSpblVerification)

[0559] - The server can be used to verify the certificate information of the second SSP 2260 (ReceiverSpblVerification)

[0560] In addition, the “certificate negotiation information” may optionally further include a list of key negotiation algorithms supported by the second SSP 2260, and may optionally further include a list of encryption algorithms supported by the second SSP 2260.

[0561] Furthermore, the “selected SSP information” may optionally further include SSP version information including at least one of version information of standard specifications supported by the main platform and the loader included in the second SSP 2260 .

[0562] refer to Fig. 22In step 22040, the second SSP 2260 may transmit the result (eg, success or failure) of the operation performed in step 22035 to the second LBA 2270. In addition, the "selected SSP information" generated in step 22035 may be transmitted together.

[0563] 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.

[0564] Fig.23 It is shown in Fig. 22 A diagram of the process of registering the packet transmission results in the server after the process presented in .

[0565] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.23 In the example of , 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 in which the second SSP 2360 is installed and in which the second LBA 2370 for controlling the second SSP 2360 is installed.

[0566] In addition, according to various embodiments, the server 2300 may be a server operated by a service provider, a package management server, a server operated by cooperation between a service provider and a package management server, or any server operated in association with a service provider and / or a package management server. In the description of the drawings, although the term SPBM as one of possible examples of a server is sometimes used to refer to the server 2300, as described above, the type of server is not limited to SPBM.

[0567] refer to Fig.23 In step 23000, a transport layer security (TLS) connection may be established between the SPBM 2300 and the LBA 2370. Although step 23000 is described as being performed before steps 23005 to 23015 with reference to the drawings, step 23000 may be performed independently of steps 23005 to 23015 before performing step 23020. For example, step 23000 may be performed between steps 23015 and 23020.

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

[0569] refer to Fig.23 In step 23010, the second SSP 2360 may generate its "selected SSP information". For a description of the "selected SSP information", refer to Fig. 22 Description of the description.

[0570] refer to Fig.23 , in step 23015, the second SSP 2360 may send the “selected SSP information” generated in step 23010 to the second LBA 2370.

[0571] Steps 23005 to 23015 may be performed non-selectively.

[0572] refer to Fig.23 In step 23020, the second LBA 2370 may send the "selected SSP information" to the server 2300. When the second LBA 2370 has passed Fig. 22 Steps 22035 to 22040 receive the "selected SSP information" or through Fig.23 When the second LBA 2370 receives the “selected SSP information” in steps 23005 to 23015, the second LBA 2370 may send the received “selected SSP information” to the server 2300. When the second LBA 2370 has not received the “selected SSP information”, the second LBA 2370 may generate the “selected SSP information” and send the SSP information to the server 2300.

[0573] refer to Fig.23 In step 23025, the server 2300 may identify the received "selected SSP information" and generate "server authentication information (SPBM.Auth)" capable of authenticating itself based on the information. The more detailed steps of the process are as follows.

[0574] The server 2300 may use the received "spbmVerification" to identify certificate information that can verify itself, and select at least one key negotiation certificate (spbm.Cert.KA). Alternatively, the server 2300 may use the received "list of key negotiation algorithms supported by the second SSP 2360" to generate a public key "spbm.ePK.KA" and a private key "spbm.eSK.KA" as a key pair for asymmetric encryption to be used for key negotiation, and then select the public key (spbm.ePK.KA) in the key pair. In addition, the server 2300 may use the received "spbmVerification" to identify certificate information that can be verified by itself, and further select at least one signature certificate (spbm.Cert.DS).

[0575] In addition, the server 2300 may use the received 'SenderSpblVerification' to identify whether the certificate information of the first SSP 2210 performing verification is verifiable by itself. This process may not be selectively performed.

[0576] In addition, the server 2300 can use the received "ReceiverSpblVerification" to identify whether the certificate information of the second SSP 2360 performing verification can be verified by itself. Alternatively, the server 2300 can use "ReceiverSpblVerification" to select at least one certificate information of the second SSP 2360 that can be verified by itself, and then configure the corresponding information as "CiPkIdToBeUsed".

[0577] In addition, the server 2300 may select at least one encryption algorithm to be used in the future using the received “encryption algorithm list supported by the second SSP 2360” and configure the corresponding information as “CryptoToBeUsed”.

[0578] Furthermore, the server 2300 may identify the received list of “version information of standard specifications supported by the main platform and loader included in the second SSP 2360 ” and identify whether there is a version of the standard specification supported by itself therein.

[0579] The "server authentication information (SPBM.Auth)" may include at least one of the above-mentioned "spbm.Cert.KA", "spbm.ePK.KA", "CiPkIdToBeUsed" or "CryptoToBeUsed". In addition, the "server authentication information (SPBM.Auth)" may optionally further include the above-mentioned "spbm.Cert.DS".

[0580] In this case, part or all of the above "Server Authentication Information (SPBM.Auth)" may be digitally signed so that it can be verified using spbm.Cert.DS to ensure the integrity of the information, and the digital signature data may be added as part of the "Server Authentication Information".

[0581] refer to Fig.23 In step 23030 , the server 2300 may transmit the “server authentication information (SPBM.Auth)” generated in step 23025 to the second SSP 2360 via the second LBA 2370 .

[0582] refer to Fig.23 , in step 23035, the second SSP 2360 may verify the received "Server Authentication Information (SPBM.Auth)". When the second SSP 2360 receives "spbm.Cert.KA", the second SSP 2360 may identify the signature of the corresponding certificate to identify the validity of the certificate. In addition, when the second SSP 2360 receives "spbm.Cert.DS", the second SSP 2360 may identify the signature of the corresponding certificate to identify the validity of the certificate. In addition, when the second SSP 2360 receives "spbm.ePK.KA" and its digital signature, the second SSP 2360 may use spbm.Cert.DS to identify the digital signature to identify the integrity of the received public key spbm.ePK.KA. In addition, when "CiPkIdToBeUsed" is received, the second SSP 2360 may identify "CiPkIdToBeUsed" to select at least one signing certificate (ssp2.Cert.DS) that can verify itself.

[0583] In addition, although not shown in the figure, in step 23035, the second SSP 2360 may generate a public key "ssp2.ePK.KA" and a private key "ssp2.eSK.KA" as a key pair for asymmetric encryption to be used for key negotiation, and then select the public key (ssp2.ePK.KA) in the key pair. In addition, the second SSP 2360 may select one of the public keys for key negotiation included in spbm.ePK.KA or spbm.Cert.KA, and then use the value and ssp2.eSK.KA to generate a session key ShKey03 to be used for encryption during future communications with the server. ShKey03 should be a session key of the encryption algorithm included in the received "CryptoToBeUsed".

[0584] 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, the "terminal authentication information (Device.Auth)" may also include certificate chain information associated with "ssp2.Cert.DS" and / or "ssp1.Cert.DS". In addition, the "terminal authentication information (Device.Auth)" may include part and / or all of the spblAttestation. In addition, the "terminal authentication information (Device.Auth)" may include part and / or all of the finalizationRequest. In addition, the "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".

[0585] In this case, some or all of the above-mentioned "terminal authentication information (Device.Auth)" can be digitally signed, so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information, and the digital signature data can be added as part of the "terminal authentication information". In addition, part or all of the "terminal authentication information (Device.Auth)" can be encrypted using the previously generated session key ShKey03.

[0586] refer to Fig.23 In step 23040 , the second SSP 2360 may transmit the “terminal authentication information (Device.Auth)” generated in step 23035 to the server 2300 via the second LBA 2370 .

[0587] refer to Fig.23, in step 23045, the server 2300 may verify the received "terminal authentication information (Device.Auth)". The specific steps of the verification process are as follows. The server 2300 may verify the signatures of the received "ssp1.Cert.DS" and / or "ssp2.Cert.DS" to verify the validity of the corresponding certificates. In addition, the server 2300 may verify the signatures of the received spblAttestation, finalizationRequest and / or finalizationResponse. In addition, the server 2300 may verify the contents of the received spblAttestation, finalizationRequest and / or finalizationResponse. In addition, the server 2300 may update the details of the package sent between devices based on the verified content. For example, the server 2300 may update the existing mapping relationship between the package and the first SSP 2210 to a mapping relationship between the package and the second SSP 2360.

[0588] During this process, when the encrypted data is included in the "Terminal Authentication Information (Device.Auth)", the server 2300 can use spbm.eSK.KA or a private key corresponding to the public key for key negotiation included in the received ssp2.ePK.KA and its spbm.Cert.KA to generate a session key ShKey03, decrypt the encrypted data using the session key, and then perform the verification process.

[0589] refer to Fig.23 In step 23050 , the server 2300 may send the result (eg, success or failure) of the operation performed in step 23045 to the second LBA 2370 .

[0590] Fig.24 It is shown Fig.19 Another detailed process diagram of the process of completing packet transmission during the process presented in FIG.

[0591] Fig.24 The process is shown to be applied when the transmission history of packets between devices is as follows

[0592] - no prior notice is required, and

[0593] -Notification content does not need to be encrypted.

[0594] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.24In the example of , the first terminal 2400 may include a first LBA 2420 and a first SSP 2410, and the second terminal 2450 may include a second LBA 2470 and a second SSP 2460. For example, the first terminal 2400 may be a terminal in which the first SSP 2410 is installed and in which the first LBA 2420 for controlling the first SSP 2410 is installed, and the second terminal 2450 may be a terminal in which the second SSP 2460 is installed and in which the second LBA 2470 for controlling the second SSP 2460 is installed.

[0595] refer to Fig.24 , the following process can be performed in step 24000.

[0596] 1. Installation package

[0597] refer to Fig.24 In step 24000, the second LBA 2470 and the second SSP 2460 may cooperate with each other to install the package in the second terminal 2450. In this process, the following steps may be performed together. When the metadata is transmitted, the second LBA 2470 or the second SSP 2460 may verify the content included in the metadata. When the "package transmission configuration" is transmitted, the second LBA 2470 may transmit the information to the second SSP 2460. When the transaction ID is 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. When at least one of the package identifier (SPB ID), the package family identifier (SPB family ID), or the package family manager identifier (SPB family custodian object ID) is transmitted, the second LBA 2470 or the second SSP 2460 may identify whether the information matches the information of the package currently to be received. When ssp1.Cert.DS is sent, the second SSP 2460 may verify the validity of the certificate to authenticate the first SSP 2410. When the received data includes encrypted data, the second SSP 2460 may generate a session key ShKey02 using the received ssp1.bundle.ePK.KA and its ssp2.eSK.KA, decrypt the encrypted data using the session key, and then perform verification. When the received data includes a digital signature, the second SSP 2460 may verify ssp1.Cer.DS and then verify the validity of the digital signature using the certificate.

[0598] 2. Identify the "Registration Configuration"

[0599] In addition, although not shown in the figure, the second LBA 2470 and / or the second SSP 2460 can identify whether "notification is required", whether "pre-notification is required", and / or whether the notification content needs to be encrypted using the "registration configuration" of the packet. This process is part of step 24000 and can be performed independently of the order of other processes performed in step 24000. Alternatively, after step 24000, before step 24035 is completed, the process can be performed at a time that needs to be determined. The process that will be described later in the drawings can be a process to be applied when: as a result of identifying the "registration configuration", the transmission history of the packet between the devices does not need to be notified in advance and the notification content does not need to be encrypted.

[0600] refer to Fig.24 In step 24005, the second SSP 2460 may configure the package state to "in transition". "In transition" means a state in which the package has been successfully installed but is not yet available (in addition, a state that can be changed to an available state (disabled, enabled, active state) only through "additional operations to be described later in this figure" and / or additional operations such as "requests from external servers (although not described in this disclosure)".

[0601] refer to Fig.24 , in step 24010, the second LBA 2470 may request “proof” from the second SSP 2460.

[0602] refer to Fig.24 , in step 24015, the second SSP 2460 may generate a "proof". Fig.24 In , the proof can be called finalizationRequest. The structure of the proof can follow Fig.18 The structure disclosed in .

[0603] In this case, one example of a possible proof configuration is as follows.

[0604] -finalizationRequest can be Fig.18 1810 includes a "packet delimiter" of the corresponding packet.

[0605] -finalizationRequest can be Fig.18 1830 includes the "SSP identifier" of the second SSP.

[0606] -finalizationRequest can be Fig.18 1850 includes information instructing the second SSP to configure the packet state to the "transitioning" state.

[0607] -finalizationRequest can optionally be in Fig.18 The finalizationRequest 1870 includes the time when the second SSP changes the package state to the "transitioning" state or the time when the certificate is generated. Alternatively, the finalizationRequest may include information about the certificate used for signing (for the electronic signature described later) and information about the certificate chain related thereto.

[0608] -finalizationRequest can be Fig.18 The signature information of the second SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the second SSP.

[0609] refer to Figure 2 In step 24020, the second SSP 2460 may transmit the finalizationRequest to the first SSP 2410. For example, the second SSP 2460 may transmit the finalizationRequest to the first SSP 2410 through the following process. That is, in response to step 24010, the second SSP 2460 may transmit the finalizationRequest to the second LBA 2470, and the second LBA 2470 may transmit the finalizationRequest to the first SSP 2410 via the first LBA 2420.

[0610] refer to Fig.24 , in step 24025, the first SSP 2410 may verify the received finalizationRequest. The verification process may include the step of checking the validity of the signature of the second SSP included in the finalizationRequest. In addition, the verification process may also include the process of checking whether the "packet delimiter" included in the finalizationRequest matches the packet delimiter of the corresponding packet. In addition, the verification process may also include the process of checking whether the "SSP identifier" included in the finalizationRequest is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information included in the finalizationRequest is instruction information for changing the packet state to the "transitioning" state.

[0611] Additionally, in step 24025, the first SSP 2410 may delete the package after the verification is complete.

[0612] Additionally, in step 24025, the first SSP 2410 may generate a "proof". Fig.24 In , the proof can be called finalizationResponse. The structure of the proof can follow Fig.18 The structure disclosed in .

[0613] In this case, one example of a possible proof configuration is as follows.

[0614] - FinalizationResponse can be Fig.18 The “packet delimiter” of the corresponding packet is included in 1810. Alternatively, the finalizationResponse may include part and / or all of the data of the finalizationRequest received in the previous step.

[0615] - FinalizationResponse can be Fig.18 1830 includes the "SSP identifier" of the first SSP.

[0616] - FinalizationResponse can be Fig.18 1850 includes information indicating that the first SSP has deleted the package.

[0617] -finalizationResponse can optionally be in Fig.18 The time when the first SSP deleted the package or the time when the certificate was generated may be included in 1870. Alternatively, the finalizationResponse may include information about the certificate used for signing (for electronic signature described later) and information about the certificate chain associated therewith.

[0618] - FinalizationResponse can be Fig.18 The signature information of the first SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the first SSP.

[0619] refer to Fig.24 In step 24030, the first SSP 2410 may transmit the finalizationResponse to the second SSP 2460. For example, the first SSP 2410 may transmit the finalizationResponse to the second SSP 2460 via the first LBA 2420 and the second LBA 2470.

[0620] refer to Fig.24, in step 24035, the second SSP 2460 may verify the received finalizationResponse. The verification process may include the step of checking the validity of the signature of the first SSP contained in the finalizationResponse. In addition, the verification process may optionally further include a process of checking whether the "packet delimiter" contained in the finalizationResponse matches the packet delimiter of the corresponding packet. In addition, the verification process may include a process of checking whether part or all of the data of the finalizationRequest contained in the finalizationResponse matches the information that has been sent by itself. In addition, the verification process may also include a process of identifying the "SSP identifier" contained in the finalizationResponse. In addition, the verification process may also include a process of identifying whether the instruction information included in the finalizationResponse is instruction information for deleting a packet.

[0621] In addition, in step 24035, after the verification is completed, the second SSP 2460 can change the package state to one of the available states (one of disabled, enabled and active). For example, as shown in the figure, the second SSP 2460 can convert the package state to a disabled state.

[0622] Additionally, in step 24035, the second SSP 2460 may generate a "proof". Fig.24 In , the proof can be called spblAttestation. The structure of the proof can be followed Fig.18 The structure disclosed in .

[0623] In this case, one example of a possible proof configuration is as follows.

[0624] -spblAttestation can be Fig.18 The "packet delimiter" of the corresponding packet is included in 1810. Alternatively, spblAttestation may include part and / or all of the data of finalizationRequest and / or finalizationResponse.

[0625] -spblAttestation can be Fig.18 1830 includes the "SSP identifier" of the second SSP.

[0626] -spblAttestation can be Fig.18 1850 includes information indicating that the second SSP has changed the package state to one of the available states.

[0627] -spblAttestation can optionally be Fig.18 The 1870 includes the time when the second SSP changes the package state to one of the available states or the time when the certificate is generated. Alternatively, spblAttestation may include information about the certificate used for signing (for the electronic signature described later), and information about the certificate chain related thereto.

[0628] -spblAttestation can be Fig.18 The signature information of the second SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the second SSP.

[0629] refer to Fig.24 , in step 24040, the second SSP 2460 may send the spblAttestation generated in step 24035.

[0630] Fig.25 It is shown in Fig.24 A diagram of the process of registering the packet transmission results in the server after the process presented in .

[0631] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.25 In the example of , the second terminal 2550 may include a second LBA 2570 and a second SSP 2560. For example, the second terminal 2550 may be a terminal in which the second SSP 2560 is installed and in which the second LBA 2570 for controlling the second SSP 2560 is installed.

[0632] In addition, according to various embodiments, the server 2500 may be a server operated by a service provider, a package management server, a server operated by cooperation between a service provider and a package management server, or any server operated in association with a service provider and / or a package management server. In the description of the drawings, although the term SPBM as one of possible examples of a server is sometimes used to refer to the server 2500, as described above, the type of server is not limited to SPBM.

[0633] refer to Fig.25 In step 25000, a transport layer security (TLS) connection may be established between the SPBM 2500 and the LBA 2570.

[0634] refer to Fig.25In step 25005, the second LBA 2570 may send part and / or all of spblAttestation, finalizationRequest and / or finalizationResponse to the server 2500. In this case, the second LBA 2570 may further send "selected SSP information" to the server 2500. For a description of "selected SSP information", refer to Fig. 22 Description. In addition, the second LBA 2570 may selectively further send "ssp2.Cert.DS" to the server 2500. In addition, the second LBA 2570 may selectively further send "ssp1.Cert.DS" to the server 2500. In addition, the second LBA 2570 may also include the certificate chain information associated with "ssp2.Cert.DS" and / or "ssp1.Cert.DS" to the server 2500. The above information may be configured and sent by the second LBA 2570 itself, although not shown in the figure, but after requesting the corresponding information from the second SSP 2560, the second LBA 2570 may send the received information, or although not shown in the figure, the second LBA 2570 may request part of the corresponding information from the second SSP 2560, and then combine and send the received information and its information.

[0635] refer to Fig.25 , in step 25010, the server 2500 may verify the information received in step 25005. The specific process of the verification process is as follows. The server 2500 may verify the signature of the received "ssp1.Cert.DS" and / or "ssp2.Cert.DS" to verify the validity of the corresponding certificate. In addition, the server 2500 may verify the signature of the received spblAttestation, finalizationRequest and / or finalizationResponse. In addition, the server 2700 may verify the content of the received spblAttestation, finalizationRequest and / or finalizationResponse. In addition, the server 2500 may update the details of the package sent between the devices based on the verified content. For example, the server 2500 may update the existing mapping relationship between the package and the first SSP 2410 to the mapping relationship between the package and the second SSP 2560.

[0636] refer to Fig.25In step 25015, the server 2500 may send the result of the verification operation performed in step 25010 to the second LBA 2570. For example, the server 2500 may send to the second LBA 2570 whether the verification is successful or failed.

[0637] Fig.26 It is shown Fig.19 FIG. 4 is a diagram of another detailed process of completing the transmission of a packet during the process shown in FIG.

[0638] Fig.26 This shows the process to be applied when the transmission history of packets between devices is as follows

[0639] - Prior notice is required, and

[0640] - Require or not require encryption of notification content

[0641] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.26 In the example of , the first terminal 2600 may include a first LBA 2620 and a first SSP 2610, and the second terminal 2650 may include a second LBA 2670 and a second SSP 2660. For example, the first terminal 2600 may be a terminal in which the first SSP 2610 is installed and in which the first LBA 2620 for controlling the first SSP 2610 is installed, and the second terminal 2650 may be a terminal in which the second SSP 2660 is installed and in which the second LBA 2670 for controlling the second SSP 2660 is installed.

[0642] refer to Fig.26 , in step 26000, the following process can be performed.

[0643] 1. Installation package

[0644] refer to Fig.26In step 26000, the second LBA 2670 and the second SSP 2660 may cooperate with each other to install the package in the second terminal 2650. In this process, the following steps may be performed together. When the metadata is sent, the second LBA 2670 or the second SSP 2660 may verify the content included in the metadata. When the "package transmission configuration" is sent, the second LBA 2670 may transmit the information to the second SSP 2660. When the transaction ID is sent, 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. When at least one of the package identifier (SPB ID), the package family identifier (SPB family ID), or the package family manager identifier (SPB family custodian object ID) is sent, the second LBA 2670 or the second SSP 2660 may identify whether the information matches the information of the package currently to be received. When ssp1.Cert.DS is sent, the second SSP 2660 can verify the validity of the certificate to authenticate the first SSP 2610. When the received data includes encrypted data, the second SSP 2660 can generate a session key ShKey02 using the received ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and use the session key to decrypt and verify the encrypted data. When the received data includes a digital signature, the second SSP 2660 can verify ssp1.Cer.DS and then verify the validity of the digital signature using the certificate.

[0645] 2. Identify whether pre-registration is required

[0646] In addition, although not shown in the figure, the second LBA 2670 and / or the second SSP 2660 can identify whether "notification" is required, whether "pre-notification" is required, and / or whether the notification content needs to be encrypted using the "registration configuration" of the packet. This process is part of step 26000 and can be performed independently of the order of other processes performed in step 26000. Alternatively, after step 26000, before step 26035 is completed, the process can be performed at a time that needs to be determined. The process that will be described later in the drawings can be a process to be applied when the transmission history of packets between devices does not need to be pre-notified as a result of identifying the "registration configuration".

[0647] refer to Fig.26 In step 26005, the second SSP 2660 may configure the package status as "in transition". "In transition" means that the package has been successfully installed but is not yet available (in addition, only through the "additional operations described later in this figure" and the reference Fig. 27The state of the processor may be changed to an available state (disabled, enabled, active state) by additional operations described and / or additional operations such as “request from an external server (although not described in the present disclosure)”.

[0648] refer to Fig.26 , in step 26010, the second LBA 2670 may request “proof” from the second SSP 2660.

[0649] refer to Fig.26 , in step 26015, the second SSP 2660 may generate a "proof". Fig.26 In , the proof can be called finalizationRequest. The structure of the proof can follow Fig.18 The structure disclosed in .

[0650] In this case, one example of a possible proof configuration is as follows.

[0651] -finalizationRequest can be Fig.18 1810 includes a "packet delimiter" of the corresponding packet.

[0652] -finalizationRequest can be Fig.18 1830 includes the "SSP identifier" of the second SSP.

[0653] -finalizationRequest can be Fig.18 1850 includes information instructing the second SSP to configure the packet state to the "transitioning" state.

[0654] -finalizationRequest can optionally be in Fig.18 The finalizationRequest 1870 includes the time when the second SSP changes the package state to the "transitioning" state or the time when the certificate is generated. Alternatively, the finalizationRequest may include information about the certificate used for signing (for the electronic signature described later) and information about the certificate chain related thereto.

[0655] -finalizationRequest can be Fig.18 The signature information of the second SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the second SSP.

[0656] refer to Fig.26In step 26020, the second SSP 2660 may transmit the finalizationRequest to the first SSP 2610. For example, the second SSP 2660 may transmit the finalizationRequest to the first SSP 2610 through the following process. That is, in response to step 26010, the second SSP 2660 may transmit the finalizationRequest to the second LBA 2670, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 2620.

[0657] refer to Fig.26 , in step 26025, the first SSP 2610 may verify the received finalizationRequest. The verification process may include the step of checking the validity of the signature of the second SSP contained in the finalizationRequest. In addition, the verification process may also include the process of checking whether the "packet delimiter" contained in the finalizationRequest matches the packet delimiter of the corresponding packet. In addition, the verification process may also include the process of checking whether the "SSP identifier" contained in the finalizationRequest is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information contained in the finalizationRequest is instruction information for changing the packet state to the "transitioning" state.

[0658] Additionally, in step 26025, the first SSP 2610 may delete the package after the verification is complete.

[0659] Additionally, in step 26025, the first SSP 2610 may generate a "proof". Fig.26 In , the proof can be called finalizationResponse. The structure of the proof can follow Fig.18 The structure disclosed in .

[0660] In this case, one example of a possible proof configuration is as follows.

[0661] - FinalizationResponse can be Fig.18 The “packet delimiter” of the corresponding packet is included in 1810. Alternatively, the finalizationResponse may include part and / or all of the data of the finalizationRequest received in the previous step.

[0662] - FinalizationResponse can be Fig.18 1830 includes the "SSP identifier" of the first SSP.

[0663] - FinalizationResponse can be Fig.18 1850 includes information indicating that the first SSP has deleted the package.

[0664] -finalizationResponse can optionally be in Fig.18 The time when the first SSP deleted the package or the time when the certificate was generated may be included in 1870. Alternatively, the finalizationResponse may include information about the certificate used for signing (for electronic signature described later) and information about the certificate chain associated therewith.

[0665] - FinalizationResponse can be Fig.18 The signature information of the first SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the first SSP.

[0666] refer to Fig.26 In step 26030, the first SSP 2610 may transmit the finalizationResponse to the second SSP 2660. For example, the first SSP 2610 may transmit the finalizationResponse to the second SSP 2660 via the first LBA 2620 and the second LBA 2670.

[0667] refer to Fig.26 , in step 26035, the second SSP 2660 may verify the received finalizationResponse. The verification process may include the step of checking the validity of the signature of the first SSP contained in the finalizationResponse. In addition, the verification process may optionally further include the process of checking whether the "packet delimiter" contained in the finalizationResponse matches the packet delimiter of the corresponding packet. In addition, the verification process may include the process of checking whether part or all of the data of the finalizationRequest contained in the finalizationResponse matches the information that it has already sent. In addition, the verification process may also include the process of identifying the "SSP identifier" contained in the finalizationResponse. In addition, the verification process may also include the process of identifying whether the instruction information contained in the finalizationResponse is the instruction information for deleting the packet.

[0668] In addition, in step 26035, the second SSP 2660 may generate its "selected SSP information (sspInforSelected)". The "selected SSP information" may include information on the second SSP to be provided in order to notify the result of the packet transmission between the server devices.

[0669] In this case, the "selected SSP information" may include information used for the certificate negotiation process (certificate negotiation information). The "certificate negotiation information" may optionally include the following information:

[0670] - The second SSP 2660 can be used to verify the server's certificate information (spbmVerification)

[0671] -The server can be used to verify the certificate information of the first SSP 2610 (SenderSpblVerification)

[0672] - The server can be used to verify the certificate information of the second SSP 2660 (ReceiverSpblVerification)

[0673] In addition, the “certificate negotiation information” may optionally further include a list of key negotiation algorithms supported by the second SSP 2660, and may optionally further include a list of encryption algorithms supported by the second SSP 2660.

[0674] Furthermore, the “selected SSP information” may optionally further include SSP version information including at least one of version information of standard specifications supported by the main platform and the loader included in the second SSP 2660 .

[0675] refer to Fig.26 In step 26040, the second SSP 2660 may transmit the result (eg, success or failure) of the operation performed in step 26035 to the second LBA 2670. In addition, the "selected SSP information" generated in step 26035 may be transmitted together.

[0676] The process of generating the "selected SSP information" in step 26035 and the process of transmitting the "selected SSP information" in step 26040 may be omitted.

[0677] Fig. 27 It is shown in Fig.26 A diagram of the process of registering the packet transmission results in the server after the process presented in .

[0678] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig. 27In the example of , the second terminal 2750 may include a second LBA 2770 and a second SSP 2760. For example, the second terminal 2750 may be a terminal in which the second SSP 2760 is installed and in which the second LBA 2770 for controlling the second SSP 2760 is installed.

[0679] In addition, according to various embodiments, the server 2700 may be a server operated by a service provider, a package management server, a server operated by cooperation between a service provider and a package management server, or any server operated in association with a service provider and / or a package management server. In the description of the drawings, although the term SPBM, which is one of possible examples of a server, is sometimes used to refer to the server 2700, as described above, the type of server is not limited to SPBM.

[0680] refer to Fig. 27 In step 27000, a transport layer security (TLS) connection may be established between the SPBM 2700 and the LBA 2770. Although step 27000 is described as being performed before steps 27005 to 27015 with reference to the drawings, step 27000 may be performed independently of steps 27005 to 27015 before performing step 27020. For example, step 27000 may be performed between steps 27015 and 27020.

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

[0682] refer to Fig. 27 In step 27010, the second SSP 2760 may generate its "selected SSP information". For a description of "selected SSP information", refer to Fig.26 Description.

[0683] refer to Fig. 27 , in step 27015, the second SSP 2760 can send the “selected SSP information” generated in step 27010 to the second LBA 2770.

[0684] In some cases, steps 27005 to 27015 may be omitted.

[0685] refer to Fig. 27 In step 27020, the second LBA 2770 may send the "selected SSP information" to the server 2700. When the second LBA 2770 has passed Fig.26 Steps 26035 to 26040 receive the "selected SSP information" or through Fig. 27 When the second LBA 2770 receives the “selected SSP information” in steps 27005 to 27015, the second LBA 2770 may send the received “selected SSP information” to the server 2700. When the second LBA 2770 has not received the “selected SSP information”, the second LBA 2770 may generate the “selected SSP information” and send the “selected SSP information” to the server 2700.

[0686] refer to Fig. 27 In step 27025, the server 2700 may identify the received "selected SSP information" and generate "server authentication information (SPBM.Auth)" capable of authenticating itself based on the information. More detailed steps of the process are as follows.

[0687] The server 2700 may use the received "spbmVerification" to identify certificate information capable of verifying itself, and select at least one key negotiation certificate (spbm.Cert.KA). Alternatively, the server 2700 may use the received "list of key negotiation algorithms supported by the second SSP 2760" to generate a public key "spbm.ePK.KA" and a private key "spbm.eSK.KA" as a key pair for asymmetric encryption to be used for key negotiation, and then select a public key (spbm.ePK.KA) in the key pair. In addition, the server 2700 may use the received "spbmVerification" to identify certificate information capable of verifying itself, and further select at least one signature certificate (spbm.Cert.DS).

[0688] Furthermore, the server 2700 may use the received 'SenderSpblVerification' to identify whether the certificate information of the first SSP 2610 that performs verification is verifiable by itself.

[0689] In addition, the server 2700 can use the received "ReceiverSpblVerification" to identify whether the certificate information of the second SSP 2760 performing verification can be verified by itself. Alternatively, after selecting at least one certificate information of the second SSP 2760 that can be verified by itself using "ReceiverSpblVerification", the server 2700 can configure the corresponding information as "CiPkIdToBeUsed".

[0690] In addition, the server 2700 may select at least one encryption algorithm to be used in the future using the received “encryption algorithm list supported by the second SSP 2760” and configure the corresponding information as “CryptoToBeUsed”.

[0691] Furthermore, the server 2700 may identify the received list of “version information of standard specifications supported by the main platform and loader included in the second SSP 2760” and identify whether there is a version of the standard specification supported by itself therein.

[0692] The "server authentication information (SPBM.Auth)" may include at least one of the above-mentioned "spbm.Cert.KA", "spbm.ePK.KA", "spbm.Cert.DS", "CiPkIdToBeUsed", or "CryptoToBeUsed".

[0693] In this case, part or all of the above "Server Authentication Information (SPBM.Auth)" may be digitally signed so that it can be verified using spbm.Cert.DS to ensure the integrity of the information, and the digital signature data may be added as part of the "Server Authentication Information".

[0694] refer to Fig. 27 In step 27030 , the server 2700 may transmit the “server authentication information (SPBM.Auth)” generated in step 27025 to the second SSP 2760 via the second LBA 2770 .

[0695] refer to Fig. 27 , in step 27035, the second SSP 2760 may verify the received "Server Authentication Information (SPBM.Auth)". When the second SSP 2760 receives "spbm.Cert.KA", the second SSP 2760 may identify the signature of the corresponding certificate to identify the validity of the certificate. In addition, when the second SSP 2760 receives "spbm.Cert.DS", the second SSP 2760 may identify the signature of the corresponding certificate to identify the validity of the certificate. In addition, when the second SSP 2760 receives "spbm.ePK.KA" and its digital signature, the second SSP 2760 may use spbm.Cert.DS to identify the digital signature to identify the integrity of the received public key spbm.ePK.KA. In addition, upon receiving "CiPkIdToBeUsed", the second SSP 2760 may identify "CiPkIdToBeUsed" to select at least one signing certificate (ssp2.Cert.DS) that can verify itself.

[0696] In addition, although not shown in the figure, in step 27035, the second SSP 2760 may generate a public key "ssp2.ePK.KA" and a private key "ssp2.eSK.KA" as a key pair for asymmetric encryption to be used for key negotiation, and then select the public key (ssp2.ePK.KA) in the key pair. In addition, the second SSP 2760 may select one of the spbm.ePK.KA or the public key for key negotiation included in the spbm.Cert.KA, and then use the value and ssp2.eSK.KA to generate a session key ShKey03 for encryption during future communications with the server. ShKey03 should be a session key for the encryption algorithm included in the received "CryptoToBeUsed".

[0697] 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, the "terminal authentication information (Device.Auth)" may include part and / or all of the finalizationRequest. In addition, the "terminal authentication information (Device.Auth)" may include part and / or all of the finalizationResponse.

[0698] In this case, some or all of the above-mentioned "terminal authentication information (Device.Auth)" can be digitally signed, so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information, and the digital signature data can be added as part of the "terminal authentication information". In addition, some or all of the "terminal authentication information (Device.Auth)" can be encrypted using the previously generated session key ShKey03.

[0699] refer to Fig. 27 In step 27040 , the second SSP 2760 may send the “terminal authentication information (Device.Auth)” generated in step 27035 to the server 2700 via the second LBA 2770 .

[0700] refer to Fig. 27, in step 27045, the server 2700 may verify the received "terminal authentication information (Device.Auth)". The specific steps of the verification process are as follows. The server 2700 may verify the signatures of the received "ssp1.Cert.DS" and / or "ssp2.Cert.DS" to verify the validity of the corresponding certificates. In addition, the server 2700 may verify the signatures of the received finalizationRequest and / or finalizationResponse. In addition, 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 packages sent between devices based on the verified contents. For example, the server 2700 may update the existing mapping relationship between the package and the first SSP 2610 to a mapping relationship between the package and the second SSP 2760.

[0701] During this process, when the encrypted data is included in the "Terminal Authentication Information (Device.Auth)", the server 2700 can use spbm.eSK.KA or a private key corresponding to the public key for key negotiation included in the received ssp2.ePK.KA and its spbm.Cert.KA to generate a session key ShKey03, decrypt the encrypted data using the session key, and then perform the verification process.

[0702] Additionally, in step 27045, server 2700 may generate a "proof". Fig. 27 In this case, the proof can be called spbmAttestation. The structure of the proof can be followed Fig.18 The structure disclosed in .

[0703] In this case, one example of a possible proof configuration is as follows.

[0704] -spbmAttestation can be Fig.18 The packet delimiter of the packet is included in 1810. Alternatively, spbmAttestation may include part and / or all of the data of finalizationRequest and / or finalizationResponse received in the previous step.

[0705] -spbmAttestation can be Fig.18 1830 includes an identifier of the server (eg, an identifier of the service provider and / or an identifier of the package management server and / or an address of the server).

[0706] -spbmAttestation can be Fig.18 1850 includes information indicating that the server has identified the movement history of the packet.

[0707] -spbmAttestation can optionally be Fig.18 The time at which the server identifies the movement history of the packet or the time at which the certificate is generated is included in 1870. Alternatively, spbmAttestation may include information about a certificate used for signing (for an electronic signature described later), and information about a certificate chain related thereto.

[0708] -spbmAttestation can be Fig.18 The signature information of the server is included in 1890. The signature may be the signature information obtained by digitally signing the above information with the signature certificate of the server.

[0709] Furthermore, in step 27045, although Fig. 27 Not shown, but server 2700 may generate a public key "spbm.attestation.ePK.KA" and a private key "spbm.attestation.eSK.KA" as a key pair for asymmetric encryption to be used for key negotiation. In this case, the key pair "spbm.attestation.ePK.KA and spbm.attestation.eSK.KA" may be configured to be the same value as the previously generated "spbm.ePK.KA and spbm.eSK.KA". Alternatively, the key pair "spbm.attestation.ePK.KA and spbm.attestation.eSK.KA" may be configured to be the same value as the previously used "public key included in spbm.Cert.KA and the corresponding private key". In addition, server 2700 may generate a session key ShKey04 using spbm.attestation.eSK.KA and ssp2.ePK.KA. When "a private key corresponding to a public key included in spbm.eSK.KA or spbm.Cert.Ka is reused for spbm.attstation.eSK.KA, the value of the session key ShKey04 may be configured as the value of ShKey03 generated previously.

[0710] Furthermore, in step 27045, although Fig. 27Although not shown, the server 2700 may configure "attestation verification data". The "attestation verification data" may include "spbm.Cert.DS". In addition, it may also include "spbm.attestation.ePK.KA" and / or the server's digital signature value of "spbm.attestation.ePK.KA".

[0711] According to various embodiments, some and / or all of the "proof" and "proof verification data" generated in step 27045 may be encrypted using ShKey04.

[0712] refer to Fig. 27 In step 27050 , the server 2700 may send the “spbmAttestation” and the “attestation verification data” generated in step 27045 to the second SSP 2760 via the second LBA 2770 .

[0713] refer to Fig. 27 In step 27055, the second SSP 2760 may verify the received "spbmAttestation" and / or "attestation verification data". When the received data includes encrypted data, the second SSP 2760 may generate a session key ShKey04 using the received spbm.attestation.ePK.KA and its ssp2.eSK.KA, and use the session key to decrypt and then verify the encrypted data. When the received data includes a digital signature, the second SSP 2760 may verify spbm.Cert.DS and then verify the validity of the digital signature using the certificate.

[0714] In addition, in step 27055, after the verification is completed, the second SSP 2760 can change the package state to one of the available states (one of disabled, enabled and active). For example, as shown in the figure, the second SSP 2760 can convert the package state to a disabled state.

[0715] refer to Fig. 27 In step 27060, the second SSP 2760 may transmit the result of 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.

[0716] Fig.28 is a block diagram showing a configuration of a terminal according to an embodiment of the present disclosure.

[0717] like Fig.28As shown, the terminal may include a transceiver 2810 and at least one processor 2820. In addition, the terminal may also 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 be referred to as a "controller". However, the configuration of the terminal is not limited to Fig.28 configuration and can include Fig.28 The components shown may be more or less than the components shown. According to some embodiments, the transceiver 2810, at least one processor 2820, and a memory (not shown) may be implemented in the form of a single chip. In addition, when the SSP 2830 is embedded in a terminal, the transceiver 2810, at least one processor 2820, and a memory (not shown) may be implemented in the form of a single chip including the SSP 2830.

[0718] According to various embodiments, the transceiver 2810 may send signals, information, data, etc. to a transceiver of another terminal or an external server according to various embodiments of the present disclosure, and receive signals, information, data, etc. from a transceiver of another terminal or an external server. The transceiver 2810 may include an RF transmitter for up-converting and amplifying the frequency of a signal to be transmitted, and an RF receiver for low-noise amplifying a received signal and down-converting its frequency. However, this is merely an example of the transceiver 2810, and the components of the transceiver 2810 are not limited to the RF transmitter and the RF receiver. In addition, the transceiver 2810 may receive a signal through a wireless channel, output the signal to at least one processor 2820, and send a signal output from at least one processor 2820 through a wireless channel.

[0719] According to various embodiments, the transceiver 2810 may transmit or receive SSP information included in another terminal, authentication information capable of authenticating another terminal, authentication information capable of authenticating a server, authentication information capable of authenticating itself, a packet transmission code, a packet transmission configuration, a packet, and a reference signal from a transceiver of another terminal or an external server. Figure 22 to Figure 27 Various proofs described.

[0720] At least one processor 2820 is a component for overall control of the terminal. As described above, according to various embodiments of the present disclosure, at least one processor 2820 may control the overall operation of the terminal.

[0721] The SSP 2830 may include a processor or controller for installing and controlling packages, or may have applications installed therein.

[0722] According to various embodiments, at least one processor or controller in the SSP 2830 may identify the packet transmission configuration to determine whether to send a specific packet. In addition, by identifying the packet transmission configuration, at least one processor or controller may determine whether the result of packet transmission of the corresponding packet between devices needs to be registered in the server, or if registration is required, whether advance notification is required.

[0723] Furthermore, according to various embodiments, at least one processor or controller in the SSP may generate a packet transmission code to control the transmission process of a specific packet.

[0724] Furthermore, according to various embodiments, at least one processor or controller in the SSP may generate its SSP information, and identify and verify SSP information of another SSP received from the outside.

[0725] Furthermore, according to various embodiments, at least one processor or controller in the SSP may generate authentication information capable of authenticating itself and authenticate authentication information of another SSP received from the outside.

[0726] In addition, according to various embodiments, the SSP 2830 may generate a package alone or in cooperation with one or more processors 2820, and install the package. In addition, the SSP 2830 may manage packages.

[0727] In addition, according to various embodiments, SSP 2830 may generate a reference Figure 22 to Figure 27 Describe the various types of certificates and verify received certificates.

[0728] In addition, according to various embodiments, SSP 2830 may change the state of the package based on the contents of the received proof, such as reference Figure 22 to Figure 27 as described.

[0729] 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 packages, or may install applications therein. Some or all of the applications may be installed in the SSP 2830 or in a memory (not shown).

[0730] The terminal may also include a memory (not shown) and store data such as basic programs, applications, and configuration information for terminal operation. In addition, the memory may include at least one storage medium of a flash memory type, a hard disk type, a multimedia micro card type, a card type memory (e.g., SD or XD memory, etc.), a magnetic memory, a disk, an optical disk, a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), a programmable read-only memory (PROM), or an electrically erasable programmable read-only memory (EEPROM). In addition, the processor 2820 may use various programs, contents, data, etc. stored in the memory to perform various operations.

[0731] Fig.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 package management server, a server operated by cooperation between a service provider and a package management server, or any server operated in association with a service provider and / or a package management server. In the description of the figure, the term package management server, which is one of possible examples of a server, is used to refer to the server, but as described above, the type of server is not limited to the package management server.

[0732] According to some embodiments, the package management server may include a transceiver 2910 and at least one processor 2920. However, the configuration of the package management server is not limited to Fig.29 configuration and can include Fig.29 More or fewer components as shown. According to some embodiments, the transceiver 2910, at least one processor 2920 and a memory (not shown) may be implemented in the form of a single chip.

[0733] According to some embodiments, the transceiver 2910 may send and receive signals, information, data, etc. according to various embodiments of the present disclosure to and from the terminal. The transceiver 2910 may include an RF transmitter for up-converting and amplifying the frequency of the signal to be transmitted, and an RF receiver for low-noise amplifying the received signal and down-converting its frequency. However, this is only an embodiment of the transceiver 2910, and the components of the transceiver 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 the signal to at least one processor 2920, and send a signal output from at least one processor 2920 through a wireless channel.

[0734] At least one processor 2920 is a component for overall control of the package management server. As described above, according to various embodiments of the present disclosure, the processor 2920 may control the overall operation of the package management server. The at least one processor 2920 may be referred to as a controller.

[0735] The package management server may also include a memory (not shown) and store data such as basic programs, applications, and configuration information for the operation of the package management server. In addition, the memory may include at least one storage medium of a flash memory type, a hard disk type, a multimedia micro card type, a card type memory (e.g., SD or XD memory, etc.), a magnetic memory, a disk, an optical disk, a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), a programmable read-only memory (PROM), or an electrically erasable programmable read-only memory (EEPROM). In addition, the processor 2920 may perform various operations using various programs, content, data, etc. stored in the memory.

[0736] Fig.30 It is a graphic Fig.19 A diagram of another detailed process of a process for completing packet transmission and a process for registering the packet transmission result in a server among the processes presented in FIG.

[0737] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Fig.30 In the example of , the first terminal 3000 may include a first LBA 3020 and a first SSP 3010, and the second terminal 3050 may include a second LBA 3070 and a second SSP 3060. For example, the first terminal 3000 may be a terminal in which the first SSP 3010 is installed and in which the first LBA 3020 for controlling the first SSP 3010 is installed, and the second terminal 3050 may be a terminal in which the second SSP 3060 is installed and in which the second LBA 3070 for controlling the second SSP 3060 is installed.

[0738] refer to Fig.30 , the following process can be performed in step 30000.

[0739] 1. Installation package

[0740] refer to Fig.30In step 30000, the second LBA 3070 and the second SSP 3060 may cooperate with each other to install the package in the second terminal 3050. In this process, the following steps may be performed together. When sending metadata, the second LBA 3070 or the second SSP 3060 may verify the content included in the metadata. When sending "Package Transfer Configuration", the second LBA 3070 may transfer information to the second SSP 3060. When sending a transaction ID, 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. When sending at least one of a package identifier (SPB ID), a package family identifier (SPB family ID), or a package family manager identifier (SPB family custodian object ID), the second LBA 3070 or the second SSP 3060 may identify whether the information matches the information of the package currently to be received. When sending ssp1.Cert.DS, the second SSP 3060 may verify the validity of the certificate to authenticate the first SSP 3010. When the received data includes encrypted data, the second SSP 3060 can generate a session key ShKey02 using the received ssp1.bundle.ePK.KA and its ssp2.eSK.KA, decrypt the encrypted data using the session key, and then perform verification. When the received data includes a digital signature, the second SSP 3060 can verify ssp1.Cer.DS and then verify the validity of the digital signature using the certificate.

[0741] 2. Identify the "Registration Configuration"

[0742] In addition, although not shown in the figure, the second LBA 3070 and / or the second SSP 3060 may identify whether "notification is required", whether "pre-notification is required", and / or whether the notification content needs to be encrypted using the "registration configuration" of the packet. This process is part of step 30000 and may be performed independently of the order of other processes performed in step 30000. Alternatively, after step 30000, before notification is performed in 30040 or 30050, the "registration configuration" may be identified, and the process may be performed at a time when it needs to be determined.

[0743] refer to Fig.30 In step 30005, the second SSP 3060 may configure the package state as "in transition". "In transition" may indicate a state in which the package has been successfully installed but is unavailable (in addition, a state that can be changed to an available state (disabled, enabled, active state) only by operations such as "request from the first terminal 3000" and / or "request from an external server").

[0744] refer to Fig.30, in step 30010, the second LBA 3070 may request “proof” from the second SSP 3060.

[0745] refer to Fig.30 , in step 30015, the second SSP 3060 may generate a "proof". Fig.30 In , the proof can be called finalizationRequest. The structure of the proof can follow Fig.18 The structure disclosed in .

[0746] In this case, one example of a possible proof configuration is as follows.

[0747] -finalizationRequest can be Fig.18 510 includes a "packet delimiter" corresponding to the packet.

[0748] -finalizationRequest can be Fig.18 530 includes the "SSP identifier" of the second SSP.

[0749] -finalizationRequest can be Fig.18 1850 includes information instructing the second SSP to configure the packet state to the "transitioning" state.

[0750] -finalizationRequest can optionally be in Fig.18 The finalizationRequest 1870 includes the time when the second SSP configured the package state to the "transitioning" state or the time when the certificate was generated. Alternatively, the finalizationRequest may include information about the certificate used for signing (for the electronic signature described later) and information about the certificate chain related thereto.

[0751] -finalizationRequest can be Fig.18 The signature information of the second SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the second SSP.

[0752] refer to Fig. 22In step 30020, the second SSP 3060 may transmit the finalizationRequest to the first SSP 3010. For example, the second SSP 3060 may transmit the finalizationRequest to the first SSP 3010 through the following process. That is, the second SSP 3060 may transmit the finalizationRequest to the second LBA 3070 in response to step 30010, and the second LBA 3070 may transmit the finalizationRequest to the first SSP 3010 via the first LBA 3020.

[0753] refer to Fig.30 , in step 30025, the first SSP 3010 may verify the received finalizationRequest. The verification process may include the step of checking the validity of the signature of the second SSP contained in the finalizationRequest. In addition, the verification process may also include the process of checking whether the "packet delimiter" contained in the finalizationRequest matches the packet delimiter of the corresponding packet. In addition, the verification process may also include the process of checking whether the "SSP identifier" contained in the finalizationRequest is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information contained in the finalizationRequest is instruction information for changing the packet state to the "transitioning" state.

[0754] In addition, in step 30025, after the verification is completed, the first SSP 3010 may configure the package state as "in transition." "In transition" may indicate a state in which the package has been successfully installed but is unavailable (in addition, a state that can be changed to an available state (disabled, enabled, active state) only through additional operations such as "request from the second terminal 3050" and / or "request from an external server").

[0755] Additionally, in step 30025, the first SSP 3010 may generate a "proof". Fig.30 In , the proof can be called finalizationResponse. The structure of the proof can follow Fig.18 The structure disclosed in .

[0756] In this case, one example of a possible proof configuration is as follows.

[0757] - FinalizationResponse can be Fig.18The “packet delimiter” of the corresponding packet is included in 510. Alternatively, the finalizationResponse may include part and / or all of the data of the finalizationRequest received in the previous step.

[0758] - FinalizationResponse can be Fig.18 530 includes the "SSP identifier" of the first SSP.

[0759] - FinalizationResponse can be Fig.18 1850 includes information instructing the first SSP to configure the packet state to the "transitioning" state.

[0760] -finalizationResponse can optionally be in Fig.18 The 1870 includes the time when the first SSP configured the package state to the "transitioning" state or the time when the certificate was generated. Alternatively, the finalizationResponse may include information about the certificate used for signing (for the electronic signature described later) and information about the certificate chain associated therewith.

[0761] - FinalizationResponse can be Fig.18 The signature information of the first SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the first SSP.

[0762] refer to Fig.30 In step 30030, the first SSP 3010 may transmit the finalizationResponse to the second SSP 3060. For example, the first SSP 3010 may transmit the finalizationResponse to the second SSP 3060 via the first LBA 3020 and the second LBA 3070.

[0763] refer to Fig.30, in step 30035, the second SSP 3060 may verify the received finalizationResponse. The verification process may include the step of checking the validity of the signature of the first SSP contained in the finalizationResponse. In addition, the verification process may optionally further include the process of checking whether the "packet delimiter" contained in the finalizationResponse matches the packet delimiter of the corresponding packet. In addition, the verification process may include the process of checking whether part or all of the data of the finalizationRequest contained in the finalizationResponse matches the information that it has already sent. In addition, the verification process may also include the process of identifying the "SSP identifier" contained in the finalizationResponse. In addition, the verification process may also include the process of identifying whether the instruction information contained in the finalizationResponse is the instruction information for configuring the package status as "in transition".

[0764] refer to Fig.30 , the pre-notification process may be performed in step 30040. This process may be applied when the pre-notification is configured to be required in the "Registration Configuration". When the pre-notification process is performed, the process may be as follows.

[0765] First, the second SSP 3060 may generate sspInfoSelected and send the information to the second LBA 3070. This process may be omitted if desired. In this case, the description of sspInfoSelected is referenced to Fig.26 Hereafter, refer to Fig. 27 The process before the "process of changing the package state to one of the available states (one of disabled, enabled, and active)" of step 27055 among the described processes may be executed.

[0766] refer to Fig.30 In step 30045, the second SSP 3060 may change the package state to one of the available states (one of disabled, enabled, and active). For example, as shown, the second SSP 3060 may change the package state to a disabled state.

[0767] Additionally, in step 30045, the second SSP 3060 may generate a "proof". Fig.30 In , the proof can be called spblAttestation. The structure of the proof can be followed Fig.18 The structure disclosed in .

[0768] In this case, one example of a possible proof configuration is as follows.

[0769] -spblAttestation can be Fig.18 The packet delimiter of the corresponding packet is included in 510. Alternatively, spblAttestation may include part and / or all of the data of "finalizationRequest, finalizationResponse and / or spbmAttestation".

[0770] -spblAttestation can be Fig.18 530 includes the "SSP identifier" of the second SSP.

[0771] -spblAttestation can be Fig.18 1850 includes information indicating that the second SSP has changed the package state to one of the available states.

[0772] -spblAttestation can optionally be Fig.18 The 1870 includes the time when the second SSP changes the package state to one of the available states or the time when the certificate is generated. Alternatively, spblAttestation may include information about the certificate used for signing (for the electronic signature described later), and information about the certificate chain related thereto.

[0773] -spblAttestation can be Fig.18 The signature information of the second SSP is included in 1890. The signature may be signature information obtained by digitally signing the above information with the signature certificate of the second SSP.

[0774] refer to Fig.30 In step 30050, a post-notification process may be performed. This process may be applied when it is configured in the "Registration Configuration" that no pre-notification is required. When the post-notification process is performed, the process may be as follows.

[0775] a. When the notification content needs to be encrypted in the "Registration Configuration"

[0776] First, the second SSP 3060 may generate sspInfoSelected and send the information to the second LBA 3070. This process may be omitted if desired. In this case, the description of sspInfoSelected is referenced to Fig. 22 Afterwards, you can execute Fig.23 The process described in .

[0777] b. When the "Registration Configuration" is configured not to encrypt the notification content

[0778] First, the second SSP 3060 may send spblAttestation to the second LBA 3070. Thereafter, reference may be performed. Fig.25 Describe the process.

[0779] refer to Fig.30 In step 30055, the second SSP 3060 may send spblAttestation to the first SSP 3010 via the second LBA 3070 and the first LBA 3020.

[0780] refer to Fig.30 , in step 30060, the first SSP 3010 may verify the received spblAttestation. The verification process may include the step of checking the validity of the signature of the second SSP contained in the spblAttestation. In addition, the verification process may also include the process of checking whether the "packet delimiter" contained in the spblAttestation matches the packet delimiter of the corresponding packet. In addition, the verification process may also include the process of checking whether the "SSP identifier" contained in the spblAttestation is a valid identifier of the second SSP. In addition, the verification process may also include the process of identifying whether the instruction information contained in the spblAttestation is instruction information for configuring the packet state to one of the available states.

[0781] Additionally, in step 30060, the first SSP 3010 may delete the package.

[0782] As needed, the process of generating spblAttestation in step 30045 and / or step 30055 and / or step 30060 may be omitted.

[0783] When the notification process described in step 30040 or 30050 is not completed (for example, when the notification is sent to the server but no response is received), the second terminal may repeatedly resend the notification to the server. The retransmission process may be performed until a maximum value is met according to a pre-configured maximum number of retransmissions, or the retransmission process may be repeatedly performed until a response is received from the server.

[0784] According to the "registration configuration", advance notification is required, but when the package is not available in the first terminal 3000 and the second terminal 3050 due to the failure of the process 30040 to be performed normally, the status of the package installed in the first terminal 3000 and / or the second terminal 3050 can be obtained by referring to Fig.29 Describes a request for a server to change from "in transition" to one of the available states (e.g., disabled).

[0785] In the specific embodiments of the present disclosure described above, the components included in the present disclosure are expressed in the singular or plural, depending on the specific embodiments presented. However, for the case presented for the convenience of description, the singular or plural expression is appropriately selected, and the present disclosure is not limited to singular or plural components, and even if the component is expressed in the plural, it can be configured in the singular, or even if the component is expressed in the singular, it can be configured in the plural.

[0786] Although specific embodiments have been described in the detailed description of the present disclosure, various modifications are possible without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims described below and the equivalents of the claims.

[0787] The various embodiments of the present disclosure and the terms used therein are not intended to limit the technology described in the present disclosure to specific embodiments, but should be understood to include various modifications, equivalents and / or substitutes of the embodiments. In conjunction with the description of the accompanying drawings, the same reference numerals may be used for the same components. Singular expressions may include plural expressions unless the context clearly specifies 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" may include all possible combinations of items listed together. Expressions such as "first" or "second" may modify corresponding components, regardless of order or importance, and are only used to distinguish one component from other components, without limiting the corresponding components. When (e.g., first) components are referred to as being "connected (functionally or in communication)" or "accessed" to another (e.g., second) component, the component may be directly connected to another component or may be connected by another component (e.g., third component).

[0788] The term "module" used in this disclosure includes a unit configured with hardware, software or firmware, and can be used interchangeably with terms such as logic, logic block, component or circuit. A module can be a part or a minimum unit formed as a whole or a part that performs one or more functions. For example, a module can be configured as an application specific integrated circuit (ASIC).

[0789] Various embodiments of the present disclosure may be implemented as software (e.g., a program) including instructions stored in a machine (e.g., a computer) readable storage medium (e.g., an internal memory or an external memory). The machine is a device capable of calling stored instructions from a storage medium and operating according to the called instructions, and may include a terminal according to various embodiments. When the processor executes the command, the processor may directly or use other components under the control of the processor to perform the function corresponding to the command. The command may include code generated or executed by a compiler or an interpreter.

[0790] The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, "non-transitory" means that the storage medium does not include a signal and is tangible, and does not distinguish whether data is stored in the storage medium semi-permanently or temporarily.

[0791] The methods according to various embodiments disclosed in the present disclosure may be provided by being included in a computer program product. The computer program product may be traded as a commodity between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read-only memory (CD-ROM)), or through an application store (e.g., Play Store TM ) online distribution. In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily generated in a storage medium, such as a memory of a manufacturer's server, an application store's server, or a relay server. Each component (e.g., a module or a program) according to various embodiments may be configured with a single entity or multiple entities, and some of the aforementioned subcomponents may be omitted, or other subcomponents may be further included in various embodiments. Alternatively or additionally, some components (e.g., modules or programs) may be integrated into a single entity so that the functions performed by each corresponding component before integration may be performed identically or similarly. According to various embodiments, the operations performed by a module, program, or other component may be performed sequentially, in parallel, repeatedly, or heuristically, or at least some operations may be performed in a different order, omitted, or other operations may be added thereto.

Claims

1. A method performed by a first terminal, the method comprising: Sending a packet to a second terminal, wherein: The package is a secondary platform package SPB included in the smart security platform SSP of the first terminal; receiving a first certificate from the second terminal, the first certificate comprising information about a package state of the second terminal, an SSP identifier of the second terminal, and a signature of the second terminal; verifying the first proof by checking the validity of the SSP identifier and the signature; After verifying the first certificate, generating a second certificate, the second certificate comprising information about the packet state of the first terminal, the SSP identifier of the first terminal and a signature of the first terminal; and The second certificate is sent to the second terminal.

2. The method according to claim 1, wherein the packet status of the first terminal is configured as at least one of deleted, in transition, and paused, and Wherein the method further comprises: receiving, from the second terminal, the generated third proof, the third proof including information on a change in a packet state of the second terminal when the packet state of the first terminal is configured as being in transition; verifying the received third certificate; and After verifying the third certificate, the package of the first terminal is deleted.

3. The method according to claim 1, wherein a fourth certificate is generated by the second terminal, the fourth certificate including information on a verification result of the first certificate and the second certificate, The fourth proof is sent to the server, and The fourth certificate is verified by the server.

4. The method according to claim 1, wherein a fifth proof is generated by a server, the fifth proof comprising an authentication result with the server; The fifth certificate is sent to the second terminal, and The fifth certificate is verified by the second terminal.

5. A method performed by a second terminal, the method comprising: A packet is received from a first terminal, wherein: The package is a secondary platform package SPB included in the smart security platform SSP of the first terminal; Install the package; generating a first certificate, the first certificate comprising information about a packet state of the second terminal, an SSP identifier of the second terminal, and a signature of the second terminal; sending the first certificate to the first terminal; receiving a second certificate from the first terminal, the second certificate comprising information about a package state of the first terminal, an SSP identifier of the first terminal, and a signature of the first terminal; verifying the second certificate by checking the validity of the SSP identifier of the first terminal and the signature of the first terminal; and After verifying the second certificate, packet state configuration information about the second terminal is changed.

6. The method according to claim 5, wherein changing the package status configuration information about the second terminal comprises changing the package status of the second terminal to at least one of enabled, active, and disabled, and wherein the packet status of the first terminal is configured as at least one of deleted, in transition, and paused, and Wherein the method further comprises: generating a third certificate including information on a change in the packet state of the second terminal when the packet state of the first terminal is configured as being in transition; and The third certificate is sent to the first terminal.

7. The method according to claim 5, further comprising: generating a fourth certificate, the fourth certificate including information about a verification result of the first certificate and the second certificate; and The fourth proof is sent to the server.

8. The method according to claim 5, further comprising: receiving the generated fifth certificate from the server, the fifth certificate including an authentication result with the server; verifying the received fifth certificate; as well as After verifying the fifth proof, packet state configuration information about the second terminal is changed.

9. A first terminal, comprising: a transceiver configured to transmit and receive at least one signal; and a controller coupled to the transceiver, Wherein the controller is configured to: Sending a packet to a second terminal, wherein: The package is a secondary platform package SPB included in the smart security platform SSP of the first terminal, receiving a first certificate from the second terminal, the first certificate comprising information about a packet state of the second terminal, an SSP identifier of the second terminal and a signature of the second terminal, verifying the received first certificate by checking the validity of said SSP identifier and said signature, After verifying the first certificate, generating a second certificate, the second certificate comprising information about the packet state of the first terminal, the SSP identifier of the first terminal and a signature of the first terminal, and The second certificate is sent to the second terminal.

10. The first terminal according to claim 9, wherein: The controller is also configured to: receiving the generated third proof including information about a change in the packet state of the second terminal from the second terminal when the packet state of the first terminal is configured as being in transition, verifying the received third proof, and deleting the packet of the first terminal after verifying the third certificate, The packet status of the first terminal is configured as at least one of deleted, in transition, and paused.

11. The first terminal according to claim 9, wherein: generating, by the second terminal, a fourth certificate, the fourth certificate including information on a verification result of the first certificate and the second certificate; The fourth proof is sent to the server, and The fourth certificate is verified by the server.

12. The first terminal according to claim 9, wherein the fifth certificate is generated by a server, and the fifth certificate includes an authentication result with the server; The fifth certificate is sent to the second terminal, and The fifth certificate is verified by the second terminal.

13. A second terminal, comprising: a transceiver configured to transmit and receive at least one signal; and a controller coupled to the transceiver, Wherein the controller is configured to: A packet is received from a first terminal, wherein: The package is a secondary platform package SPB included in the smart security platform SSP of the first terminal, Install said package, generating a first certificate, the first certificate comprising information about the packet state of the second terminal, an SSP identifier of the second terminal and a signature of the second terminal, sending the first certificate to the first terminal, receiving a second certificate from the first terminal, the second certificate comprising information about a packet state of the first terminal, an SSP identifier of the first terminal, and a signature of the first terminal, verifying the received second certificate by checking the validity of the SSP identifier of the first terminal and the signature of the first terminal, and After verifying the second certificate, packet state configuration information about the second terminal is changed.

14. The second terminal according to claim 13, wherein: The controller is also configured to: changing the package state of the second terminal to at least one of enabled, active and disabled, generating a third certificate including information about a change in the packet state of the second terminal when the packet state of the first terminal is configured as being in transition, and sending the third certificate to the first terminal, and The packet status of the first terminal is configured as at least one of deleted, in transition, and paused.

15. The second terminal according to claim 13, wherein: The controller is also configured to: generating a fourth certificate, the fourth certificate including information about a verification result of the first certificate and the second certificate, and The fourth proof is sent to the server.

Images