WO2021054808A1 - 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치 - Google Patents

기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치 Download PDF

Info

Publication number
WO2021054808A1
WO2021054808A1 PCT/KR2020/012728 KR2020012728W WO2021054808A1 WO 2021054808 A1 WO2021054808 A1 WO 2021054808A1 KR 2020012728 W KR2020012728 W KR 2020012728W WO 2021054808 A1 WO2021054808 A1 WO 2021054808A1
Authority
WO
WIPO (PCT)
Prior art keywords
bundle
ssp
terminal
certificate
information
Prior art date
Application number
PCT/KR2020/012728
Other languages
English (en)
French (fr)
Inventor
임태형
구종회
윤강진
이덕기
이혜원
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020200120292A external-priority patent/KR20210034522A/ko
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to CN202080080987.6A priority Critical patent/CN114731505A/zh
Priority to US17/762,047 priority patent/US20220385670A1/en
Priority to JP2022517517A priority patent/JP2022549182A/ja
Priority to EP20865704.9A priority patent/EP4017047A4/en
Publication of WO2021054808A1 publication Critical patent/WO2021054808A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/71—Hardware identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier

Definitions

  • the present disclosure relates to a smart security medium, and more particularly, to a method and an apparatus for setting a state of a bundle after moving a bundle between smart security media.
  • the present disclosure relates to a smart security medium, and more particularly, to a method and apparatus for registering a bundle movement result in a server after a bundle movement between smart security media is performed.
  • a 5G communication system or a pre-5G communication system is called a Beyond 4G Network communication system or an LTE system and a Post LTE system.
  • the 5G communication system is being considered for implementation in the ultra-high frequency (mmWave) band (eg, such as the 60 Giga (60 GHz) band).
  • mmWave ultra-high frequency
  • 5G communication systems include beamforming, massive MIMO, and Full Dimensional MIMO (FD-MIMO).
  • ACM advanced coding modulation
  • FQAM Hybrid FSK and QAM Modulation
  • SWSC Soliding Window Superposition Coding
  • FBMC Filter Bank Multi Carrier
  • NOMA non orthogonal multiple access
  • SCMA sparse code multiple access
  • IoT Internet of Things
  • M2M Machine Type Communication
  • MTC Machine Type Communication
  • a 5G communication system to an IoT network.
  • technologies such as sensor network, machine to machine (M2M), and machine type communication (MTC) are implemented by techniques such as beamforming, MIMO, and array antenna.
  • M2M machine to machine
  • MTC machine type communication
  • cloud RAN cloud radio access network
  • the disclosed embodiment provides an apparatus and method for setting a state of a bundle after bundle transmission is performed when a bundle is moved between security modules included in two electronic devices.
  • the disclosed embodiment provides an apparatus and method for registering a bundle transmission result in a server after bundle transmission is performed when a bundle is moved between security modules included in two electronic devices.
  • the present invention provides a method of operating a first terminal, the method comprising: transmitting a bundle to a second terminal; Receiving, from the second terminal, a first certificate generated including bundle status information of the second terminal; Verifying the received first certificate; After verifying the first certificate, generating a second certificate including bundle status information of the first terminal; And transmitting the second certificate to the second terminal.
  • the bundle state information of the first terminal is characterized in that the bundle state of the first terminal is set to at least one of DELETE, IN TRANSITION, and SUSPENSION.
  • the bundle status of the first terminal when the bundle status of the first terminal is set to IN TRANSITION, receiving a third certificate generated from the second terminal including information on the change of the bundle status of the second terminal; Verifying the received third certificate; And deleting (DELETE) the bundle of the first terminal after verifying the third certificate.
  • a fourth certificate including information on the verification result of the first certificate and the second certificate is generated, the fourth certificate is transmitted to the server, and the server By, the fourth certificate is characterized in that it is verified.
  • a fifth certificate including a result of authentication with the server is generated by the server, and the fifth certificate is transmitted to the second terminal, and by the second terminal, the fifth certificate Characterized in that it is verified.
  • a method of operating a second terminal comprising: receiving a bundle from a first terminal; Installing the bundle; Generating a first certificate including bundle status information of a second terminal; Transmitting the first certificate to the first terminal; Receiving, from the first terminal, a second certificate generated including bundle status information of the first terminal; Verifying the received second certificate; And changing the bundle state setting information of the second terminal after verifying the second certificate.
  • a transceiver capable of transmitting and receiving at least one signal; And a control unit coupled to the transmission/reception unit, wherein the control unit: transmits a bundle to a second terminal, and receives, from the second terminal, a first certificate generated including bundle status information of the second terminal, , To verify the received first certificate, to generate a second certificate including bundle status information of the first terminal after verifying the first certificate, and to transmit the second certificate to the second terminal It characterized in that it is configured.
  • a transceiver capable of transmitting and receiving at least one signal; And a control unit coupled to the transmission/reception unit, wherein the control unit: receives a bundle from a first terminal, installs the bundle, generates a first certificate including bundle status information of a second terminal, and the Transmits the first certificate to a first terminal, receives, from the first terminal, a second certificate generated including bundle status information of the first terminal, verifies the received second certificate, and the After verifying the second certificate, it is characterized in that it is configured to change the bundle state setting information of the second terminal.
  • a bundle installed in one device may be transmitted and installed to another device in a safe and efficient manner, and a state of the bundle may be set after completing the transmission and installation.
  • a bundle installed in one device may be transmitted and installed to another device in a safe and efficient manner, and a transmission result of the bundle may be registered in the server after completing the transmission and installation.
  • FIG. 1 shows a conceptual diagram of an SSP according to an embodiment of the present disclosure.
  • FIG. 2 is a conceptual diagram illustrating an internal structure of an SSP according to an embodiment of the present disclosure.
  • FIG. 3 is a diagram illustrating an example of a component in a terminal used to download and install a bundle through an SSP by a terminal according to an embodiment of the present disclosure.
  • FIG. 4 is a diagram illustrating an example of a method in which two terminals mutually operate in order to transmit a bundle between two terminals according to an embodiment of the present disclosure.
  • FIG. 5 is a diagram illustrating a configuration of a “certificate (Attestaion)” according to some embodiments of the present disclosure.
  • FIG. 6 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure.
  • FIG. 7 is a diagram illustrating a detailed procedure for a procedure for preparing for bundle transmission among the procedures presented in FIG. 6.
  • FIG. 8 is a diagram illustrating a detailed procedure for a procedure in which a bundle is transmitted among the procedures presented in FIG. 6.
  • FIG. 9 is a diagram illustrating a detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 10 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 11 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 12 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 13 is a diagram illustrating an example of a procedure for making a bundle that has been discontinued to be used again.
  • FIG. 14 is a diagram illustrating another example of a procedure for making a bundle that has been discontinued to be used again.
  • 15 is a diagram illustrating another example of a procedure for making a bundle that has been discontinued to be used again.
  • 16 is a diagram illustrating a configuration of a terminal according to some embodiments of the present disclosure.
  • FIG. 17 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 18 is a diagram illustrating a configuration of a "certificate (Attestaion)" according to some embodiments of the present disclosure.
  • 19 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure.
  • FIG. 20 is a diagram illustrating a detailed procedure for a procedure for preparing for bundle transmission among the procedures presented in FIG. 19.
  • FIG. 21 is a diagram showing a detailed procedure for a procedure in which a bundle is transmitted among the procedures presented in FIG. 19.
  • FIG. 22 is a diagram illustrating a detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.
  • FIG. 23 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 22.
  • FIG. 24 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.
  • 25 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 24.
  • FIG. 26 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.
  • FIG. 27 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 26.
  • FIG. 28 is a diagram illustrating a configuration of a terminal according to some embodiments of the present disclosure.
  • 29 is a diagram illustrating a configuration of a server according to some embodiments of the present disclosure.
  • FIG. 30 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19 and a procedure in which a transmission result of a bundle is registered in the server.
  • each block of the flowchart diagrams and combinations of the flowchart diagrams may be executed by computer program instructions. Since these computer program instructions can be mounted on the processor of a general purpose computer, special purpose computer or other programmable data processing equipment, the instructions executed by the processor of the computer or other programmable data processing equipment are described in the flowchart block(s). It creates a means to perform functions.
  • These computer program instructions can also be stored in computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement a function in a particular way, so that the computer-usable or computer-readable memory It is also possible for the instructions stored in the flow chart to produce an article of manufacture containing instruction means for performing the functions described in the flowchart block(s). Since computer program instructions can also be mounted on a computer or other programmable data processing equipment, a series of operating steps are performed on a computer or other programmable data processing equipment to create a computer-executable process to create a computer or other programmable data processing equipment. It is also possible for instructions to perform processing equipment to provide steps for executing the functions described in the flowchart block(s).
  • each block may represent a module, segment, or part of code that contains one or more executable instructions for executing the specified logical function(s).
  • the functions mentioned in the blocks may occur out of order. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order depending on the corresponding function.
  • the term' ⁇ unit' used in this embodiment refers to software or hardware components such as FPGA or ASIC, and' ⁇ unit' performs certain roles.
  • The' ⁇ unit' may be configured to be in an addressable storage medium, or may be configured to reproduce one or more processors.
  • ' ⁇ unit' refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, and procedures. , Subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.
  • components and functions provided in the' ⁇ units' may be combined into a smaller number of elements and' ⁇ units', or may be further separated into additional elements and' ⁇ units'.
  • components and' ⁇ units' may be implemented to play one or more CPUs in a device or a security multimedia card.
  • SE Secure Element
  • security information eg, mobile communication network access key, user identification information such as ID/passport, credit card information, encryption key, etc.
  • a control module eg: It refers to a security module composed of a single chip that can install and operate network access control modules such as USIM, encryption modules, key generation modules, etc.
  • SE can be used in various electronic devices (e.g., smartphones, tablets, wearable devices, automobiles, IoT devices, etc.), and security services (e.g., mobile communication network access, payment, user authentication, etc.) through security information and control modules. Can provide.
  • UICC Universal Integrated Circuit Card
  • eSE Embedded Secure Element
  • SSP Smart Secure Platform
  • UICC and eSE are integrated.
  • fixed Embedded
  • SoC system on chip
  • UICC Universal Integrated Circuit Card
  • the UICC may include an access control module for accessing the mobile communication service provider's network. Examples of access control modules include Universal Subscriber Identity Module (USIM), Subscriber Identity Module (SIM), and IP Multimedia Service Identity Module (ISIM).
  • USIM Universal Subscriber Identity Module
  • SIM Subscriber Identity Module
  • ISIM IP Multimedia Service Identity Module
  • UICC with USIM is also commonly referred to as a USIM card.
  • a UICC including a SIM module is commonly referred to as a SIM card.
  • the SIM module may be installed when manufacturing the UICC or download a SIM module of a mobile communication service to be used at a time desired by the user to the UICC card.
  • the UICC card can also download and install a plurality of SIM modules, and select and use at least one SIM module among them.
  • a UICC card may or may not be fixed to the terminal.
  • the UICC fixed to the terminal is called eUICC (embedded UICC), and in particular, a system-on-chip including a communication processor of the terminal, an application processor, or a single processor structure in which the two processors are integrated.
  • the UICC built in (SoC) may be referred to as iUICC (Integrated UICC).
  • SoC SoC
  • iUICC Integrated UICC
  • eUICC and iUICC are fixed to a terminal and used, and may mean a UICC card that can remotely download and select a SIM module.
  • a UICC card that can remotely download and select a SIM module is collectively referred to as eUICC or iUICC. That is, among UICC cards that can be selected by downloading a SIM module remotely, a UICC card that is fixed or not fixed to the terminal is collectively used as eUICC or iUICC.
  • the SIM module information to be downloaded is collectively referred to as an eUICC profile or iUICC profile, or more simply, a term of a profile.
  • the term UICC may be mixed with SIM
  • the term eUICC may be mixed with eSIM
  • the USIM Profile may have the same meaning as a profile or may mean that information included in a USIM application in the profile is packaged in a software form.
  • eSE embedded Secure Element
  • the eSE is usually manufactured exclusively for the manufacturer at the request of the terminal manufacturer, and can be manufactured including an operating system and a framework.
  • eSE remotely downloads and installs an applet-type service control module, and can be used for various security services such as electronic wallets, ticketing, e-passports, and digital keys.
  • an SE in the form of a single chip attached to an electronic device that can remotely download and install a service control module is collectively referred to as eSE.
  • SSP Smart Secure Platform
  • the SSP may include one primary platform (PP) and at least one secondary platform bundle (SPB) operating on the PP, and the primary platform includes a hardware platform and a low level operating system (LLOS).
  • the secondary platform bundle may include at least one of a High-level Operating System (HLOS) and an application running on the HLOS.
  • SPBs Smart Secure Platform
  • the bundle accesses resources such as the central processing unit and memory of the PP through the Primary Platform Interface (PPI) provided by the PP, and can be run on the PP through this.
  • the bundle can be loaded with communication applications such as SIM (Subscriber Identification Module), USIM (Universal SIM), ISIM (IP Multimedia SIM), and various application applications such as e-wallets, ticketing, e-passports, and digital keys.
  • SIM Subscriber Identification Module
  • USIM Universal SIM
  • ISIM IP Multimedia SIM
  • e-wallets ticketing, e-passports, and digital keys.
  • the SSP may be referred to as a smart security medium.
  • the SSP can be used for the above-described UICC or eSE according to the downloaded and installed bundles, and a plurality of bundles can be installed in a single SSP and operated at the same time to mix the uses of UICC and eSE. That is, when a bundle including a profile is operated, the SSP can be used for UICC to access the network of a mobile communication service provider.
  • the corresponding UICC bundle may operate by downloading at least one profile remotely into the bundle, such as the eUICC or iUICC, and selecting it.
  • a bundle including a service control module equipped with an application application capable of providing services such as an electronic wallet, ticketing, e-passport, or digital key
  • a plurality of service control modules may be installed and operated by being integrated into one bundle, or they may be installed and operated as independent bundles.
  • the SSP can download and install a bundle from an external bundle management server (Secondary Platform Bundle Manager, SPB Manager) using OTA (Over The Air) technology, or can receive and install a bundle from another terminal.
  • the method of installing the downloaded or transmitted bundle includes a removable SSP (rSSP) that can be inserted and removed in the terminal, a fixed SSP (eSSP) installed in the terminal, and an integrated SSP (iSSP) included in the SoC installed in the terminal. ) Can be applied equally.
  • the “SSP ID (SSP ID)” may be referred to as an sspID as a unique identifier of an SSP embedded in the terminal. Also, as in the embodiment of the present disclosure, when the terminal and the SSP chip are not separated, it may be a terminal ID. It may also refer to a specific bundle identifier (SPB ID) in the SSP. In more detail, it may refer to the bundle identifier of a management bundle or loader (SPBL, Secondary Platform Bundle Loader) that installs, activates, deactivates, and deletes other bundles in the SSP. In addition, it may refer to the Primary Platform Identifier (ID) of the primary platform in the SSP.
  • the SSP may have a plurality of SSP identifiers, and the plurality of SSP identifiers may be values derived from a single unique SSP identifier.
  • SPB Secondary Platform Bundle
  • PP Primary Platform
  • UICC bundle is an application, file system, authentication key value, etc. stored in the existing UICC. It may mean that the operating system (HLOS) in which they operate is packaged in the form of software.
  • HLOS operating system
  • an SPB may be referred to as a bundle.
  • the "state" of the terminal may be as follows.
  • the operation of enabling the bundle by the terminal or the external server is to change the state of the SPB to the enabled state so that the terminal provides the service provided by the bundle (e.g., communication service, credit service through a communication service provider). It may mean an operation of setting to receive a card payment service, a user authentication service, etc.).
  • Bundles in the active state may be expressed as “enabled bundles”.
  • the bundle in the activated state may be stored in an encrypted state in a storage space inside or outside the SSP.
  • the bundle activated in the present disclosure is driven by external input (eg, user input, push, request of an application in the terminal, authentication request from a carrier, PP management message, etc.) or an operation inside the bundle (eg, timer, polling). It can be changed to the state (Active).
  • the running bundle is loaded into the driving memory inside the SSP in the storage space inside or outside the SSP, and it can mean processing security information and providing security services to the terminal using the security control device (Secure CPU) inside the SSP. have.
  • the operation of disabling the bundle by the terminal or the external server may mean an operation of changing the state of the bundle to a disabled state so that the terminal cannot receive the services provided by the bundle.
  • the SPB in the deactivated state may be expressed as a "disabled bundle".
  • the inactive bundle may be stored in an encrypted state in a storage space inside or outside the SSP.
  • the terminal or the external server when the terminal or the external server deletes the bundle, the terminal or the external server no longer causes the terminal or external server to change the state of the bundle to deleted or delete the related data of the bundle including the bundle. It may mean an operation of setting so that the corresponding bundle cannot be driven, activated, or deactivated. Bundles in the deleted state may be expressed as "deleted bundles".
  • “Bundle Image, or Image” may be mixed with a bundle or used as a term indicating a data object of a specific bundle, and may be referred to as a bundle TLV or a bundle image TLV (Bundle Image TLV).
  • the bundle image is encrypted using an encryption parameter, it may be referred to as a protected bundle image (PBI) or a protected bundle image TLV (PBI TLV).
  • the bundle image is encrypted using an encryption parameter that can be decrypted only by a specific SSP, it may be referred to as a bound bundle image (BBI) or a bundled bundle image TLV (BBI TLV).
  • the bundle image TLV may be a data set representing information constituting a bundle in a TLV (Tag, Length, Value) format.
  • the "bundle identifier" will be referred to as a factor matching the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), bundle family manager identifier (SPB Family Custodian Object ID), bundle matching ID, and event identifier (Event ID).
  • the bundle identifier may indicate a unique identifier of each bundle.
  • the bundle family identifier may indicate an identifier for classifying the type of a bundle (eg, a telecom bundle for accessing a mobile communication company network). In the present disclosure, the bundle family identifier may be referred to as Famaily ID, Fid, or FID.
  • the bundle family manager identifier may indicate an identifier that identifies a subject that manages the bundle family identifier (eg, a communication service provider, a terminal manufacturer, a specific organization, etc.).
  • the bundle family manager identifier may be referred to as OID or Oid.
  • the bundle identifier can be used as a value that allows the bundle management server or terminal to index the bundle.
  • Bundle metadata is a term representing a set of information that can refer to or describe a bundle.
  • Bundle metadata may include the bundle identifier described above.
  • the bundle metadata may further include information on the properties, characteristics, or settings of the bundle.
  • Bundle metadata may be expressed as "metadata”.
  • the "bundle management server” creates a bundle at the request of a service provider or other bundle management server, encrypts the generated bundle, generates a bundle remote management command, or encrypts the generated bundle remote management command. May contain functions.
  • the bundle management server that provides the above functions is SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), IDS (Image Delivery Server), SM-DP (Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation plus).
  • Admin Bundle Server Managing SM-DP+ (Managing Subscription Manager Data Preparation plus), Bundle Encryption Server, Bundle Generation Server, Bundle Provisioner (BP), Bundle Provider, BPC holder (Bundle Provisioning Credentials holder) ) Can be expressed as at least one of.
  • the bundle management server may download, install, or update a bundle from the SSP, and may play a role of managing key and certificate settings for remotely managing the state of the bundle.
  • Bundle management servers that provide the above functions include Secondary Platform Bundle Manager (SPBM), Remote Bundle Manager (RBM), Image Delivery Server (IDS), Subscription Manager Secure Routing (SM-SR), and Subscription Manager Secure Routing Plus (SM-SR+). ), an off-card entity of eUICC Profile Manager, PMC holder (Profile Management Credentials holder), and EM (eUICC Manager).
  • the opening brokerage server may receive an event registration request (Register Event Request, Event Register Request) from one or more bundle management servers or opening brokerage servers.
  • one or more opening brokerage servers may be used in combination, and in this case, the first opening brokerage server may receive an event registration request from not only the bundle management server but also the second opening brokerage server.
  • the function of the opening intermediary server may be integrated into the bundle management server.
  • the opening intermediary server that provides the above functions is SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), SPBDS (Secondary Platform Bundle Discovery Sever), BDS (Bundle Discovery Sever), SM-DS (Subscription Manager Discovery Service), It may be expressed as at least one of DS (Discovery Service), Root SM-DS, and Alternative SM-DS.
  • SPBM Secondary Platform Bundle Manager
  • RBM Remote Bundle Manager
  • SPBDS Secondary Platform Bundle Discovery Sever
  • BDS Bundle Discovery Sever
  • SM-DS Subscribescription Manager Discovery Service
  • It may be expressed as at least one of DS (Discovery Service), Root SM-DS, and Alternative SM-DS.
  • the bundle management server may collectively refer to a combination of a function of generating, encrypting, and transmitting a bundle or bundle remote management command, and a function of setting an SSP and managing an installed bundle. In addition, it may be collectively referred to as a combination of the functions of the activation intermediary server. Accordingly, in various embodiments of the present disclosure, operations of the bundle management server and the opening intermediary server may be performed in one bundle management server. In addition, each function may be separately performed by a plurality of bundle management servers separated from each other. In addition, in the specification of the present disclosure, the bundle management server or the opening intermediary server may be expressed as a bundle server.
  • the bundle server may be one of a bundle management server and an opening brokerage server, or may be a device including both a bundle management server and an opening brokerage server.
  • Service Provider may indicate a business entity that issues a request to a bundle management server to request a bundle creation, and provides a service to a terminal through the bundle.
  • it may represent a mobile operator that provides a communication network access service through a bundle equipped with a communication application, and the business support system (BSS) of the communication service provider, and the Operational Supporting System , OSS), POS terminal (Point of Sale Terminal), and other IT systems can all be collectively referred to.
  • BSS business support system
  • OSS Operational Supporting System
  • POS terminal Point of Sale Terminal
  • IT systems Point of Sale Terminal
  • a service provider is not limited to expressing only one specific business entity, and may be used as a term referring to a group or association or consortium of one or more businesses or an agency representing the group or association.
  • a service provider may be named as an operator (Operator or OP or Op.), a bundle owner (BO), an image owner (Image Owner, IO), etc., and each service provider is a name and/or unique At least one or more identifiers (Object Identifier, OID) may be set or assigned. If the service provider refers to a group or association or agency of more than one business entity, the name or unique identifier of any group or association or agency is shared by all businesses belonging to that group or association, or by all businesses working with the agency. It may be a name or a unique identifier.
  • Subscriber may be used as a term referring to a service provider having ownership of the terminal or an end user having ownership of the terminal.
  • the former may be referred to as an M2M device, and the latter may be referred to as a user terminal (Consumer Device).
  • M2M terminal there may be an end user who does not have ownership of the terminal but transfers or leases the terminal from a service provider, and in this case, the user may be different or the same as the service provider. .
  • Subscriber intent may be used as a term collectively referring to the intention that the subscriber intends to manage the bundle locally or remotely.
  • the subscriber intent refers to an end user intent
  • the subscriber intent may be used as a term referring to a service provider intent.
  • End User consent may be used as a term indicating whether a user agrees to perform local management or remote management.
  • The'terminal' includes a mobile station (MS), a user equipment (UE), a user terminal (UT), a wireless terminal, an access terminal (AT), a terminal, a subscriber unit, and a subscriber station (SS); Subscriber Station), wireless device, wireless communication device, wireless transmit/receive unit (WTRU), mobile node, mobile or other terms.
  • Various embodiments of the terminal include a cellular phone, a smart phone having a wireless communication function, a personal portable terminal (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, and a digital camera having a wireless communication function.
  • the terminal may include a machine to machine (M2M) terminal and a machine type communication (MTC) terminal/device, but is not limited thereto.
  • M2M machine to machine
  • MTC machine type communication
  • the terminal may also be referred to as an electronic device.
  • an SSP capable of downloading and installing a bundle may be embedded in the electronic device.
  • the SSP physically separated from the electronic device may be inserted into the electronic device and connected to the electronic device.
  • the SSP may be inserted into an electronic device in the form of a card.
  • the electronic device may include a terminal, and in this case, the terminal may be a terminal including an SSP capable of downloading and installing a bundle.
  • the SSP can be inserted into the terminal, or inserted into the terminal to be connected to the terminal.
  • LBA Local Bundle Assistant
  • LBM Local Bundle Manager
  • a “loader (SPBL, Secondary Platform Bundle Loader)” may refer to a management bundle that installs other bundles in the SSP and manages activation, deactivation, and deletion.
  • the LBA of the terminal or the remote server can install, activate, deactivate, or delete a specific bundle through the loader.
  • the operation of the loader may also be described as the operation of the SSP including the loader.
  • Event may be a term collectively referring to bundle download, remote bundle management, or other bundle or SSP management/processing command.
  • the event can be named as a remote bundle provisioning operation (or RBP operation, or RBP operation) or an event record, and each event is an event identifier corresponding thereto. , Event ID, EventID) or matching identifier (Matching Identifier, Matching ID, MatchingID), and at least one address (FQDN, IP Address, or URL) or each server identifier of the bundle management server or opening brokerage server in which the event is stored It may be referred to as containing data.
  • Bundle Download can be mixed with Bundle Installation.
  • Event Type can be used as a term indicating whether a specific event is a bundle download, remote bundle management (e.g., delete, activate, deactivate, replace, update, etc.), or other bundle or SSP management/handling command.
  • it may be named as an operation type (Operation Type or OperationType), an operation classification (Operation Class or OperationClass), an event request type, an event class, an event request class, etc. .
  • LBM Local Bundle Management
  • LBM Package Bundle Local Management Package, Local Management Package, Local Management Command Package, and Local Command Package.
  • LBM installs an arbitrary bundle through software installed on the terminal, changes the status of a specific bundle (Enabled, Disabled, Deleted), or changes the contents of a specific bundle (e.g., the bundle nickname). , Or bundle summary information (Bundle Metadata), etc.).
  • the LBM may include more than one local management command, and in this case, the bundles subject to each local management command may be the same or different for each local management command.
  • Remote Bundle Management is a bundle remote management (Bundle Remote Management), remote management (Remote Management), remote management command (Remote Management Command), remote command (Remote Command), remote bundle management package ( RBM Package), Bundle Remote Management Package, Remote Management Package, Remote Management Command Package, and Remote Command Package.
  • RBM installs an arbitrary bundle, changes the state of a specific bundle (Enabled, Disabled, Deleted), or changes the content of a specific bundle (e.g., bundle nickname, or bundle summary information (Bundle Metadata), etc.) can be used for updating.
  • the RBM may contain more than one remote management command, and the bundles subject to each remote management command may be the same or different for each remote management command.
  • Target Bundle may be used as a term referring to a bundle that is a target of a local management command or a remote management command.
  • Bin Rule may be used as a term referring to information to be checked by a terminal when performing local management or remote management on a target bundle. Also, the bundle rule may be used interchangeably with terms such as a bundle policy, a rule, and a policy.
  • “Certificate” or digital certificate is a mutual authentication based on an asymmetric key consisting of a pair of a public key (PK) and a secret key (SK). It may represent a digital certificate used for. Each certificate includes one or more public keys (PK), a public key identifier (PKID) corresponding to each public key, and the identifier of the certificate issuer (CI) that issued the certificate. (Certificate Issuer ID) and digital signature (Digital Signature) may be included.
  • a certificate issuer may be referred to as a certification issuer, a certificate authority (CA), a certification authority, or the like.
  • a public key (PK) and a public key identifier are a specific public key or a certificate including the public key, or a part of a specific public key or a certificate including the public key.
  • a part or a result of an operation of a specific public key e.g., hash
  • a result of an operation of a certificate containing the public key e.g., hash
  • a part of a specific public key It has the same meaning as an operation result (eg, hash) value or an operation result (eg, hash) value of a part of the certificate containing the corresponding public key, or the storage space in which data is stored. They can be used interchangeably.
  • Certificate Chain or Certificate Hierarchy is used by certificates (primary certificates) issued by the “Certificate Issuer” to issue other certificates (secondary certificates), or 2 When secondary certificates are used to issue third or higher certificates in connection, the correlation between the corresponding certificates can be indicated.
  • the CI certificate used for issuing the initial certificate is the Root of Certificate, the highest certificate, the Root CI, the Root CI Certificate, the Root CA, and the Root CA. Certificate).
  • FIG. 1 shows a conceptual diagram of an SSP according to an embodiment of the present disclosure.
  • the terminal 110 may include the SSP 120.
  • the SSP 120 may be embedded in the SoC 130 of the terminal 110.
  • the SoC 130 may be a communication processor, an application processor, or a processor in which the two processors are integrated.
  • the SSP 120 may be a detachable type 122 in the form of an independent chip without being integrated into the SoC, or may be a built-in type 124 that is pre-embedded in the terminal 110.
  • the SSP 120 included in the terminal may include at least one of one or more telecom bundles, one or more payment bundles, and one or more electronic identification card bundles.
  • the terminal 110 when a plurality of telecom bundles 140 and 150 are included in the SSP 120, the terminal 110 simultaneously transmits a plurality of telecom bundles 140 and 150 according to the setting.
  • the terminal 110 uses the payment bundle 170 to make online payment through a terminal app or an external credit card PoS (Point Offline payment through the device can be used, and the identity of the terminal owner can be authenticated using the electronic identification card bundle 180.
  • PoS Point Offline payment through the device can be used, and the identity of the terminal owner can be authenticated using the electronic identification card bundle 180.
  • SSP Smart Secure Platform
  • the SSP 210 includes one primary platform (PP) 220 and at least one secondary platform bundle (SPB) operating thereon. ) (230, 240) may be included.
  • PP primary platform
  • SPB secondary platform bundle
  • the primary platform 220 may include hardware (not disclosed) and at least one low level operating system (LLOS) 222.
  • LLOS low level operating system
  • the secondary platform bundle 230 may include a high-level operating system (HLOS) 232 and at least one application 234 operating thereon.
  • HLOS high-level operating system
  • each of the secondary platform bundles 230 and 240 accesses resources such as a central processing unit and memory of the primary platform 220 using a primary platform interface (PPI) 250 And through this, it can be driven in the SSP (210).
  • PPI primary platform interface
  • FIG. 3 is a diagram illustrating an example of an internal component of a terminal for a terminal to download and install a bundle through an SSP according to an embodiment of the present disclosure.
  • the terminal 310 may include an LBA 312 for controlling the SSP 330 and/or the SSP 330.
  • the terminal 310 may be a terminal equipped with an SSP 330 and an LBA 312 for controlling the SSP 330.
  • the SSP 330 may be embedded in the terminal 310 or may be detachable.
  • the SSP 330 includes at least one of a primary platform 331, a secondary platform bundle loader (SPBL) 333, and one or more secondary platform bundles 335, 337, or 339. It can contain one.
  • SPBL secondary platform bundle loader
  • the secondary platform bundle 335, 337, or 339 is not installed inside the SSP 330 at the time of terminal shipment, but may be downloaded and installed remotely after shipment.
  • each bundle may have a different bundle family identifier and/or a bundle family manager identifier 341, 342, or 343.
  • These bundle family identifiers and bundle family manager identifiers may be used as information necessary for downloading and installing bundles. That is, the SSP 330 or the SPBL 333 may allow or reject the download and installation of a specific bundle according to the bundle family identifier and the bundle family manager identifier.
  • FIG. 4 is a diagram illustrating an example of a method in which two terminals mutually operate in order to transmit a bundle between two terminals according to an embodiment of the present disclosure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 400 includes the LBA 410 and the SSP 420
  • the second terminal 450 includes the LBA 460 and the SSP 470. can do.
  • the user may send a command to the terminal or receive information to be provided by the user from the terminal.
  • the first user 440 and the second user 490 issue commands to the LBAs 410 and 460 of the first terminal 400 and the second terminal 450. It is possible to send or receive information to be provided by the user from the LBAs 410 and 460.
  • the above operation may include a process of selecting a bundle to be transmitted by the user.
  • the above operation may further include a process of confirming the information of the bundle that the user wants to receive.
  • the above operation may further include an operation of approving whether to transmit a bundle to be transmitted by the user.
  • the above operation may further include an operation of approving whether to transmit a bundle to be transmitted by the user.
  • the above operation may include a process of selecting a bundle in order for the user to resume use of a bundle that has been suspended.
  • the above operation may further include a process of checking information on the bundle for which the user has received a request to resume use.
  • the above operation may further include an operation of approving a bundle to be resumed by the user.
  • the above operation may further include an operation of approving the resumption of use of the bundle for which the user has received a request to resume use.
  • selection and approval operations may not all be operated independently of each other, or one or more operations may be independently selected and operated.
  • the LBAs 410 and 460 may issue commands to the SSPs 420 and 470 or transmit and receive data with the SSPs 420 and 470.
  • the LBA may receive the above-described user's command and transmit the command to the SSP.
  • the LBA may receive the result transmitted by the SSP as a result.
  • the LBA may transmit a command or data received from another terminal or an external server to the SSP.
  • the LBA may receive a result transmitted by the SSP as a result.
  • the LBA may define a new command and data based on a command of a user or a command or data received from another terminal or an external server, and transmit this to the SSP.
  • the LBA when the LBA defines new commands and data based on the user's command or commands or data received from other terminals or external servers and delivers them to the SSP, the LBA receives the result sent by the SSP as a result. can do.
  • the LBA and the SSP may transmit and receive data to and from each other to install a bundle.
  • the two LBAs 410 and 460 may be connected to each other to give a command to the other party or transmit/receive data with the other party.
  • the connection in operation 4050 may be a direct connection between the terminal and the device of the terminal, and although not shown, an external entity (eg, an external server) is connected between the connection between the two LBAs 410 and 460. It may be a connection between devices.
  • the SSPs 420 and 470 may generate, process, or verify necessary data within the SSP.
  • the SSP may check the bundle movement setting.
  • the SSP can generate and utilize the bundle movement code.
  • the operation related to the bundle movement setting and the operation related to the bundle movement code described above are functions independent of each other, and both functions may not be executed, only one of the two functions, or both functions may be executed. Even when both functions are executed, both functions can be performed as completely independent functions.
  • the SSP may generate its own SSP information or verify SSP information received from a counterpart terminal and/or a server.
  • the SSP may generate authentication data capable of verifying itself or may verify authentication data received from the counterpart terminal.
  • the SSP may generate a "certificate” to be described in FIG. 5 and verify the received "certificate”. Examples of various "certificates" that the SSP can generate/verify will be described with reference to FIGS. 10 to 15 and 22 to 27 to be described later.
  • the SSP may set the state of the bundle.
  • the states and setting conditions of various bundles that can be set by the SSP will be described with reference to FIGS. 10 to 15 and 22 to 27 to be described later.
  • the SSP may generate a bundle.
  • FIG. 5 is a diagram illustrating a configuration of a "certificate (Attestation)" according to some embodiments of the present disclosure.
  • the certificate may optionally include a "bundle identifier" (510).
  • the certificate may selectively include a bundle identifier (SPB ID), which is one of the bundle identifiers, as shown in FIG. 5.
  • SPB ID bundle identifier
  • the certificate may optionally further include another certificate (530 ).
  • another certificate included in the certificate will be referred to the description of FIGS. 10 to 15 which will be described later.
  • the certificate may optionally further include an “SSP identifier (SSP ID)” (540).
  • the certificate may optionally further include information on an operation performed by the SSP (550).
  • SSP operation performed by the SSP
  • FIGS. 10 to 15 various examples of operations performed by the SSP will be described with reference to the description of FIGS. 10 to 15 to be described later.
  • the certificate may optionally further include other data other than the above-described information 530, 540, and 550 if necessary (520).
  • other data that may be included in the certificate, reference is made to the description of FIGS. 10 to 15 which will be described later.
  • the certificate may include electronic signature data for the above-described information (560).
  • This signature data may be an electronic signature generated by the SSP's signature certificate.
  • FIG. 6 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 600 includes a first LBA 620 and a first SSP 610
  • the second terminal 650 includes a second LBA 670 and It may include a second SSP (660).
  • the first terminal 600 may be a terminal equipped with a first SSP 610 and a first LBA 620 for controlling the first SSP 610
  • the second terminal 650 2 It may be a terminal in which the SSP 660 is mounted and the second LBA 670 for controlling the second SSP 660 is installed.
  • step 6000 the first SSP 610 of the first terminal 600, the first LBA 620, and the second LBA 670 of the second terminal 650 are prepared for bundle transmission.
  • You can perform a procedure (a procedure for preparing to send a bundle).
  • a procedure a procedure for preparing to send a bundle.
  • step 6005 a procedure of transmitting a bundle from the first terminal 600 to the second terminal 650 (a bundle transmission procedure) may be performed.
  • a bundle transmission procedure For a more detailed description of the above procedure, refer to the detailed description of FIG. 8 to be described later.
  • the first terminal 600 and the second terminal 660 may perform a procedure for installing a transmitted bundle and a procedure for setting a state of the bundle (a procedure for completing a bundle transmission).
  • a procedure for installing a transmitted bundle and a procedure for setting a state of the bundle (a procedure for completing a bundle transmission).
  • FIG. 7 is a diagram illustrating a detailed procedure for a procedure for preparing for bundle transmission among the procedures presented in FIG. 6.
  • FIG. 7 is a diagram illustrating a procedure in which one terminal undergoes a necessary preparation process to transmit a bundle to another terminal according to an embodiment of the present disclosure.
  • the procedure of FIG. 7 may be referred to as a bundle transmission preparation procedure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 700 includes a first LBA 720 and a first SSP 710
  • the second terminal 750 includes a second LBA 770 and It may include a second SSP (760).
  • the first terminal 700 may be a terminal equipped with a first SSP 710 and a first LBA 720 for controlling the first SSP 710
  • the second terminal 750 2 It may be a terminal in which the SSP 760 is mounted and the second LBA 770 for controlling the second SSP 760 is installed.
  • the first terminal 700 may have a pre-installed bundle, and may further have metadata associated with the bundle.
  • the first terminal 700 is associated with a corresponding bundle to provide at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), or a bundle family manager identifier (SPB Family Custodian Object ID). You may have it.
  • SPB ID bundle identifier
  • SPB Family ID bundle family identifier
  • SPB Family Custodian Object ID bundle family manager identifier
  • the first terminal 700 may be associated with a corresponding bundle and hold a'bundle movement setting'.
  • the bundle movement setting may selectively include information related to whether a corresponding bundle can be transmitted between devices.
  • the bundle movement setting may selectively further include information on whether a corresponding bundle can be used repeatedly in a plurality of terminals. For example, if the bundle is'forbidden to be used simultaneously in multiple terminals', that is,'the bundle should be used only in one terminal at a certain point in time', information about this may be included. have.
  • information of a bundle to be transmitted between devices may be transmitted to the first LBA 720 in step 7000.
  • This delivery process may be performed, for example, through a process in which a user directly selects a bundle through a UI provided by the first terminal 700, as shown in FIG. 7, or through a push input from a remote server. It may be input to 720, or the first LBA 720 may access the remote server and read the corresponding information.
  • information related to a bundle selected through steps 7005 to 7000 may be transferred from the first LBA 720 to the first SSP 710.
  • information related to the selected bundle may be transmitted from the first LBA 720 to the first SSP 710 through the Select SPB command.
  • the information transmitted from the first LBA 720 to the first SSP 710 may include information for identifying the bundle selected in step 7000.
  • the first SSP 710 may check whether a bundle requested to be transmitted can be transmitted between devices. This process may be performed by first identifying a bundle requested to be transmitted based on the information received in step 7005, and confirming a'bundle movement setting' associated with the bundle. In this process, when the'bundle movement setting' includes'information on whether a corresponding bundle can be used repeatedly in a plurality of terminals', the first SSP 710 may confirm this fact.
  • the first SSP 710 may selectively set a'bundle movement code'.
  • The'bundle movement code' is a code used to refer to the corresponding bundle in the process of transmitting the bundle between devices and must be a value that can identify the corresponding bundle.
  • the first SSP 710 may bind the'bundle movement code' described above with information of a bundle to be transmitted.
  • a response result for step 7005 in step 7015 may be transmitted from the first SSP 710 to the first LBA 720.
  • a response to the Select SPB command may be transmitted from the first SPB 710 to the first LBA 720 through the Select SPB response.
  • This response value may include the'bundle movement code' described in step 7010.
  • information necessary for inter-device bundle transmission in step 7020 may be transferred from the first LBA 720 of the first terminal 700 to the second LBA 770 of the second terminal 750.
  • information transmitted from the first LBA 720 to the second LBA 770 may include a'bundle movement code'.
  • the information transmitted from the first LBA 820 to the second LBA 870 includes information necessary for connection to be established between the first LBA 720 and the second LBA 770 in the next step 7025. Optionally, it may further include.
  • the information transmitted from the first LBA 720 to the second LBA 770 may optionally further include information indicating that the inter-device bundle movement is to be performed.
  • Information transferred from the first LBA 720 to the second LBA 770 through the above-described step 7020 may be transferred in various ways.
  • the first LBA 720 may provide information to be transmitted to the second LBA 770 to the user through the UI of the first terminal 700, and the user provides the received information to the second terminal ( 750) can be entered into the second LBA 770.
  • the first LBA 720 creates information to be transmitted to the second LBA 770 in the form of an image (for example, a QR code) and displays it on the screen of the first terminal 700, and the user By scanning this image using 750, information can be passed to the second LBA 770.
  • a method of transferring information from the first LBA 720 to the second LBA 770 is not limited to the above methods.
  • a connection may be established (or established) between the first LBA 720 and the second LBA 770 in step 7025. If information necessary for connection is transmitted in step 7020, the first LBA 720 and the second LBA 770 may establish a connection using this information.
  • the connection between the first LBA 820 and the second LBA 870 may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), 5G D2D) or It may be a remote connection in which a remote server (eg, a relay server) is located between the first LBA 720 and the second LBA 770.
  • a remote server eg, a relay server
  • step 7025 is shown as a final step, but this step is independent of the other steps described above, i.e., steps 7000, 7005, 7010, 7015, and 7020. Can be done without For example, step 7025 may be performed between steps 7015 and 7020. In this case, information transmitted from the first LBA 720 to the second LBA 2 770 in step 7020 is through the connection established in step 7025. It can also be transmitted.
  • FIG. 8 is a diagram illustrating a detailed procedure for a procedure in which a bundle is transmitted among the procedures presented in FIG. 6.
  • FIG. 8 is a diagram illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure.
  • the procedure of FIG. 8 may be referred to as a bundle transmission procedure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 800 includes a first LBA 820 and a first SSP 810
  • the second terminal 850 includes a second LBA 870 and It may include a second SSP (860).
  • the first terminal 800 may be a terminal equipped with a first SSP 810 and a first LBA 820 for controlling the first SSP 810
  • the second terminal 850 2 It may be a terminal in which the SSP 860 is mounted and the second LBA 870 for controlling the second SSP 860 is installed.
  • the second LBA 870 may request “SSP information (SspInfo)” from the second SSP 2 860.
  • SSP information SspInfo
  • the second LBA 870 indicates that the bundle movement between devices will be performed to the second SSP 860. I can tell you.
  • step 8000 may be automatically performed immediately following the process illustrated in FIG. 8, or may be performed after receiving an external input.
  • the'external input' may be performed through a process of selecting a bundle to be directly transmitted by the user through a UI provided by the second terminal 850, or the second LBA 870 through a push input from a remote server.
  • the second LBA 870 may access the remote server to read the corresponding information.
  • the second SSP 860 may generate its own “SSP information”.
  • the "SSP information” may include information on the second SSP to be provided for bundle transmission.
  • the "SSP information” may include information (certificate negotiation information) for a certificate negotiation process that the second SSP 860 must go through before receiving the bundle.
  • This "certificate negotiation information” may include certificate information (SenderSpblVerification) that the second SSP 860 can use to verify another SSP and certificate information (ReceiverSpblVerification) that can be used by another SSP to verify itself. have.
  • the "certificate negotiation information" may optionally further include a list of key agreement algorithms supported by the second SSP 860, and may optionally further include a list of encryption algorithms supported by the second SSP 860.
  • the "SSP information” may optionally further include SSP version information including at least one of version information of a standard standard supported by a primary platform and a loader included in the second SSP 960.
  • the second SSP 860 may transmit the "SSP information" generated in step 8005 to the first SSP 810 through the second LBA 870 and the first LBA 820. have.
  • the second LBA 870 requests "SSP information (SspInfo)" from the second SSP 860, and the second SSP 860 generates its own “SSP information”.
  • the second SSP 860 may transmit “SSP information” to the first SSP 810 through the second LBA 870 and the first LBA 820.
  • the process of transmitting "SSP information" from the second terminal 850 to the first terminal 800 may be as follows. For example, after the second LBA 870 generates “SSP information” by itself, the “SSP information” may be transmitted to the first SSP 810 through the first LBA 820.
  • the first SSP 810 checks the received “SSP information” and generates “first terminal authentication information (Device1.Auth)” capable of authenticating itself based on this information. can do.
  • first terminal authentication information (Device1.Auth)
  • the first SSP 810 may check certificate information capable of verifying itself using the received "SenderSpblVerification” and select at least one key agreement certificate (ssp1.Cert.KA).
  • the first SSP 810 uses the received "list of key agreement algorithms supported by the second SSP 860" to be used for key agreement, the asymmetric encryption key pair public key "ssp1.ePK.KA” After creating “and the private key "ssp1.eSK.KA", you can select the public key (ssp1.ePK.KA) from this key pair.
  • the first SSP 810 may check certificate information capable of verifying itself using the received "SenderSpblVerification” and further select at least one signing certificate (ssp1.Cert.DS).
  • the first SSP 810 may select at least one certificate information of the second SSP 860 to be verified using the received "ReceiverSpblVerification” and then set the corresponding information to "CiPkIdToBeUsed”.
  • the first SSP 810 may select at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 860" and then set corresponding information to "CryptoToBeUsed”. .
  • the first SSP 810 checks the list of the received "version information of the primary platform included in the second SSP 860 and the standard standard supported by the loader", and among them, the version of the standard standard that it also supports. You can check if it exists.
  • the “first terminal authentication information (Device1.Auth)” may include at least one of “ssp1.Cert.KA”, “ssp1.ePK.KA” “CiPkIdToBeUsed”, and “CryptoToBeUsed” described above.
  • the “first terminal authentication information (Device1.Auth)” may optionally further include “ssp1.Cert.DS” described above.
  • the “first terminal authentication information (Device1.Auth)” may optionally further include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future. I can.
  • first terminal authentication information (Device1.Auth)" mentioned above may be digitally signed so that it can be verified using ssp1.Cert.DS to ensure the integrity of the information, and this digital signature Data may be added as part of the "first terminal authentication information".
  • the first SSP 810 transmits the “first terminal authentication information (Device1.Auth)” generated in step 8015 to the second LBA 870 through the first LBA 820. I can.
  • the second LBA 870 may transmit “first terminal authentication information (Device1.Auth)” to the second SSP 860.
  • the second LBA 870 may further transmit a "bundle movement code” to the second SSP 860.
  • the second SSP 860 may verify the received “first terminal authentication information (Device1.Auth)”. If the second SSP 860 receives "ssp1.Cert.KA”, it may check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 860 receives "ssp1.ePK.KA” and a digital signature for it, it first checks the validity of ssp1.Cert.DS and then checks the digital signature using this certificate. You can check the integrity of the public key ssp1.ePK.KA. In addition, the second SSP 860 may select at least one signing certificate (ssp2.Cert.DS) capable of verifying itself by checking the received "CiPkIdToBeUsed”.
  • ssp2.Cert.DS at least one signing certificate
  • the second SSP 960 uses a public key "ssp2.ePK.KA” and a private key “ssp2.eSK.” as an asymmetric encryption key pair to be used for key agreement. After creating "KA”, you can select the public key (ssp2.ePK.KA) from this key pair. In addition, the second SSP 860 selects one of the public key for key agreement or ssp1.ePK.KA included in ssp1.Cert.KA, and then uses this value and ssp2.eSK.KA to communicate with the terminal 1 in the future. Session key ShKey01 to be used for encryption during communication can be generated. ShKey01 must be a session key for the encryption algorithm included in the received "CryptoToBeUsed”.
  • the second SSP 860 may generate “second terminal authentication information (Device2.Auth)” capable of authenticating itself.
  • the "second terminal authentication information (Device2.Auth)” may include “ssp2.Cert.DS”.
  • the “second terminal authentication information (Device2.Auth)” may further include “ssp2.ePK.KA”.
  • the “second terminal authentication information (Device2.Auth)” may further include a transaction ID indicating the current session generated by the SSP 2 860.
  • the “second terminal authentication information (Device2.Auth)” may further include a "bundle movement code”.
  • the "second terminal authentication information (Device2.Auth)" may further include an SSP identifier of the second SSP 960.
  • the "second terminal authentication information (Device2.Auth)” may optionally further include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future. I can.
  • Second terminal authentication information (Device2.Auth) may be digitally signed so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information, and this digital signature Data may be added as part of the "second terminal authentication information".
  • this digital signature Data may be added as part of the "second terminal authentication information”.
  • some or all of the "second terminal authentication information (Device2.Auth)" may be encrypted using the previously generated session key ShKey01.
  • step 8035 the second SSP 860 passes through the second LBA 870 and the first LBA 820 to the first SSP 810 generated in step 8030.
  • Device2.Auth can be delivered.
  • a “bundle movement code” may be selectively further transmitted.
  • the first SSP 810 may verify the received “second terminal authentication information (Device2.Auth)”.
  • the first SSP 810 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp2.Cert.DS”.
  • the first SSP 810 checks whether the received bundle family identifier (SPB Family ID) and/or the bundle family manager identifier (SPB Family Custodian Object ID) is a value set correctly in association with the bundle to be transmitted. I can.
  • the first SSP 810 may store the received transaction ID and/or the SSP identifier of the second SSP 860.
  • the first SSP 810 may bind the received transaction ID or the SSP identifier of the second SSP 960 with a currently ongoing session or a bundle to be transmitted.
  • the first SSP 810 is sent to the received ssp2.ePK.KA and its own ssp1.Cert.KA.
  • a session key ShKey01 can be generated using a private key corresponding to the included public key for key agreement or ssp1.eSK.KA, and the encrypted data can be decrypted using this session key, and then the verification process can be performed.
  • the first SSP 810 uses the "ssp2.Cert.DS" to determine the validity of the digital signature received. Can be verified.
  • the first SSP 810 includes an asymmetric encryption key pair public key "ssp1.bundle.ePK.KA” and a private key “ssp1. bundle.eSK.KA” can be created.
  • the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA” may be set to the same value as the previously created "ssp1.ePK.KA and ssp1.eSK.KA”.
  • the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA” will be set to the same value as the public key included in the previously used "ssp1.Cert.KA and the corresponding private key”. May be.
  • the first SSP 810 may generate the session key ShKey02 using ssp1.bundle.eSK.KA and ssp2.ePK.KA. If ssp1.eSK.KA or the private key corresponding to the public key included in ssp1.Cert.Ka is reused for ssp1.bundle.eSK.KA, the value of the session key ShKey02 is also of the previously generated ShKey01. Can be set to a value.
  • the first SSP 810 may configure a bundle to be transmitted to the second terminal 850 and/or metadata associated with the bundle.
  • the first SSP 810 may identify a bundle to be transmitted by using the received "bundle movement code".
  • "ssp1.Cert.DS” may be included in the bundle to be configured.
  • the bundle to be configured may further include "ssp1.bundle.ePK.KA”.
  • the bundle to be configured may further include a transaction ID identifying a corresponding session.
  • the bundle to be configured may optionally further include at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID) associated with the to-be-transmitted bundle.
  • SPB ID bundle identifier
  • SPB Family ID bundle family identifier
  • SPB Family Custodian Object ID bundle family manager identifier
  • a "bundle movement setting" may be included in the bundle (or metadata associated with the bundle) configured in step 8040.
  • digital signature data generated using ssp1.Cert.DS may be added to a bundle to be configured in step 8040. That is, digital signature data generated for some or all of the components of the bundle specified above may be added as a part of the bundle.
  • some or all of the bundles to be configured may be encrypted using ShKey02.
  • a first SSP 810 may deliver a bundle generated (configured) in step 8040 to a second LBA 870 through a first LBA 820.
  • metadata associated with the transmitted bundle may be selectively further transmitted.
  • a "bundle movement setting" associated with the transmitted bundle may be further transmitted.
  • the “bundle movement setting” may not be included in the bundle or metadata, but may be transmitted in a separate format (eg, a message).
  • FIG. 9 is a diagram illustrating a detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 9 is a possible example of a diagram illustrating a process in which a bundle is installed in a terminal and a process in which a bundle state is set after a bundle is transmitted according to an embodiment of the present disclosure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 900 includes a first LBA 920 and a first SSP 910
  • the second terminal 950 includes a second LBA 970 and It may include a second SSP (960).
  • the first terminal 900 may be a terminal equipped with a first SSP 910 and a first LBA 920 for controlling the first SSP 910
  • the second terminal 950 2 It may be a terminal in which the SSP 960 is mounted and the second LBA 970 for controlling the second SSP 960 is installed.
  • the second LBA 970 and the second SSP 960 may cooperate with each other to install a bundle in the second terminal 950.
  • the following procedures can be performed together. If metadata is transmitted, the second LBA 970 or the second SSP 960 may verify the content included in the metadata. If "bundle movement setup" has been transmitted, the second LBA 970 may transmit this information to the second SSP 960. If a transaction ID has been transmitted, the second LBA 970 or the second SSP 960 may check whether the transaction ID is the same as the transaction ID used in the current session.
  • the second LBA 970 or the second SSP 960 is It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS has been transmitted, the second SSP 960 may authenticate the first SSP 910 by verifying the validity of this certificate. If the transmitted data contains encrypted data, the second SSP 960 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, verification can be performed. If the received data includes a digital signature, the second SSP 960 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.
  • the second LBA 970 and/or the second SSP 960 may selectively determine whether a corresponding bundle can be used repeatedly in a plurality of terminals. Some possible ways to make this judgment are: As one possible example, if the bundle movement configuration includes whether the corresponding bundle can be used repeatedly in a plurality of terminals, the second LBA 970 and/or the second SSP 960 determine this information by checking this information. You can get it down. As another possible example, the second LBA 970 and/or the second SSP 960 uses the received bundle family identifier (SPB Family ID) and/or the bundle family manager identifier (SPB Family Custodian Object ID) to have multiple bundles. It is also possible to check whether it is possible to redundantly use the terminal of As part of step 9000, this process may be performed in any order and procedures performed in step 9000, or may be performed after step 9000.
  • SPB Family ID received bundle family identifier
  • SPB Family Custodian Object ID bundle family manager identifier
  • the bundle is determined to be a bundle that can be used repeatedly in a plurality of terminals, a process of additionally setting the bundle state may not be necessary.
  • a process of additionally setting the bundle state may not be necessary.
  • the second LBA 970 and/or the second SSP 960 does not determine whether the corresponding bundle is used repeatedly, according to the implementation of the second LBA 970 and/or the second SSP 960
  • the process of additionally configuring the bundle state may not be necessary.
  • FIG. 10 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 10 is another example of a diagram illustrating a process of installing a bundle in a terminal and a process of setting a bundle state after a bundle is transmitted according to an embodiment of the present disclosure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 1000 includes a first LBA 1020 and a first SSP 1010
  • the second terminal 1050 includes a second LBA 1070 and It may include a second SSP (1060).
  • the first terminal 1000 may be a terminal equipped with a first SSP 1010 and a first LBA 1020 for controlling the first SSP 1010
  • the second terminal 1050 2 It may be a terminal in which the SSP 1060 is mounted and the second LBA 1070 for controlling the second SSP 1060 is installed.
  • step 10000 the second LBA 1070 and the second SSP 1060 may cooperate with each other to install a bundle in the second terminal 1050.
  • the second LBA 1070 and/or the second SSP 1060 may selectively determine whether the corresponding bundle can be used repeatedly in a plurality of terminals. Refer to the procedure "Checking whether duplicates can be used" in 9.
  • the bundle state is additionally set as follows.
  • the process of additionally setting the bundle state may be performed as follows.
  • the second SSP 1060 may set the state of a corresponding bundle to “IN TRANSITION”.
  • IN TRANSITION is a state in which the bundle has been successfully installed but is not yet usable (also,'a request from another terminal (for example, a request made by sending a'finalizationResponse or recoveryRequest)')' and/or'(explained in this disclosure) It means a state that can be changed to an available state (Disabled, Enable, Active state) only by an additional operation such as'Request from an external server'.
  • the second LBA 1070 may request a “certificate” from the second SSP 1060.
  • the second SSP 1060 may generate a “certificate”.
  • this certificate may be called finalizationRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the finalizationRequest may include the "bundle identifier" of the corresponding bundle in 510.
  • the finalizationRequest may include the "SSP identifier" of the second SSP in 540.
  • the finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 550.
  • the finalizationRequest may optionally include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created.
  • the finalizationRequest may include signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 1060 may transmit a finalization Request to the first SSP 1010.
  • the second SSP 1060 may transmit a finalizationRequest to the first SSP 1010 through the following process. That is, the second SSP 1060 may transmit a finalizationRequest to the second LBA 1070 in a response of step 10010, and the second LBA may transmit a finalizationRequest to the first SSP through the first LBA 1020.
  • the first SSP 1010 may verify the received finalizationRequest.
  • This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest.
  • the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP.
  • the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.
  • the first SSP 1010 may delete the bundle after completing the verification.
  • the first SSP 1010 may generate a "certificate".
  • this certificate may be called finalizationResponse.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the finalizationResponse may include the "bundle identifier" of the corresponding bundle in 510.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 540.
  • the finalizationResponse may include information indicating that the first SSP has deleted the bundle in 550.
  • the finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 520.
  • the finalizationResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • the finalizationResponse may include the finalizationRequest received at 530.
  • some information of the received finalizationRequest may be omitted if necessary.
  • signature information of the second SSP included in the finalizationRequest may be omitted in some cases.
  • time information included in the finalizationRequest may be omitted in some cases.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 540.
  • the finalizationResponse may include information indicating that the first SSP has deleted the bundle in 550.
  • the finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 520.
  • the finalizationResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • a first SSP 1010 may transmit a finalizationResponse to a second SSP 1060.
  • the first SSP 1010 may transmit a finalizationResponse to the second SSP 1060 through the first LBA 1020 and the second LBA 1070.
  • the second SSP 1060 may verify the received finalizationResponse.
  • This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse.
  • the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle.
  • the verification process may optionally further include a process of checking whether the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse.
  • the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse.
  • the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.
  • the second SSP 1060 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification.
  • the second SSP 1060 may convert the state of the bundle to the Disabled state.
  • a second SSP 1060 may transmit a result (eg, success or failure) of a task performed in step 10035 to a second LBA 1070.
  • FIG. 11 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 11 is another example of a diagram illustrating a process of installing a bundle in a terminal and a process of setting a bundle state after a bundle is transmitted according to an embodiment of the present disclosure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 1100 includes a first LBA 1120 and a first SSP 1110
  • the second terminal 1150 includes a second LBA 1170 and A second SSP 1160 may be included.
  • the first terminal 1100 may be a terminal equipped with a first SSP 1110 and a first LBA 1120 for controlling the first SSP 1110
  • the second terminal 1150 2 It may be a terminal in which the SSP 1160 is mounted and the second LBA 1170 for controlling the second SSP 1160 is installed.
  • step 11000 the second LBA 1170 and the second SSP 1160 may cooperate with each other to install a bundle in the second terminal 1150.
  • the second LBA 1170 and/or the second SSP 1160 may selectively determine whether the corresponding bundle can be used repeatedly in a plurality of terminals. Refer to the procedure "Checking whether duplicates can be used" in 9.
  • the bundle state is additionally set as follows.
  • the process of additionally setting the bundle state may be performed as follows.
  • the second SSP 1160 may set the state of a corresponding bundle to “IN TRANSITION”.
  • the "IN TRANSITION” state refer to the description of step 10005.
  • the second LBA 1170 may request a “certificate” from the second SSP 1160.
  • the second SSP 1160 may generate a “certificate”.
  • this certificate may be called finalizationRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the finalizationRequest may include the "bundle identifier" of the corresponding bundle in 510.
  • the finalizationRequest may include the "SSP identifier" of the second SSP in 540.
  • the finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 550.
  • the finalizationRequest may optionally include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created.
  • the finalizationRequest may include signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 1160 may transmit a finalization Request to the first SSP 1110.
  • the second SSP 1160 may transmit a finalizationRequest to the first SSP 1110 through the following process. That is, the second SSP 1160 may transmit the finalizationRequest to the second LBA 1170 in response to step 11010, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1120.
  • the first SSP 1110 may verify the received finalizationRequest.
  • This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest.
  • the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP.
  • the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.
  • the first SSP 1110 may set the state of the bundle to the "IN TRANSITION" state after completing the verification.
  • the first SSP 1110 may generate a "certificate".
  • this certificate may be called finalizationResponse.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the finalizationResponse may include the "bundle identifier" of the corresponding bundle in 510.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 540.
  • the finalizationResponse may include information indicating that the first SSP changed the state of the bundle to the "IN TRANSITION" state in 550.
  • the finalizationResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.
  • the finalizationResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • the finalizationResponse may include the finalizationRequest received at 530.
  • some information of the received finalizationRequest may be omitted if necessary.
  • signature information of the second SSP included in the finalizationRequest may be omitted in some cases.
  • time information included in the finalizationRequest may be omitted in some cases.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 540.
  • the finalizationResponse may include information indicating that the first SSP changed the state of the bundle to the "IN TRANSITION" state in 550.
  • the finalizationResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.
  • the finalizationResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • a first SSP 1110 may transmit a finalizationResponse to a second SSP 1160.
  • the first SSP 1110 may transmit a finalizationResponse to the second SSP 1160 through the first LBA 1120 and the second LBA 1170.
  • the second SSP 1160 may verify the received finalizationResponse.
  • This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse.
  • the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle.
  • the verification process may optionally further include a process of checking whether the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse.
  • the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse.
  • the verification process may further include a process of checking whether command information included in the finalizationResponse is correct.
  • the second SSP 1160 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification.
  • the second SSP 1160 may convert the state of the bundle to the Disabled state.
  • the second SSP 1160 may generate a "certificate".
  • this certificate may be referred to as spblAttestation.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • -spblAttestation may include the "bundle separator" of the corresponding bundle in 510.
  • -spblAttestation may include the "SSP identifier" of the second SSP in 540.
  • -spblAttestation may include information indicating that the second SSP has changed the state of the bundle to a usable state in 550.
  • -spblAttestation may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.
  • -spblAttestation may include the signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • -spblAttestation may include finalizationResponse received at 530.
  • some information of the received finalizationResponse may be omitted if necessary.
  • some of the signature information included in the finalizationResponse may be omitted in some cases.
  • some of the time information included in the finalizationResponse may be omitted in some cases.
  • -spblAttestation may include the "SSP identifier" of the second SSP in 540.
  • -spblAttestation may include information indicating that the second SSP has changed the state of the bundle to a usable state in 550.
  • -spblAttestation may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.
  • -spblAttestation may include the signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 1160 may transmit spblAttestation to the first SSP 1110.
  • the second SSP 1160 may transmit spblAttestation to the first SSP through the second LBA 1170 and the first LBA 1120.
  • the first SSP 1110 may verify the received spblAttestation.
  • This verification process may include checking the validity of the signature of the second SSP included in the spblAttestation.
  • the verification process may further include a process of checking whether the "bundle separator" included in spblAttestation matches the bundle identifier of the corresponding bundle.
  • the verification process may optionally further include a process of checking whether the finalizationResponse included in the spblAttestation matches the information transmitted by the spblAttestation.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the spblAttestation is a correct identifier of the second SSP.
  • the verification process may further include a process of confirming whether command information included in spblAttestation changes the state of the bundle to a usable state.
  • the first SSP 1110 may delete the bundle after completing the verification.
  • FIG. 12 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 12 is another example of a diagram illustrating a process in which a bundle is installed in a terminal and a process in which a bundle state is set after a bundle is transmitted according to an embodiment of the present disclosure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 1200 includes a first LBA 1220 and a first SSP 1210
  • the second terminal 1250 includes a second LBA 1270 and A second SSP 1260 may be included.
  • the first terminal 1200 may be a terminal equipped with a first SSP 1210 and a first LBA 1220 for controlling the first SSP 1210
  • the second terminal 1250 2 It may be a terminal in which the SSP 1260 is mounted and the second LBA 1270 for controlling the second SSP 1260 is installed.
  • step 12000 the second LBA 1270 and the second SSP 1260 may cooperate with each other to install a bundle in the second terminal 1250.
  • the second LBA 1270 and/or the second SSP 1260 can selectively determine whether the corresponding bundle can be used repeatedly in a plurality of terminals. Refer to the procedure "Checking whether duplicates can be used" in 9.
  • the bundle state is additionally set as follows.
  • the process of additionally setting the bundle state may be performed as follows.
  • the second SSP 1260 may set the state of a corresponding bundle to “IN TRANSITION”.
  • the "IN TRANSITION” state refer to the description of step 10005.
  • the second LBA 1270 may request a “certificate” from the second SSP 1260.
  • the second SSP 1260 may generate a “certificate”.
  • this certificate may be called finalizationRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the finalizationRequest may include the "bundle identifier" of the corresponding bundle in 510.
  • the finalizationRequest may include the "SSP identifier" of the second SSP in 540.
  • the finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 550.
  • the finalizationRequest may optionally include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created.
  • the finalizationRequest may include signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 1260 may transmit a finalization Request to the first SSP 1210.
  • the second SSP 1260 may transmit a finalizationRequest to the first SSP 1210 through the following process. That is, the second SSP 1260 may transmit the finalizationRequest to the second LBA 1270 in response to step 12010, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1220.
  • the first SSP 1210 may verify the received finalizationRequest.
  • This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest.
  • the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP.
  • the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.
  • the first SSP 1210 may set the state of the bundle to the "SUSPENSION” state after completing the verification.
  • "SUSPENSION” is in a state in which the bundle cannot be used (also, a request from another terminal (for example, a request made by sending a recoveryRequest)) and/or a request from an external server (though not described in this disclosure). It means a state that can be changed to an available state (Disabled, Enable, Active state). Further, although not shown in the drawing, the "SUSPENSION” state described above may be replaced with the "IN TRANSITION" state.
  • the first SSP 1210 may generate a "certificate".
  • this certificate may be called finalizationResponse.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the finalizationResponse may include the "bundle identifier" of the corresponding bundle in 510.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 540.
  • the finalizationResponse may include information indicating that the first SSP changed the state of the bundle to the state of "SUSPENSION" (or IN TRANSITION) in 550.
  • the finalizationResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.
  • the finalizationResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • the finalizationResponse may include the finalizationRequest received at 530.
  • some information of the received finalizationRequest may be omitted if necessary.
  • signature information of the second SSP included in the finalizationRequest may be omitted in some cases.
  • time information included in the finalizationRequest may be omitted in some cases.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 540.
  • the finalizationResponse may include information indicating that the first SSP changed the state of the bundle to the state of "SUSPENSION" (or IN TRANSITION) in 550.
  • the finalizationResponse may optionally include, in 520, a time when the first SSP changes the state of the bundle or a time when a certificate is created.
  • the finalizationResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • a first SSP 1210 may transmit a finalizationResponse to a second SSP 1260.
  • the first SSP 1210 may transmit a finalizationResponse to the second SSP 1260 through the first LBA 1220 and the second LBA 1270.
  • the second SSP 1260 may verify the received finalizationResponse.
  • This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse.
  • the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle.
  • the verification process may optionally further include a process of checking whether the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse.
  • the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse.
  • the verification process may further include a process of checking whether command information included in the finalizationResponse is correct.
  • the second SSP 1260 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification. For example, as shown in the drawing, the second SSP 1260 may convert the state of the bundle to the Disabled state.
  • the second SSP 1260 may transmit a result (eg, success or failure) of the task performed in step 12035 to the second LBA 1270.
  • a result eg, success or failure
  • FIG. 13 is a diagram illustrating an example of a procedure for making a bundle that has been discontinued to be used again.
  • it is an example of a diagram showing a procedure for setting a bundle in an "IN TRANSITION” state or a "SUSPENSION” state to a usable state again.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 1300 includes a first LBA 1320 and a first SSP 1310
  • the second terminal 1350 includes a second LBA 1370 and A second SSP 1360 may be included.
  • the first terminal 1300 may be a terminal equipped with a first SSP 1310 and a first LBA 1320 for controlling the first SSP 1310
  • the second terminal 1350 2 It may be a terminal in which the SSP 1360 is mounted and the second LBA 1370 for controlling the second SSP 1360 is installed.
  • a possible example when the state of the bundle is set to the "IN TRANSITION” state or the "SUSPENSION” state before the procedure disclosed in FIG. 13 is performed is as follows. For example, in the step in which the transmission of the bundle disclosed in FIG. 11 is finished, if step 11025 is performed but step 11045 is not performed, the state of the bundle in the first terminal 1300 is set to the "IN TRANSITION” state. There will be. As another example, if step 12025 is performed in the step in which the transmission of the bundle disclosed in FIG. 12 is completed, the state of the bundle in the first terminal 1300 will be set to the "IN TRANSITION" state or the "SUSPENSION” state. .
  • step 13000 information on a bundle for requesting to resume use may be transmitted to the second LBA 1370.
  • This delivery process may be performed through a process in which the user directly selects a bundle through a UI provided by the second terminal 1350, or may be input to the second LBA 1370 through a push input from a remote server, or The second LBA 1370 may access the remote server and read the corresponding information.
  • information of a bundle selected in step 13000 in step 13005 may be transmitted from the second LBA 1370 to the second SSP 1360.
  • the information transmitted from the second LBA 1370 to the second SSP 1360 may include information for identifying the bundle selected in step 13000.
  • the second SSP 1360 may delete the corresponding bundle. Also, the second SSP 1360 may generate a "certificate". In Figure 13, this certificate may be called recoveryRequest. The structure of this certificate may follow the structure disclosed in FIG. 5.
  • the recoveryRequest may include the "bundle identifier" of the corresponding bundle in 510.
  • the recoveryRequest may include the "SSP identifier" of the second SSP in 540.
  • the recoveryRequest may include information indicating that the second SSP has deleted the bundle in 550.
  • the recoveryRequest may optionally include a time when the second SSP deletes the bundle or creates a certificate in 520.
  • the recoveryRequest may include the signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 1360 may transmit a recovery Request to the first SSP 1310.
  • the second SSP 1360 may transmit a recovery Request to the first SSP 1310 through the following process. That is, the second SSP 1360 transmits a recovery Request to the second LBA 1370 in response to step 13005, and the second LBA 1370 sends a recovery request to the first SSP 1310 through the first LBA 1320. I can deliver.
  • the first SSP 1310 may verify the received recovery Request.
  • This verification process may include checking the validity of the signature of the second SSP 1360 included in the recoveryRequest.
  • this verification process may further include a process of checking the "bundle identifier" included in the recoveryRequest.
  • the verification process may further include a process of checking the "SSP identifier" included in the recoveryRequest.
  • the verification process may further include a process of confirming whether the command information included in the recoveryRequest deletes the bundle.
  • the first SSP 1310 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the first SSP 1310 may convert the state of the bundle to the Disabled state.
  • the first SSP 1310 may transmit a result (eg, success or failure) of the task performed in step 13020 to the first LBA 1320.
  • a result eg, success or failure
  • FIG. 14 is a diagram illustrating another example of a procedure for making a bundle that has been discontinued to be used again.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 1400 includes a first LBA 1420 and a first SSP 1410
  • the second terminal 1450 includes a second LBA 1470 and A second SSP 1460 may be included.
  • the first terminal 1400 may be a terminal equipped with a first SSP 1410 and a first LBA 1420 for controlling the first SSP 1410
  • the second terminal 1450 2 It may be a terminal in which the SSP 1460 is mounted and the second LBA 1470 for controlling the second SSP 1460 is installed.
  • a possible example when the state of the bundle is set to the "IN TRANSITION” state or the "SUSPENSION” state before the procedure disclosed in FIG. 14 is performed is as follows. For example, in the step in which the transmission of the bundle disclosed in FIG. 11 is finished, if step 11025 is performed but step 11045 is not performed, the state of the bundle in the first terminal 1400 is set to the "IN TRANSITION” state. There will be. As another example, if step 12025 is performed in the step in which the transmission of the bundle disclosed in FIG. 12 is completed, the state of the bundle in the first terminal 1400 will be set to the "IN TRANSITION" state or the "SUSPENSION” state. .
  • information on a bundle for requesting to resume use may be transmitted to the second LBA 1470 in step 14000.
  • This delivery process may be performed through a process in which the user directly selects a bundle through a UI provided by the second terminal 1450, or may be input to the second LBA 1470 through a push input from a remote server, or The second LBA 1470 may access the remote server and read the corresponding information.
  • information of a bundle selected in step 14000 in step 14005 may be transmitted from the second LBA 1470 to the second SSP 1460.
  • the information transmitted from the second LBA 1470 to the second SSP 1460 may include information for identifying the bundle selected in step 14000.
  • the second SSP 1460 may set the state of a corresponding bundle to an “IN TRANSITION” state.
  • the second SSP 1460 may generate a "certificate" related to a state change of a corresponding bundle.
  • this certificate may be called recoveryRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the recoveryRequest may include the "bundle identifier" of the corresponding bundle in 510.
  • the recoveryRequest may include the "SSP identifier" of the second SSP in 540.
  • the recoveryRequest may include information indicating that the second SSP has set the bundle state to the "IN TRANSITION" state in 550.
  • the recoveryRequest may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.
  • the recoveryRequest may include the signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 1460 may transmit a recovery Request to the first SSP 1410.
  • the second SSP 1460 may transmit a recovery Request to the first SSP 1410 through the following process. That is, the second SSP 1460 transmits the recovery Request to the second LBA 1470 in response to step 14005, and the second LBA 1470 sends a recovery request to the first SSP 1410 through the first LBA 1420. I can deliver.
  • the first SSP 1410 may verify the received recovery Request.
  • This verification process may include checking the validity of the signature of the second SSP 1460 included in the recoveryRequest.
  • this verification process may further include a process of checking the "bundle identifier" included in the recoveryRequest.
  • this verification process may further include a process of verifying the "SSP identifier" included in the recoveryRequest.
  • the verification process may further include a process of confirming whether command information included in the recoveryRequest changes the state of the bundle to the "IN TRANSITION" state.
  • the first SSP 1410 may change the state of the bundle to one of available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the first SSP 1410 may convert the state of the bundle to the Disabled state.
  • the first SSP 1410 may generate a "certificate".
  • this certificate may be called recoveryResponse.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the recoveryResponse may include the "bundle identifier" of the corresponding bundle in 510.
  • the recoveryResponse may include the "SSP identifier" of the first SSP in 540.
  • the recoveryResponse may include information indicating that the first SSP has changed the state of the bundle to a usable state in 550.
  • the recoveryResponse may optionally include a time when the first SSP changes the state of the bundle or a time when a certificate is created in 520.
  • -RecoveryResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • the recoveryResponse may include the recoveryRequest received at 530.
  • some information of the received recoveryRequest may be omitted if necessary.
  • the signature information of the second SSP included in the recoveryRequest may be omitted in some cases.
  • time information included in the recoveryRequest may be omitted in some cases.
  • the recoveryResponse may include the "SSP identifier" of the first SSP in 540.
  • the recoveryResponse may include information indicating that the first SSP has changed the state of the bundle to a usable state in 550.
  • the recoveryResponse may optionally include a time when the first SSP changes the state of the bundle or a time when a certificate is created in 520.
  • -RecoveryResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • the first SSP 1410 may transmit a recoveryResponse to the second SSP 1460.
  • the first SSP 1410 may transmit a recoveryResponse to the second SSP 1460 through the first LBA 1420 and the second LBA 1470.
  • the second SSP 1460 may verify the received recoveryResponse.
  • This verification process may include checking the validity of the signature of the first SSP 1460 included in the recoveryResponse.
  • the verification process may optionally further include a process of checking whether the "bundle identifier" included in the recoveryResponse matches the bundle identifier of the corresponding bundle.
  • the verification process may optionally further include a process of checking whether the recoveryRequest included in the recoveryResponse matches the information transmitted by the user.
  • this verification process may further include a process of verifying the "SSP identifier" included in the recoveryResponse.
  • the verification process may further include a process of checking whether command information included in the recoveryResponse is correct command information.
  • the second SSP 1460 may delete the bundle after completing the verification.
  • the second SSP 1460 may transmit a result (eg, success or failure) of the task performed in step 14030 to the second LBA 1470.
  • a result eg, success or failure
  • 15 is a diagram illustrating another example of a procedure for making a bundle that has been discontinued to be used again.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 1500 includes a first LBA 1520 and a first SSP 1510
  • the second terminal 1550 is a second LBA 1570 and It may include a second SSP (1560).
  • the first terminal 1500 may be a terminal equipped with a first SSP 1510 and a first LBA 1520 for controlling the first SSP 1510
  • the second terminal 1550 2 It may be a terminal in which the SSP 1560 is mounted and the second LBA 1570 for controlling the second SSP 1560 is installed.
  • a possible example when the state of the bundle is set to the "IN TRANSITION” state or the "SUSPENSION” state before the procedure disclosed in FIG. 15 is performed is as follows. For example, in the step in which the transmission of the bundle disclosed in FIG. 11 is finished, if step 11025 is performed but step 11045 is not performed, the state of the bundle in the first terminal 1500 is set to the "IN TRANSITION” state. There will be. As another example, if step 12025 is performed in the step in which the transmission of the bundle disclosed in FIG. 12 is completed, the state of the bundle in the first terminal 1500 will be set to the "IN TRANSITION" state or the "SUSPENSION” state. .
  • step 15000 information on a bundle requesting resume of use may be delivered to a second LBA.
  • This delivery process may be performed through a process in which the user directly selects a bundle through a UI provided by the second terminal 1550, or may be input to the second LBA 1570 through a push input from a remote server, or The second LBA 1570 may access the remote server and read the corresponding information.
  • information of a bundle selected in step 15000 in step 15005 may be transmitted from the second LBA 1570 to the second SSP 1560.
  • the information transmitted from the second LBA 1570 to the second SSP 1560 may include information for identifying the bundle selected in step 15000.
  • the second SSP 1560 may change the state of the corresponding bundle to “SUSPENSION”.
  • the "SUSPENSION” state described above may be replaced with the "IN TRANSITION” state.
  • the second SSP 1560 may generate a "certificate".
  • this certificate may be called recoveryRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the recoveryRequest may include the "bundle identifier" of the corresponding bundle in 510.
  • the recoveryRequest may include the "SSP identifier" of the second SSP in 540.
  • the recoveryRequest may include information indicating that the second SSP has changed the state of the bundle to "SUSPENSION” or "IN TRANSITION” in 550.
  • the recoveryRequest may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.
  • the recoveryRequest may include the signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 1560 may transmit a recovery Request to the first SSP 1510.
  • the second SSP 1560 may transmit a recovery Request to the first SSP 1510 through the following process. That is, the second SSP 1560 transmits a recovery Request to the second LBA 1570 in response to step 15005, and the second LBA 1570 sends a recovery request to the first SSP 1510 through the first LBA 1520. I can deliver.
  • the first SSP 1510 may verify the received recovery Request.
  • This verification process may include checking the validity of the signature of the second SSP 1560 included in the recoveryRequest.
  • this verification process may further include a process of checking the "bundle identifier" included in the recoveryRequest.
  • this verification process may further include a process of verifying the "SSP identifier" included in the recoveryRequest.
  • the verification process may further include a process of checking whether command information included in the recoveryRequest correctly changes the state of the bundle.
  • the first SSP 1510 may change the state of the bundle to one of available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the first SSP 1510 may change the state of the bundle to the Disabled state.
  • a first SSP 1510 may transmit a result (eg, success or failure) of a task performed in step 15020 to a first LBA 1520.
  • 16 is a diagram illustrating a configuration of a terminal according to an embodiment of the present disclosure.
  • the terminal may include a transceiver 1610 and at least one processor 1620.
  • the terminal may further include an SSP 1630.
  • the SSP 1630 may be inserted into the terminal or may be embedded in the terminal.
  • the at least one processor 1620 may also be referred to as a “control unit”.
  • the configuration of the terminal is not limited to FIG. 16, and may include more or fewer components than the components illustrated in FIG. 16.
  • the transmission/reception unit 1610, at least one processor 1620, and a memory may be implemented in the form of one chip.
  • the SSP 1630 when the SSP 1630 is embedded, it may be implemented in the form of a single chip, including the SSP 1630.
  • the transmission/reception unit 1610 may transmit and receive signals, information, and data according to various embodiments of the present disclosure with a transmission/reception unit of another terminal or an external server.
  • the transceiver unit 1610 may include an RF transmitter that up converts and amplifies a frequency of a transmitted signal, and an RF receiver that amplifies a received signal with low noise and down converts the frequency.
  • this is only an embodiment of the transmission/reception unit 1610, and components of the transmission/reception unit 1610 are not limited to the RF transmitter and the RF receiver.
  • the transmission/reception unit 1610 may receive a signal through a wireless channel, output it to the at least one processor 1620, and transmit a signal output from the at least one processor 1620 through a wireless channel.
  • the transmission/reception unit 1610 includes information on the SSP included in the other terminal from the transmission/reception unit of another terminal or an external server, authentication information for authenticating other terminals, authentication information for authenticating itself, bundle It is possible to transmit or receive a movement code, a bundle movement setting, a bundle, and various certificates described in FIGS. 10 to 15.
  • At least one processor 1620 is a component for overall control of the terminal.
  • the at least one processor 1620 may control the overall operation of the terminal according to various embodiments of the present disclosure as described above.
  • the SSP 1630 may include a processor or controller for installing and controlling a bundle, or may have an application installed.
  • At least one processor or controller in the SSP 1630 may determine whether to transmit a specific bundle by checking the bundle movement setting. In addition, it is possible to check whether the bundle movement setting is checked and whether a corresponding bundle can be used repeatedly in a plurality of terminals.
  • At least one processor or controller in the SSP may generate a bundle movement code to control a transmission process of a specific bundle.
  • At least one processor or controller in the SSP may generate its own SSP information, and may check and verify SSP information of another SSP transmitted from the outside.
  • At least one processor or controller in the SSP may generate authentication information capable of verifying itself, and may verify authentication information of another SSP transmitted from the outside.
  • the SSP 1330 may generate a bundle, and may install the bundle alone or in cooperation with one or more processors 1620. Also, the SSP 1630 may manage a bundle.
  • the SSP 1630 may generate various types of certificates described in FIGS. 10 to 15 and verify the received certificates.
  • the SSP 1630 may change the state of the bundle based on the contents of the received certificate as described in FIGS. 10 to 15.
  • the SSP 1630 may operate under the control of the processor 1620.
  • the SSP 1630 may include a processor or controller for installing and controlling a bundle, or may have an application installed. Some or all of the applications may be installed in the SSP 1630 or a memory (not shown).
  • the terminal may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the terminal.
  • the memory is a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium.
  • the processor 1620 may perform various operations using various programs, contents, data, and the like stored in the memory.
  • FIG. 17 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 6.
  • FIG. 17 is another example of a diagram illustrating a process of installing a bundle in a terminal and a process of setting a bundle state after a bundle is transmitted according to an embodiment of the present disclosure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 1700 includes a first LBA 1720 and a first SSP 1710
  • the second terminal 1750 includes a second LBA 1770 and It may include a second SSP (1760).
  • the first terminal 1700 may be a terminal equipped with a first SSP 1710 and a first LBA 1720 for controlling the first SSP 1710
  • the second terminal 1750 2 It may be a terminal in which the SSP 1760 is mounted and the second LBA 1770 for controlling the second SSP 1760 is installed.
  • the second LBA 1770 and the second SSP 1760 may cooperate with each other to install a bundle in the second terminal 1750.
  • the second LBA 1770 and/or the second SSP 1760 may selectively determine whether the corresponding bundle can be used repeatedly in a plurality of terminals. Refer to the procedure "Checking whether duplicates can be used" in 9.
  • the bundle state is additionally set as follows.
  • the process of additionally setting the bundle state may be performed as follows.
  • the second SSP 1760 may set the state of a corresponding bundle to “IN TRANSITION”.
  • IN TRANSITION is a state in which the bundle has been successfully installed but cannot be used (also, such as'a request from another terminal (for example, a request made by sending a finalizationResponse or recoveryRequest)' and/or a'request from an external server'). It means a state that can be changed to an available state (Disabled, Enable, Active state) only by an additional operation.
  • the second LBA 1770 may request a “certificate” from the second SSP 1760.
  • the second SSP 1760 may generate a “certificate”.
  • this certificate may be called finalizationRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the finalizationRequest may include the "bundle identifier" of the corresponding bundle in 510.
  • the finalizationRequest may include the "SSP identifier" of the second SSP in 540.
  • the finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 550.
  • the finalizationRequest may optionally include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created.
  • information of a certificate to be used for later electronic signature may be optionally further included.
  • the finalizationRequest may include signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 1760 may transmit a finalization Request to the first SSP 1710.
  • the second SSP 1760 may transmit a finalizationRequest to the first SSP 1710 through the following process. That is, the second SSP 1760 may transmit the finalizationRequest to the second LBA 1770 in the response of step 17010, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 1720.
  • the first SSP 1710 may verify the received finalizationRequest.
  • This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest.
  • the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP.
  • the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.
  • the first SSP 1710 may delete the bundle.
  • the first SSP 1710 may generate a "certificate".
  • this certificate may be called finalizationResponse.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • the finalizationResponse may include the "bundle identifier" of the corresponding bundle in 510.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 540.
  • the finalizationResponse may include information indicating that the first SSP has deleted the bundle in 550.
  • the finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 520.
  • information of a certificate to be used for later electronic signature may be optionally further included.
  • the finalizationResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • the finalizationResponse may include some and/or all data of the finalizationRequest in 530.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 540.
  • the finalizationResponse may include information indicating that the first SSP has deleted the bundle in 550.
  • the finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 520.
  • information of a certificate to be used for later electronic signature may be optionally further included.
  • the finalizationResponse may include signature information of the first SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • a first SSP 1710 may transmit a finalizationResponse to a second SSP 1760.
  • the first SSP 1710 may transmit a finalizationResponse to the second SSP 1760 through the first LBA 1720 and the second LBA 1770.
  • the second SSP 1760 may verify the received finalizationResponse.
  • This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse.
  • the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle.
  • the verification process may optionally further include a process of checking whether some and/or all information of the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse.
  • the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse.
  • the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.
  • the second SSP 1760 may change the state of the bundle to one of available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the second SSP 1760 may convert the state of the bundle to the Disabled state.
  • the second SSP 1760 may generate a "certificate".
  • this certificate may be referred to as spblAttestation.
  • the structure of this certificate may follow the structure disclosed in FIG. 5.
  • -spblAttestation may include the "bundle separator" of the corresponding bundle in 510.
  • -spblAttestation may include the "SSP identifier" of the second SSP in 540.
  • -spblAttestation may include information indicating that the second SSP has changed the state of the bundle to a usable state in 550.
  • -spblAttestation may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.
  • information of a certificate to be used for later electronic signature may be optionally further included.
  • -spblAttestation may include the signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • -spblAttestation may include some and/or all data of'finalizationRequest and/or finalizationResponse' in 530.
  • -spblAttestation may include the "SSP identifier" of the second SSP in 540.
  • -spblAttestation may include information indicating that the second SSP has changed the state of the bundle to a usable state in 550.
  • -spblAttestation may optionally include, in 520, a time when the second SSP changes the state of the bundle or a time when a certificate is created.
  • information of a certificate to be used for later electronic signature may be optionally further included.
  • -spblAttestation may include the signature information of the second SSP in 560.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 1760 may transmit spblAttestation to the first SSP 1710.
  • the second SSP 1760 may transmit spblAttestation to the first SSP 1710 through the second LBA 1770 and the first LBA 1720.
  • the first SSP 1710 may verify the received spblAttestation.
  • This verification process may include checking the validity of the signature of the second SSP included in the spblAttestation.
  • the verification process may further include a process of checking whether the "bundle separator" included in spblAttestation matches the bundle identifier of the corresponding bundle.
  • the verification process may optionally further include a process of checking whether some and/or all information of the finalizationRequest and/or finalizationResponse included in the spblAttestation matches the information transmitted by the spblAttestation.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the spblAttestation is a correct identifier of the second SSP.
  • the verification process may further include a process of confirming whether command information included in spblAttestation changes the state of the bundle to a usable state.
  • the first SSP 1710 may delete the finalizationResponse.
  • step 17035 the step of generating spblAttestation and/or step 17040 and/or step 17045 may be omitted as necessary.
  • the corresponding certificate may be retransmitted to the counterpart device.
  • retransmission may be attempted as many times as a preset maximum number of retransmissions. Or, it may be repeated until it is confirmed that the corresponding certificate has been transmitted to the other terminal. Alternatively, depending on the implementation of the terminal, it may be retransmitted repeatedly until the corresponding certificate is deleted. For example, in the case of the finalizationResponse, until it is deleted in step 17045, the first terminal may repeatedly attempt to retransmit the finalizationResponse.
  • the two devices can establish a new connection and transmit and receive the corresponding certificate.
  • the two terminals can select and/or verify the target of the newly established connection using the records that have been transmitted/received while communicating in the past, and can determine what data to transmit and receive with the newly established counterpart. Validity and/or content of data received from the terminal can be verified.
  • retransmission may be automatically initiated by an operation inside the terminal, may be initiated by a request from an external server, or may be initiated by a user input.
  • FIG. 18 is a diagram illustrating a configuration of a “certificate (Attestation)” according to some embodiments of the present disclosure.
  • the certificate may optionally include “Attestation Info” (1810).
  • Attestation Info For various examples of data included in the certificate information, reference will be made to the description of FIGS. 22 to 27 to be described later.
  • the certificate may optionally further include "Issuer ID of the subject that issued the certificate” (1830).
  • Issuer ID of the subject that issued the certificate (1830).
  • Various examples of the subject issuing the certificate will be referred to the description of FIGS. 22 to 27 to be described later.
  • the certificate may optionally further include “information on an operation performed by the certificate issuer (Command)” (1850).
  • Communication information on an operation performed by the certificate issuer
  • the certificate may optionally further include other data other than the above-described information (1870).
  • other data that may be included in the certificate, reference will be made to the description of Figs.
  • the certificate may include electronic signature data for the above-described information (1890).
  • This signature data may be an electronic signature generated by the certificate issuer's signature certificate.
  • 19 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 1900 includes a first LBA 1920 and a first SSP 1910
  • the second terminal 1950 includes a second LBA 1970 and It may include a second SSP (1960).
  • the first terminal 1900 may be a terminal equipped with a first SSP 1910 and a first LBA 1920 for controlling the first SSP 1910
  • the second terminal 1950 2 It may be a terminal in which the SSP (1960) is mounted and the second LBA (1970) for controlling the second SSP (1960) is installed.
  • step 19000 the first SSP 1910 of the first terminal 1900, the first LBA 1920, and the second LBA 1970 of the second terminal 1950 are prepared for bundle transmission.
  • You can perform a procedure (a procedure for preparing to send a bundle).
  • a procedure for preparing to send a bundle.
  • step 19005 a procedure for transmitting a bundle from a first terminal 1900 to a second terminal 1950 (a bundle transmission procedure) may be performed.
  • a bundle transmission procedure a procedure for transmitting a bundle from a first terminal 1900 to a second terminal 1950 (a bundle transmission procedure) may be performed.
  • a first terminal 1900 and a second terminal 1960 may perform a procedure for installing a transmitted bundle and a procedure for setting a state of a bundle (a procedure for finishing a bundle transmission).
  • a procedure for installing a transmitted bundle and a procedure for setting a state of a bundle (a procedure for finishing a bundle transmission).
  • FIG. 20 is a diagram illustrating a detailed procedure for a procedure for preparing for bundle transmission among the procedures presented in FIG. 19.
  • FIG. 20 is a diagram exemplarily illustrating a procedure in which one terminal undergoes a necessary preparation process to transmit a bundle to another terminal according to an embodiment of the present disclosure.
  • the procedure of FIG. 20 may be referred to as a bundle transmission preparation procedure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 2000 includes a first LBA 2020 and a first SSP 2010, and the second terminal 2050 includes a second LBA 2070 and It may include a second SSP (2060).
  • the first terminal 2000 may be a terminal equipped with a first SSP 2010 and a first LBA 2020 for controlling the first SSP 2010, and the second terminal 2050 2 It may be a terminal in which the SSP 2060 is mounted and the second LBA 2070 for controlling the second SSP 2060 is installed.
  • the first terminal 2000 may have a pre-installed bundle, and may further have metadata associated with the bundle.
  • the first terminal 2000 is associated with a corresponding bundle and provides at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), or a bundle family manager identifier (SPB Family Custodian Object ID). You may have it.
  • SPB ID bundle identifier
  • SPB Family ID bundle family identifier
  • SPB Family Custodian Object ID bundle family manager identifier
  • the first terminal 2000 may be linked with a corresponding bundle to hold a'bundle movement setting'.
  • the bundle movement setting may selectively include information related to whether a corresponding bundle can be transmitted between devices.
  • the bundle movement setting may optionally further include “registration setting” for a process of registering the transmission result between devices of the corresponding bundle in the server.
  • registration setting for a process of registering the transmission result between devices of the corresponding bundle in the server.
  • the "registration setting" may be set by a service provider, may be set by a bundle management server, or may be set by cooperation between the service provider and the bundle management server.
  • this bundle movement setting may be included as data inside the bundle, may be included in the metadata of the bundle, or may exist as independent data.
  • the bundle movement setting may include an electronic signature of a service provider and/or a bundle management server.
  • information on a bundle to be transmitted between devices may be transmitted to a first LBA 2020 in step 20000.
  • This delivery process may be performed, for example, through a process in which a user directly selects a bundle through a UI provided by the first terminal 2000, as shown in FIG. 20, or through a push input from a remote server. It may be input to (2020), or the first LBA (2020) may access the remote server and read the corresponding information.
  • information related to a bundle selected through operation 20000 in operation 20005 may be transferred from the first LBA 2020 to the first SSP 2010.
  • information related to the selected bundle may be transmitted from the first LBA 2020 to the first SSP 2010 through the Select SPB command.
  • the information transmitted from the first LBA 2020 to the first SSP 2010 may include information for identifying the bundle selected in step 20000.
  • a first SSP 2010 may check whether a bundle requested to be transmitted can be transmitted between devices. This process may be performed by first identifying a bundle requested to be transmitted based on the information received in step 20005, and confirming a'bundle movement setting' associated with the bundle.
  • the first SSP 2010 may selectively set a'bundle movement code'.
  • The'bundle movement code' is a code used to refer to the corresponding bundle in the process of transmitting the bundle between devices and must be a value that can identify the corresponding bundle.
  • the first SSP 2010 may bind the aforementioned'bundle movement code' and information of a bundle to be transmitted.
  • a response result for step 20005 in step 20015 may be transmitted from the first SSP 2010 to the first LBA 2020.
  • a response to the Select SPB command may be transmitted from the first SPB 2010 to the first LBA 2020 through the Select SPB response.
  • This response value may include the'bundle movement code' described in step 20010.
  • information necessary for inter-device bundle transmission in step 20020 may be transferred from the first LBA 2020 of the first terminal 2000 to the second LBA 2070 of the second terminal 2050.
  • information transmitted from the first LBA 2020 to the second LBA 2070 may include a'bundle movement code'.
  • the information transmitted from the first LBA 2020 to the second LBA 2070 includes information necessary for connection established between the first LBA 720 and the second LBA 2070 in the next step 20025.
  • it may further include.
  • Information transmitted from the first LBA 2020 to the second LBA 2070 through the above-described step 20020 may be transmitted in various ways.
  • the first LBA may provide information to be transmitted to the second LBA to the user through the UI of the first terminal 2000, and the user can provide the received information by using the UI of the second terminal 2050. Can be entered into the second LBA.
  • the first LBA creates the information to be transmitted to the second LBA in the form of an image (for example, a QR code) and displays it on the screen of the first terminal, and the user scans this image using the second terminal 2050.
  • information can be delivered to the second LBA 2070.
  • a method of transferring information from the first LBA 2020 to the second LBA 2070 is not limited to the above methods.
  • a connection may be established (or established) between a first LBA 2020 and a second LBA 2070 in step 20025. If information necessary for connection is transmitted in step 20020, the first LBA 2020 and the second LBA 2070 may establish a connection using this information.
  • the connection between the first LBA 2020 and the second LBA 2070 may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), 5G D2D) or It may be a remote connection in which a remote server (eg, a relay server) is located between the first LBA 2020 and the second LBA 2070.
  • a remote server eg, a relay server
  • step 20025 is shown as the last step, but this step is independent of the other steps described above, namely, steps 20000, 20005, 20010, 20015, and 20020, and is dependent on other steps and sequences. Can be done without For example, step 20025 may be performed between steps 20015 and 20020, and in this case, information transmitted from the first LBA 2020 to the second LBA 2 2070 in step 20020 is through the connection established in step 20025. It can also be transmitted.
  • FIG. 21 is a diagram showing a detailed procedure for a procedure in which a bundle is transmitted among the procedures presented in FIG. 19.
  • FIG. 21 is a diagram illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure.
  • the procedure of FIG. 21 may be referred to as a bundle transmission procedure.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 2100 includes a first LBA 2120 and a first SSP 2110
  • the second terminal 2150 includes a second LBA 2170 and It may include a second SSP (2160).
  • the first terminal 2100 may be a terminal equipped with a first SSP 2110 and a first LBA 2120 for controlling the first SSP 2110
  • the second terminal 2150 2 It may be a terminal in which the SSP 2160 is mounted and the second LBA 2170 for controlling the second SSP 2160 is installed.
  • the second LBA 2170 may request “SSP information (SspInfo)” from the second SSP 2 2160.
  • SSP information SspInfo
  • the second LBA 2170 indicates that the bundle movement between devices will be performed to the second SSP 2160. I can tell you.
  • step 21000 may be automatically performed immediately following the process illustrated in FIG. 21, or may be performed after receiving an external input.
  • the'external input' may be performed through a process of selecting a bundle to be directly transmitted by the user through a UI provided by the second terminal 2150, or the second LBA 2170 through a push input from a remote server.
  • the second LBA 2170 may access the remote server and read the corresponding information.
  • the second SSP 2160 may generate its own “SSP information”.
  • the "SSP information” may include information on the second SSP to be provided for bundle transmission.
  • the "SSP information” may include information (certificate negotiation information) for a certificate negotiation process that the second SSP 2160 must go through before receiving the bundle.
  • This "certificate negotiation information” may include certificate information (SenderSpblVerification) that the second SSP 2160 can use to verify another SSP and certificate information (ReceiverSpblVerification) that can be used by another SSP to verify itself. have.
  • the "certificate negotiation information" may optionally further include a list of key agreement algorithms supported by the second SSP 2160, and may optionally further include a list of encryption algorithms supported by the second SSP 2160.
  • the "SSP information” may optionally further include SSP version information including at least one of version information of a primary platform included in the second SSP 2160 and version information of a standard standard supported by the loader.
  • the second SSP 2160 may transmit the "SSP information" generated in step 21005 to the first SSP 2110 through the second LBA 2170 and the first LBA 2120. have.
  • the second LBA 2170 requests "SSP information (SspInfo)" from the second SSP 2160, and the second SSP 2160 requests its "SSP information".
  • the second SSP 2160 may transmit “SSP information” to the first SSP 2110 through the second LBA 2170 and the first LBA 2120.
  • the process of transmitting "SSP information" from the second terminal 2150 to the first terminal 2100 may be as follows.
  • the second LBA 2170 may generate “SSP information” by itself and then transmit the “SSP information” to the first SSP 2110 through the first LBA 2120.
  • step 21015 the first SSP 2110 checks the received "SSP information” and generates "first terminal authentication information (Device1.Auth)” that can authenticate itself based on this information. can do.
  • first terminal authentication information Device1.Auth
  • the first SSP 2110 may check certificate information capable of verifying itself using the received "SenderSpblVerification” and select at least one key agreement certificate (ssp1.Cert.KA).
  • the first SSP 2110 uses the received "list of key agreement algorithms supported by the second SSP 2160" to be used for key agreement, and the asymmetric encryption key pair public key "ssp1.ePK.KA” After creating “and the private key "ssp1.eSK.KA", you can select the public key (ssp1.ePK.KA) from this key pair.
  • the first SSP 2110 may check certificate information capable of verifying itself using the received "SenderSpblVerification” and further select at least one signature certificate (ssp1.Cert.DS).
  • the first SSP 2110 may select at least one certificate information of the second SSP 2160 to be verified using the received "ReceiverSpblVerification” and then set the corresponding information to "CiPkIdToBeUsed”.
  • the first SSP 2110 may select at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 2160" and then set corresponding information to "CryptoToBeUsed”. .
  • the first SSP 2110 checks the list of the received "version information of the primary platform included in the second SSP 2160 and the standard standard supported by the loader", and among them, the version of the standard standard that it also supports. You can check if it exists.
  • the “first terminal authentication information (Device1.Auth)” may include at least one of “ssp1.Cert.KA”, “ssp1.ePK.KA” “CiPkIdToBeUsed”, and “CryptoToBeUsed” described above.
  • the “first terminal authentication information (Device1.Auth)” may optionally further include “ssp1.Cert.DS” described above.
  • the “first terminal authentication information (Device1.Auth)” may optionally further include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future. I can.
  • first terminal authentication information (Device1.Auth)" mentioned above may be digitally signed so that it can be verified using ssp1.Cert.DS to ensure the integrity of the information, and this digital signature Data may be added as part of the "first terminal authentication information".
  • step 21020 the first SSP 2110 passes the first LBA 2120 to the second LBA 2170 to transmit “first terminal authentication information (Device1.Auth)” generated in step 21015. I can.
  • the second LBA 2170 may transmit “first terminal authentication information (Device1.Auth)” to the second SSP 2160.
  • the second LBA 2170 may further transmit a "bundle movement code” to the second SSP 2160.
  • the second SSP 2160 may verify the received “first terminal authentication information (Device1.Auth)”. If the second SSP 2160 receives "ssp1.Cert.KA”, it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2160 receives "ssp1.ePK.KA” and a digital signature for it, it first checks the validity of ssp1.Cert.DS and then checks the digital signature using this certificate. You can check the integrity of the public key ssp1.ePK.KA. In addition, the second SSP 2160 may select at least one signing certificate (ssp2.Cert.DS) capable of verifying itself by checking the received "CiPkIdToBeUsed”.
  • ssp2.Cert.DS at least one signing certificate
  • the second SSP 2160 uses a public key "ssp2.ePK.KA” and a private key “ssp2.eSK.” as an asymmetric encryption key pair to be used for key agreement. After creating “KA”, you can select the public key (ssp2.ePK.KA) from this key pair. In addition, the second SSP 2160 selects one of the public key for key agreement or ssp1.ePK.KA included in ssp1.Cert.KA, and then uses this value and ssp2.eSK.KA to communicate with the terminal 1 in the future. Session key ShKey01 to be used for encryption during communication can be generated. ShKey01 must be a session key for the encryption algorithm included in the received "CryptoToBeUsed”.
  • the second SSP 2160 may generate “second terminal authentication information (Device2.Auth)” capable of authenticating itself.
  • the "second terminal authentication information (Device2.Auth)” may include “ssp2.Cert.DS”.
  • the “second terminal authentication information (Device2.Auth)” may further include “ssp2.ePK.KA”.
  • the “second terminal authentication information (Device2.Auth)” may further include a transaction ID indicating the current session generated by the SSP 2 2160.
  • the “second terminal authentication information (Device2.Auth)” may further include a "bundle movement code”.
  • the "second terminal authentication information (Device2.Auth)" may further include an SSP identifier of the second SSP 2160.
  • the "second terminal authentication information (Device2.Auth)” may optionally further include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future. I can.
  • Second terminal authentication information (Device2.Auth) may be digitally signed so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information, and this digital signature Data may be added as part of the "second terminal authentication information".
  • this digital signature Data may be added as part of the "second terminal authentication information”.
  • some or all of the "second terminal authentication information (Device2.Auth)" may be encrypted using the previously generated session key ShKey01.
  • step 21035 the second SSP 2160 passes through the second LBA 2170 and the first LBA 2120 to the first SSP 2110 generated in step 21030.
  • Device2.Auth can be delivered.
  • a “bundle movement code” may be selectively further transmitted.
  • the first SSP 2110 may verify the received “second terminal authentication information (Device2.Auth)”.
  • the first SSP 2110 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp2.Cert.DS”.
  • the first SSP 2110 checks whether the received bundle family identifier (SPB Family ID) and/or the bundle family manager identifier (SPB Family Custodian Object ID) is a value set correctly in association with the bundle to be transmitted. I can.
  • the first SSP 2110 may store the received transaction ID and/or the SSP identifier of the second SSP 2160.
  • the first SSP 2110 may bind the received transaction ID or the SSP identifier of the second SSP 2160 with a currently ongoing session or a bundle to be transmitted.
  • the first SSP 2110 is transmitted to the received ssp2.ePK.KA and its own ssp1.Cert.KA.
  • a session key ShKey01 can be generated using a private key corresponding to the included public key for key agreement or ssp1.eSK.KA, and the encrypted data can be decrypted using this session key, and then the verification process can be performed.
  • the first SSP 2110 uses the "ssp2.Cert.DS" to determine the validity of the digital signature received. Can be verified.
  • the first SSP 2110 includes an asymmetric encryption key pair public key "ssp1.bundle.ePK.KA” and a secret key “ssp1. bundle.eSK.KA” can be created.
  • the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA” may be set to the same value as the previously created "ssp1.ePK.KA and ssp1.eSK.KA”.
  • the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA” will be set to the same value as the public key included in the previously used "ssp1.Cert.KA and the corresponding private key”. May be.
  • the first SSP 2110 may generate the session key ShKey02 using ssp1.bundle.eSK.KA and ssp2.ePK.KA. If ssp1.eSK.KA or the private key corresponding to the public key included in ssp1.Cert.Ka is reused for ssp1.bundle.eSK.KA, the value of the session key ShKey02 is also of the previously generated ShKey01. Can be set to a value.
  • the first SSP 2110 may configure a bundle to be transmitted to the second terminal 2150 and/or metadata associated with the bundle.
  • the first SSP 2110 may identify a bundle to be transmitted by using the received "bundle movement code".
  • "ssp1.Cert.DS” may be included in the bundle to be configured.
  • the bundle to be configured may further include "ssp1.bundle.ePK.KA”.
  • the bundle to be configured may further include a transaction ID identifying a corresponding session.
  • the bundle to be configured may optionally further include at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID) associated with the to-be-transmitted bundle.
  • SPB ID bundle identifier
  • SPB Family ID bundle family identifier
  • SPB Family Custodian Object ID bundle family manager identifier
  • a "bundle movement setting" may be included in the bundle (or metadata associated with the bundle) configured in step 21040.
  • digital signature data generated using ssp1.Cert.DS may be added to a bundle to be configured in step 21040. That is, digital signature data generated for some or all of the components of the bundle specified above may be added as a part of the bundle.
  • some or all of the bundles to be configured may be encrypted using ShKey02.
  • a first SSP 2110 may transmit a bundle generated (configured) in step 21040 to a second LBA 2170 via a first LBA 2120.
  • metadata associated with the transmitted bundle may be selectively further transmitted.
  • a "bundle movement setting" associated with the transmitted bundle may be further transmitted.
  • the “bundle movement setting” may not be included in the bundle or metadata, but may be transmitted in a separate format (eg, a message).
  • FIG. 22 is a diagram illustrating a detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.
  • this may be a procedure that applies.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 2200 includes a first LBA 2220 and a first SSP 2210
  • the second terminal 2250 includes a second LBA 2270 and A second SSP 2260 may be included.
  • the first terminal 2200 may be a terminal equipped with a first SSP 2210 and a first LBA 2220 for controlling the first SSP 2210
  • the second terminal 2250 2 It may be a terminal in which the SSP 2260 is mounted and the second LBA 2270 for controlling the second SSP 2260 is installed.
  • step 22000 the following procedures may be performed in step 22000.
  • the second LBA 2270 and the second SSP 2260 may cooperate with each other to install a bundle in the second terminal 2250.
  • the following procedures can be performed together. If metadata is transmitted, the second LBA 2270 or the second SSP 2260 may verify content included in the metadata. If "bundle movement setting" is transmitted, the second LBA 2270 may transmit the information to the second SSP 2260. If a transaction ID has been transmitted, the second LBA 2270 or the second SSP 2260 may check whether the transaction ID is the same as the transaction ID used in the current session.
  • the second LBA 2270 or the second SSP 2260 is It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS is transmitted, the second SSP 2260 may verify the validity of this certificate to authenticate the first SSP 2210. If the transmitted data contains encrypted data, the second SSP 2260 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, verification can be performed. If the received data includes a digital signature, the second SSP 2260 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.
  • the 2nd LBA 2270 and/or the 2nd SSP 2260 uses the "registration setting" of the corresponding bundle to'whether notification is required' and/or'whether or not pre-announcement is required' and/or You can check'whether the notification contents need to be encrypted.' This process is part of step 22000 and can be performed independently of other procedures in step 22000 and in any order. Alternatively, after step 22000, before step 22035 is completed, it may be performed at a moment when judgment is required. A procedure to be described later in this drawing may be a procedure applied when, as a result of confirming the “registration setting”, the transmission details between devices of the bundle do not need to be announced.
  • the second SSP 2260 may set the state of a corresponding bundle to “IN TRANSITION”.
  • IN TRANSITION is a state in which the bundle has been successfully installed but is not yet available (also, additional operations such as'an additional operation to be described later in this drawing' and/or'a request from an external server (although not described in this disclosure)') It means a state that can be changed to an available state (Disabled, Enable, Active state) only by.
  • the second LBA 2270 may request a “certificate” from the second SSP 2260.
  • the second SSP 2260 may generate a “certificate”.
  • this certificate may be called finalizationRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • the finalizationRequest may include the "bundle identifier" of the corresponding bundle in 1810 of FIG. 18.
  • the finalizationRequest may include the "SSP identifier" of the second SSP in 1830 of FIG. 18.
  • the finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 1850 of FIG. 18.
  • the finalizationRequest may selectively include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • the finalizationRequest may include signature information of the second SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 2260 may transmit a finalization Request to the first SSP 2210.
  • the second SSP 2260 may transmit a finalizationRequest to the first SSP 2210 through the following process. That is, the second SSP 2260 transmits a finalization Request to the second LBA 2270 in response to step 22010, and the second LBA 2270 sends a finalization request to the first SSP 2210 through the first LBA 2220. I can deliver.
  • a first SSP 2210 may verify a received finalizationRequest.
  • This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest.
  • the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP.
  • the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.
  • the first SSP 2210 may delete the bundle after completing the verification.
  • the first SSP 2210 may generate a "certificate".
  • this certificate may be called finalizationResponse.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • the finalizationResponse may include the "bundle identifier" of the corresponding bundle in 1810 of FIG. 18. Alternatively, it may include some and/or all data of the finalizationRequest received in the previous step.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 1830 of FIG. 18.
  • the finalizationResponse may include information indicating that the first SSP has deleted the bundle in 1850 of FIG. 18.
  • the finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • the finalizationResponse may include signature information of the first SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • a first SSP 2210 may transmit a finalizationResponse to a second SSP 2260.
  • the first SSP 2210 may transmit a finalizationResponse to the second SSP 2260 through the first LBA 2220 and the second LBA 2270.
  • the second SSP 2260 may verify the received finalizationResponse.
  • This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse.
  • the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle.
  • this verification process may include a process of checking whether some or all of the data of the finalizationRequest included in the finalizationResponse is consistent with the information transmitted by the finalizationResponse.
  • the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse.
  • the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.
  • the second SSP 2260 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification.
  • the second SSP 2260 may convert the bundle state to the Disabled state.
  • the second SSP 2260 may generate a "certificate".
  • this certificate may be referred to as spblAttestation.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • -spblAttestation may include a "bundle separator" of a corresponding bundle in 1810 of FIG. 18.
  • some and/or all data of the finalizationRequest and/or finalizationResponse may be included.
  • -spblAttestation may include the “SSP identifier” of the second SSP in 1830 of FIG. 18.
  • -spblAttestation may include information indicating that the second SSP has changed the bundle to one of the usable states in 1850 of FIG. 18.
  • -spblAttestation may optionally include a time when the second SSP changes the state of the bundle to one of the usable states or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • -spblAttestation may include the signature information of the second SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 2260 may generate its own "selected SSP information (sspInforSelected)".
  • the "selected SSP information” may include information on the second SSP that must be provided to notify the server of the bundle transmission result between devices.
  • the "selected SSP information” may include information for a certificate negotiation process (certificate negotiation information).
  • certificate negotiation information may optionally further include a list of key agreement algorithms supported by the second SSP 2260, and may optionally further include a list of encryption algorithms supported by the second SSP 2260. I can.
  • the "selected SSP information" may optionally further include SSP version information including at least one of version information of a standard standard supported by a primary platform and a loader included in the second SSP 2260.
  • the second SSP 2260 may transmit a result (eg, success or failure) of the task performed in step 22035 to the second LBA 2270.
  • a result eg, success or failure
  • selected SSP information generated in step 22035 may be transmitted together.
  • the process of generating the “selected SSP information” in step 22035 and the process of transmitting the “selected SSP information” in step 22040 may be omitted.
  • FIG. 23 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 22.
  • the terminal may include at least one LBA and at least one SSP.
  • the second terminal 2350 may include a second LBA 2370 and a second SSP 2360.
  • the second terminal 2350 may be a terminal equipped with a second SSP 2360 and a second LBA 2370 for controlling the second SSP 2360.
  • the server 2300 may be a server operated by a service provider, a bundle management server, a server operated by cooperation between a service provider and a bundle management server, or a service It may be any server operated in connection with the provider and/or the bundle management server.
  • SPBM which is one of the possible examples of the server, is sometimes used to refer to the server 2300, but as described above, the type of server is not limited to SPBM.
  • step 23000 a Transport Layer Security (TLS) connection may be established between the SPBM 2300 and the LBA 2370.
  • TLS Transport Layer Security
  • step 23000 may be performed independently from steps 23005 to 23015 before step 23020 is performed.
  • step 23000 may be performed between steps 23015 and 23020.
  • the second LBA 2370 may request “selected SSP information (SspInfoSelected)” from the second SSP 2 2360.
  • step 23005 may be performed automatically or may be performed after receiving an external input.
  • the'external input' may be given from a user through a UI provided by the second terminal 2350 or may be given to the second terminal 2350 through a push input from a remote server.
  • the second SSP 2360 may generate its own “selected SSP information”.
  • selected SSP information refer to the description described in FIG. 22.
  • the second SSP 2360 may transmit “selected SSP information” generated in step 23010 to the second LBA 2370.
  • Steps 23005 to 23015 may not be selectively performed.
  • the second LBA 2370 may transmit “selected SSP information” to the server 2300. If the second LBA 2370 receives “selected SSP information” through steps 22035 to 22040 of FIG. 22, or receives “selected SSP information” through steps 23005 to 23015 of FIG. 23, the second LBA ( 2370) may transmit the received “selected SSP information” to the server 2300. If the second LBA 2370 does not receive “selected SSP information”, the second LBA 2370 may generate “selected SSP information” and transmit it to the server 2300.
  • the server 2300 may check the received “selected SSP information” and generate “server authentication information (SPBM.Auth)” capable of authenticating itself based on this information. .
  • SPBM.Auth server authentication information
  • the server 2300 may check certificate information capable of verifying itself using the received "spbmVerification” and select at least one key agreement certificate (spbm.Cert.KA).
  • the server 2300 uses the received "list of key agreement algorithms supported by the second SSP 2360" to use the asymmetric encryption key pair public key "spbm.ePK.KA” to be used for key agreement. After creating the private key "spbm.eSK.KA", you can select the public key (spbm.ePK.KA) from this key pair.
  • the server 2300 may check certificate information capable of verifying itself using the received "spbmVerification” and further select at least one signing certificate (spbm.Cert.DS).
  • the server 2300 may check whether the certificate information of the first SSP 2210 to be verified by using the received "SenderSpblVerification" is verifiable by itself. This process may not be selectively performed.
  • the server 2300 may check whether the certificate information of the second SSP 2360 to be verified by using the received “ReceiverSpblVerification” is verifiable by itself. Alternatively, after selecting at least one certificate information of the second SSP 2360 that can be verified by using “ReceiverSpblVerification”, the corresponding information may be set as “CiPkIdToBeUsed”.
  • the server 2300 may select at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 2360" and then set corresponding information to "CryptoToBeUsed”.
  • the server 2300 checks the list of the received "version information of the primary platform included in the second SSP 2360 and the standard standard supported by the loader", and among them, there is a version of the standard standard that it also supports. You can check whether it is.
  • Server authentication information may include at least one of “spbm.Cert.KA”, “spbm.ePK.KA”, “CiPkIdToBeUsed”, and “CryptoToBeUsed” described above.
  • server authentication information may optionally further include “spbm.Cert.DS” described above.
  • server authentication information (SPBM.Auth)" mentioned above may be digitally signed so that it can be verified using spbm.Cert.DS to ensure the integrity of the information, and this digital signature data is It can be added as part of the "server authentication information".
  • the server 2300 may transmit “server authentication information (SPBM.Auth)” generated in step 23025 to the second SSP 2360 through the second LBA 2370.
  • SPBM.Auth server authentication information
  • the second SSP 2360 may verify the received “server authentication information (SPBM.Auth)”. If the second SSP 2360 receives "spbm.Cert.KA”, it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2360 receives "spbm.Cert.DS”, it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2360 receives "spbm.ePK.KA” and a digital signature for it, the integrity of the received public key spbm.ePK.KA is verified by verifying the digital signature using spbm.Cert.DS. can confirm. In addition, when the second SSP 2360 receives “CiPkIdToBeUsed”, it may check and select at least one signing certificate (ssp2.Cert.DS) capable of verifying itself.
  • ssp2.Cert.DS signing certificate capable of verifying itself.
  • the second SSP 2360 uses a public key "ssp2.ePK.KA” and a private key “ssp2.eSK.” as an asymmetric encryption key pair to be used for key agreement. After creating "KA”, you can select the public key (ssp2.ePK.KA) from this key pair. In addition, the second SSP 2360 selects one of the public key for key agreement or spbm.ePK.KA included in spbm.Cert.KA, and then communicates with the server in the future using this value and ssp2.eSK.KA. Session key ShKey03 to be used for middle encryption can be generated. ShKey03 must be the session key for the encryption algorithm contained in the received "CryptoToBeUsed”.
  • the second SSP 2360 may generate “terminal authentication information (Device.Auth)” capable of authenticating itself.
  • the "terminal authentication information (Device.Auth)” may include “ssp2.Cert.DS”.
  • the "terminal authentication information (Device.Auth)” may optionally further include “ssp1.Cert.DS”.
  • terminal authentication information (Device.Auth)” may further include certificate chain information associated with “ssp2.Cert.DS” and/or “ssp1.Cert.DS”.
  • terminal authentication information (Device.Auth)” may include part and/or all of spblAttestation.
  • terminal authentication information may include part and/or all of the finalizationRequest.
  • terminal authentication information (Device.Auth) may include part and/or all of the finalizationResponse.
  • the “terminal authentication information (Device.Auth)” may further include “ssp2.ePK.KA”.
  • part or all of the “device authentication information (Device.Auth)” mentioned above may be digitally signed to be verified using ssp2.Cert.DS to ensure the integrity of the information, and this digital signature data may be digitally signed. It can be added as part of "terminal authentication information”.
  • part or all of the “terminal authentication information (Device.Auth)” may be encrypted using the previously generated session key ShKey03.
  • the second SSP 2360 may transmit “terminal authentication information (Device.Auth)” generated in step 23035 to the server 2300 through the second LBA 2370.
  • the server 2300 may verify the received "terminal authentication information (Device.Auth)".
  • the specific procedure of the verification process is as follows.
  • the server 2300 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp1.Cert.DS” and/or "ssp2.Cert.DS".
  • the server 2300 may verify the signature of the received spblAttestation and/or finalizationRequest and/or finalizationResponse.
  • the server 2300 may verify the contents of the received spblAttestation and/or finalizationRequest and/or finalizationResponse.
  • the server 2300 may update the details of the bundle transmitted between devices based on the verified content. For example, the server 2300 may update a mapping relationship between the bundle and the first SSP 2210 to a mapping relationship between the bundle and the second SSP 2360.
  • the server 2300 receives the transmitted ssp2.ePK.KA and the key included in its spbm.Cert.KA.
  • a session key ShKey03 can be generated using a secret key corresponding to the consensus public key or spbm.eSK.KA, and the encrypted data can be decrypted using this session key, and then the verification process can be performed.
  • the server 2300 may transmit a result (eg, success or failure) of a task performed in step 23045 to the second LBA 2370.
  • a result eg, success or failure
  • FIG. 24 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 2400 includes a first LBA 2420 and a first SSP 2410
  • the second terminal 2450 includes a second LBA 2470 and A second SSP 2460 may be included.
  • the first terminal 2400 may be a terminal equipped with a first SSP 2410 and a first LBA 2420 for controlling the first SSP 2410
  • the second terminal 2450 2 It may be a terminal in which the SSP 2460 is mounted and the second LBA 2470 for controlling the second SSP 2460 is installed.
  • step 24000 the following procedures may be performed in step 24000.
  • the second LBA 2470 and the second SSP 2460 may cooperate with each other to install a bundle in the second terminal 2450.
  • the following procedures can be performed together. If metadata is transmitted, the second LBA 2470 or the second SSP 2460 may verify content included in the metadata. If "bundle movement setup" has been transmitted, the second LBA 2470 may transfer this information to the second SSP 2460. If a transaction ID has been transmitted, the second LBA 2470 or the second SSP 2460 may check whether the transaction ID is the same as the transaction ID used in the current session.
  • the second LBA 2470 or the second SSP 2460 is It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS has been transmitted, the second SSP 2460 may verify the validity of this certificate to authenticate the first SSP 2410. If the transmitted data contains encrypted data, the second SSP 2460 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, you can perform verification. If the received data includes a digital signature, the second SSP 2460 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.
  • the 2nd LBA 2470 and/or the 2nd SSP 2460 uses the "registration setting" of the corresponding bundle to'whether notification is required' and/or'whether or not pre-announcement is required' and/or You can check'whether the notification contents need to be encrypted.' This process is part of the 24000 step and can be done independently of the other procedures in the 24000 step and in any order. Alternatively, after step 24000, before step 24035 is completed, it may be performed at a moment when judgment is required.
  • a procedure to be described later in this drawing may be a procedure applied when, as a result of confirming the “registration setting”, the transmission details of the bundle between devices do not need to be a pre-announcement and the content of the announcement does not need to be encrypted.
  • the second SSP 2460 may set the state of a corresponding bundle to “IN TRANSITION”.
  • IN TRANSITION is a state in which the bundle has been successfully installed but is not yet available (also, additional operations such as'an additional operation to be described later in this drawing' and/or'a request from an external server (although not described in this disclosure)) It means a state that can be changed to an available state (Disabled, Enable, Active state) only by.
  • the second LBA 2470 may request a “certificate” from the second SSP 2460.
  • the second SSP 2460 may generate a “certificate”.
  • this certificate may be called finalizationRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • the finalizationRequest may include the "bundle identifier" of the corresponding bundle in 1810 of FIG. 18.
  • the finalizationRequest may include the "SSP identifier" of the second SSP in 1830 of FIG. 18.
  • the finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 1850 of FIG. 18.
  • the finalizationRequest may selectively include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • the finalizationRequest may include signature information of the second SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 2460 may transmit a finalization Request to the first SSP 2410.
  • the second SSP 2460 may transmit a finalizationRequest to the first SSP 2410 through the following process. That is, the second SSP 2460 transmits a finalization Request to the second LBA 2470 in response to step 24010, and the second LBA 2470 sends a finalization request to the first SSP 2410 through the first LBA 2420. I can deliver.
  • a first SSP 2410 may verify a received finalizationRequest.
  • This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest.
  • the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP.
  • the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.
  • the first SSP 2410 may delete the bundle after completing the verification.
  • the first SSP 2410 may generate a "certificate".
  • this certificate may be called finalizationResponse.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • the finalizationResponse may include the "bundle identifier" of the corresponding bundle in 1810 of FIG. 18. Alternatively, it may include some and/or all data of the finalizationRequest received in the previous step.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 1830 of FIG. 18.
  • the finalizationResponse may include information indicating that the first SSP has deleted the bundle in 1850 of FIG. 18.
  • the finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • the finalizationResponse may include signature information of the first SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • a first SSP 2410 may transmit a finalizationResponse to a second SSP 2460.
  • the first SSP 2410 may transmit a finalizationResponse to the second SSP 2460 through the first LBA 2420 and the second LBA 2470.
  • the second SSP 2460 may verify the received finalizationResponse.
  • This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse.
  • the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle.
  • this verification process may include a process of checking whether some or all of the data of the finalizationRequest included in the finalizationResponse is consistent with the information transmitted by the finalizationResponse.
  • the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse.
  • the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.
  • the second SSP 2460 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification.
  • the second SSP 2460 may convert the state of the bundle to the Disabled state.
  • the second SSP 2460 may generate a "certificate".
  • this certificate may be referred to as spblAttestation.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • -spblAttestation may include a "bundle separator" of a corresponding bundle in 1810 of FIG. 18.
  • some and/or all data of the finalizationRequest and/or finalizationResponse may be included.
  • -spblAttestation may include the “SSP identifier” of the second SSP in 1830 of FIG. 18.
  • -spblAttestation may include information indicating that the second SSP has changed the bundle to one of the usable states in 1850 of FIG. 18.
  • -spblAttestation may optionally include a time when the second SSP changes the state of the bundle to one of the usable states or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • -spblAttestation may include the signature information of the second SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 2460 may transmit spblAttestation generated in step 24035.
  • 25 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 24.
  • the terminal may include at least one LBA and at least one SSP.
  • the second terminal 2550 may include a second LBA 2570 and a second SSP 2560.
  • the second terminal 2550 may be a terminal equipped with a second SSP 2560 and a second LBA 2570 for controlling the second SSP 2560.
  • the server 2500 may be a server operated by a service provider, a bundle management server, a server operated by cooperation between a service provider and a bundle management server, or a service It may be any server operated in connection with the provider and/or the bundle management server.
  • SPBM which is one of the possible examples of the server, is sometimes used to refer to the server 2500, but as described above, the type of server is not limited to SPBM.
  • a Transport Layer Security (TLS) connection may be established between the SPBM 2500 and the LBA 2570.
  • TLS Transport Layer Security
  • the second LBA 2570 may transmit a part and/or all of spblAttestation and/or finalizationRequest and/or finalizationResponse to the server 2500.
  • the second LBA 2570 may further transmit “selected SSP information” to the server 2500.
  • selected SSP information refer to the description of FIG. 22.
  • the second LBA 2570 may selectively further transmit “ssp2.Cert.DS” to the server 2500.
  • the second LBA 2570 may selectively further transmit “ssp1.Cert.DS” to the server 2500.
  • the second LBA 2570 may further include certificate chain information associated with “ssp2.Cert.DS” and/or “ssp1.Cert.DS” to the server 2500.
  • the above information may be configured and transmitted by the second LBA 2570 itself, and although not shown in this figure, the second LBA 2570 may request the corresponding information from the second SSP 2560 and then transmit the received information. Or, although not shown in this figure, the second LBA 2570 may request a part of the corresponding information from the second SSP 2560 and then combine the received information with the information held by the second LBA 2570 and transmit it.
  • the server 2500 may verify information received in step 25005.
  • the specific procedure of the verification process is as follows.
  • the server 2500 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp1.Cert.DS" and/or "ssp2.Cert.DS".
  • the server 2500 may verify the signature of the received spblAttestation and/or finalizationRequest and/or finalizationResponse.
  • the server 2700 may verify the contents of the received spblAttestation and/or finalizationRequest and/or finalizationResponse.
  • the server 2500 may update the details of the bundle transmitted between devices based on the verified content. For example, the server 2500 may update a mapping relationship between the bundle and the first SSP 2410 to a mapping relationship between the bundle and the second SSP 2500.
  • the server 2500 may transmit the result of the verification operation performed in step 25010 to the second LBA 2570.
  • the server 2500 may transmit the success or failure of verification to the second LBA 2570.
  • FIG. 26 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19.
  • this may be a procedure that applies.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 2600 includes a first LBA 2620 and a first SSP 2610
  • the second terminal 2650 is a second LBA 2670 and A second SSP 2660 may be included.
  • the first terminal 2600 may be a terminal equipped with a first SSP 2610 and a first LBA 2620 for controlling the first SSP 2610
  • the second terminal 2650 2 It may be a terminal in which the SSP 2660 is mounted and the second LBA 2670 for controlling the second SSP 2660 is installed.
  • step 26000 the following procedures may be performed in step 26000.
  • the second LBA 2670 and the second SSP 2660 may cooperate with each other to install a bundle in the second terminal 2650.
  • the following procedures can be performed together. If metadata is transmitted, the second LBA 2670 or the second SSP 2660 may verify content included in the metadata. If "bundle movement setup" has been transmitted, the second LBA 2670 may transmit this information to the second SSP 2660. If a transaction ID has been transmitted, the second LBA 2670 or the second SSP 2660 may check whether the transaction ID is the same as the transaction ID used in the current session.
  • the second LBA 2670 or the second SSP 2660 is It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS is transmitted, the second SSP 2660 may verify the validity of this certificate to authenticate the first SSP 2610. If the transmitted data contains encrypted data, the second SSP 2660 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, you can perform verification. If the received data includes a digital signature, the second SSP 2660 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.
  • the 2nd LBA 2670 and/or the 2nd SSP 2660 uses the "registration setting" of the corresponding bundle to'whether notification is necessary' and/or'whether or not preliminary notification is required' and/or You can check'whether the notification contents need to be encrypted.' This process is part of step 26000 and can be done independently of the other procedures in step 26000 and in any order. Alternatively, it may be performed at a moment when judgment is required, after step 26000 and before step 26035 is completed. A procedure to be described later in this drawing may be a procedure applied when, as a result of confirming the “registration setting”, the transmission details between devices of the bundle need to be announced.
  • the second SSP 2660 may set the state of a corresponding bundle to “IN TRANSITION”.
  • IN TRANSITION is a state in which the bundle has been successfully installed but is not yet available (also,'additional operations to be described later in this drawing and additional operations to be described in Fig. 27' and/or'(although not described in this disclosure) It means a state that can be changed to an available state (Disabled, Enable, Active state) only by an additional operation such as'Request from server'.
  • the second LBA 2670 may request a “certificate” from the second SSP 2660.
  • the second SSP 2660 may generate a “certificate”.
  • this certificate may be called finalizationRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • the finalizationRequest may include the "bundle identifier" of the corresponding bundle in 1810 of FIG. 18.
  • the finalizationRequest may include the "SSP identifier" of the second SSP in 1830 of FIG. 18.
  • the finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 1850 of FIG. 18.
  • the finalizationRequest may selectively include a time when the second SSP changes the state of the bundle to an “IN TRANSITION” state or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • the finalizationRequest may include signature information of the second SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 2660 may transmit a finalization Request to the first SSP 2610.
  • the second SSP 2660 may transmit a finalizationRequest to the first SSP 2610 through the following process. That is, the second SSP 2660 may transmit the finalizationRequest to the second LBA 2670 in response to step 26010, and the second LBA may transmit the finalizationRequest to the first SSP through the first LBA 2620.
  • the first SSP 2610 may verify the received finalizationRequest.
  • This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest.
  • the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP.
  • the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.
  • the first SSP 2610 may delete the bundle after completing the verification.
  • the first SSP 2610 may generate a "certificate".
  • this certificate may be called finalizationResponse.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • the finalizationResponse may include the "bundle identifier" of the corresponding bundle in 1810 of FIG. 18. Alternatively, it may include some and/or all data of the finalizationRequest received in the previous step.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 1830 of FIG. 18.
  • the finalizationResponse may include information indicating that the first SSP has deleted the bundle in 1850 of FIG. 18.
  • the finalizationResponse may optionally include a time when the first SSP deletes a bundle or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • the finalizationResponse may include signature information of the first SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • a first SSP 2610 may transmit a finalizationResponse to a second SSP 2660.
  • the first SSP 2610 may transmit a finalizationResponse to the second SSP 2660 through the first LBA 2620 and the second LBA 2670.
  • the second SSP 2660 may verify the received finalizationResponse.
  • This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse.
  • the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle.
  • this verification process may include a process of checking whether the data daily or all of the finalizationRequest included in the finalizationResponse matches the information transmitted by the finalizationResponse.
  • the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse.
  • the verification process may further include a process of confirming whether the instruction information included in the finalizationResponse deletes the bundle.
  • the second SSP 2660 may generate its own "selected SSP information (sspInforSelected)".
  • the "selected SSP information" may include information on the second SSP that must be provided to notify the server of the bundle transmission result between devices.
  • the "selected SSP information” may include information for a certificate negotiation process (certificate negotiation information).
  • the "certificate negotiation information" may optionally further include a list of key agreement algorithms supported by the second SSP 2660, and may optionally further include a list of encryption algorithms supported by the second SSP 2660. I can.
  • selected SSP information may optionally further include SSP version information including at least one of version information of the standard standard supported by the primary platform and the loader included in the second SSP 2660.
  • the second SSP 2660 may transmit a result (eg, success or failure) of the task performed in step 26035 to the second LBA 2670.
  • a result eg, success or failure
  • selected SSP information generated in step 26035 may be transmitted together.
  • step 26035 The process of generating “selected SSP information” in step 26035 and the process of delivering “selected SSP information” in step 26040 may be omitted.
  • FIG. 27 is a diagram illustrating a procedure in which a transmission result of a bundle is registered in a server after the procedure shown in FIG. 26.
  • the terminal may include at least one LBA and at least one SSP.
  • the second terminal 2750 may include a second LBA 2770 and a second SSP 2760.
  • the second terminal 2750 may be a terminal equipped with a second SSP 2760 and a second LBA 2770 for controlling the second SSP 2760.
  • the server 2700 may be a server operated by a service provider, a bundle management server, a server operated by cooperation between a service provider and a bundle management server, or a service It may be any server operated in connection with the provider and/or the bundle management server.
  • SPBM which is one of the possible examples of a server, is sometimes used to refer to the server 2700, but as described above, the type of server is not limited to SPBM.
  • step 27000 a Transport Layer Security (TLS) connection may be established between the SPBM 2700 and the LBA 2770.
  • TLS Transport Layer Security
  • step 27000 may be performed independently from steps 27005 to 27015 before step 27020 is performed.
  • step 27000 may be performed between steps 27015 and 27020.
  • the second LBA 2770 may request “selected SSP information (SspInfoSelected)” from the second SSP 2 2760.
  • step 27005 may be performed automatically or may be performed after receiving an external input.
  • the'external input' may be given from a user through a UI provided by the second terminal 2750 or may be given to the second terminal 2750 through a push input from a remote server.
  • the second SSP 2760 may generate its own “selected SSP information”.
  • selected SSP information refer to the description described in FIG. 26.
  • the second SSP 2760 may transmit “selected SSP information” generated in step 27010 to the second LBA 2770.
  • Steps 27005 to 27015 may be omitted in some cases.
  • the second LBA 2770 may transmit “selected SSP information” to the server 2700. If the second LBA 2770 receives “selected SSP information” through steps 26035 to 26040 of FIG. 26, or receives “selected SSP information” through steps 27005 to 27015 of FIG. 27, the second LBA 2770 ) May transmit the received “selected SSP information” to the server 2700. If the second LBA 2770 has not received “selected SSP information”, the second LBA 2770 may generate “selected SSP information” and transmit it to the server 2700.
  • the server 2700 may check the received “selected SSP information” and generate “server authentication information (SPBM.Auth)” capable of authenticating itself based on this information. .
  • server authentication information SPBM.Auth
  • the server 2700 may check certificate information capable of verifying itself using the received "spbmVerification” and select at least one key agreement certificate (spbm.Cert.KA).
  • the server 2700 uses the received "list of key agreement algorithms supported by the second SSP 2760" to use the asymmetric encryption key pair public key "spbm.ePK.KA” to be used for key agreement. After creating the private key "spbm.eSK.KA", you can select the public key (spbm.ePK.KA) from this key pair.
  • the server 2700 may check certificate information capable of verifying itself using the received "spbmVerification” and further select at least one signing certificate (spbm.Cert.DS).
  • the server 2700 may check whether the certificate information of the first SSP 2610 to be verified by using the received "SenderSpblVerification" is verifiable by itself.
  • the server 2700 may check whether the certificate information of the second SSP 2760 to be verified by using the received “ReceiverSpblVerification” is verifiable by itself. Alternatively, after selecting at least one certificate information of the second SSP 2760 that can be verified by using “ReceiverSpblVerification”, the corresponding information may be set as “CiPkIdToBeUsed”.
  • the server 2700 may select at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 2760" and then set corresponding information to "CryptoToBeUsed”.
  • the server 2700 checks the list of the received "version information of the primary platform included in the second SSP 2760 and the standard standard supported by the loader", and among them, there is a version of the standard standard that it also supports. You can check whether it is.
  • Server authentication information includes at least one of “spbm.Cert.KA”, “spbm.ePK.KA”, “spbm.Cert.DS”, “CiPkIdToBeUsed", and “CryptoToBeUsed” described above. Can include.
  • server authentication information (SPBM.Auth)" mentioned above may be digitally signed so that it can be verified using spbm.Cert.DS to ensure the integrity of the information, and this digital signature data is It can be added as part of the "server authentication information".
  • the server 2700 may transmit “server authentication information (SPBM.Auth)” generated in step 27025 to the second SSP 2760 through the second LBA 2770.
  • SPBM.Auth server authentication information
  • the second SSP 2760 may verify the received "server authentication information (SPBM.Auth)". If, when the second SSP 2760 receives "spbm.Cert.KA”, it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2760 receives "spbm.Cert.DS”, it can check the validity of the certificate by checking the signature of the corresponding certificate. In addition, when the second SSP 2760 receives "spbm.ePK.KA” and a digital signature therefor, it verifies the digital signature using spbm.Cert.DS and the integrity of the received public key spbm.ePK.KA. can confirm. In addition, when the second SSP 2760 receives “CiPkIdToBeUsed”, it may check and select at least one signature certificate (ssp2.Cert.DS) capable of verifying itself.
  • SPBM.Auth server authentication information
  • the second SSP 2760 uses a public key "ssp2.ePK.KA” and a private key “ssp2.eSK.” as an asymmetric encryption key pair to be used for key agreement. After creating "KA”, you can select the public key (ssp2.ePK.KA) from this key pair. In addition, the second SSP 2760 selects one of the public key for key agreement or spbm.ePK.KA included in spbm.Cert.KA, and then communicates with the server in the future using this value and ssp2.eSK.KA. Session key ShKey03 to be used for middle encryption can be generated. ShKey03 must be the session key for the encryption algorithm contained in the received "CryptoToBeUsed”.
  • the second SSP 2760 may generate “terminal authentication information (Device.Auth)” capable of authenticating itself.
  • the "terminal authentication information (Device.Auth)” may include “ssp2.Cert.DS”.
  • the "terminal authentication information (Device.Auth)” may further include “ssp2.ePK.KA”.
  • the “terminal authentication information (Device.Auth)” may optionally further include “ssp1.Cert.DS”.
  • terminal authentication information (Device.Auth)” may include part and/or all of the finalizationRequest.
  • terminal authentication information (Device.Auth)” may include part and/or all of the finalizationResponse.
  • part or all of the “device authentication information (Device.Auth)” mentioned above may be digitally signed to be verified using ssp2.Cert.DS to ensure the integrity of the information, and this digital signature data may be digitally signed. It can be added as part of "terminal authentication information”.
  • part or all of the “terminal authentication information (Device.Auth)” may be encrypted using the previously generated session key ShKey03.
  • the second SSP 2760 may transmit “terminal authentication information (Device.Auth)” generated in step 27035 to the server 2700 through the second LBA 2770.
  • the server 2700 may verify the received "terminal authentication information (Device.Auth)".
  • the specific procedure of the verification process is as follows.
  • the server 2700 may verify the validity of the corresponding certificate by verifying the signature of the received "ssp1.Cert.DS” and/or "ssp2.Cert.DS".
  • the server 2700 may verify the signature of the received finalizationRequest and/or finalizationResponse.
  • the server 2700 may verify the contents of the received finalizationRequest and/or finalizationResponse.
  • the server 2700 may update the details of the bundle transmitted between devices based on the verified content. For example, the server 2700 may update a mapping relationship between the bundle and the first SSP 2610 to a mapping relationship between the bundle and the second SSP 2760.
  • the server 2700 receives the transmitted ssp2.ePK.KA and the key included in its spbm.Cert.KA.
  • a session key ShKey03 can be generated using a secret key corresponding to the consensus public key or spbm.eSK.KA, and the encrypted data can be decrypted using this session key, and then the verification process can be performed.
  • the server 2700 may generate a "certificate".
  • this certificate may be referred to as spbmAttestation.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • -spbmAttestation may include a "bundle separator" of the corresponding bundle in 1810 of FIG. 18.
  • some and/or all data of the finalizationRequest and/or finalizationResponse received in the previous step may be included.
  • -spbmAttestation may include an identifier of a server (eg, an identifier of a service provider and/or an identifier of a bundle management server and/or an address of a server) in 1830 of FIG. 18.
  • a server eg, an identifier of a service provider and/or an identifier of a bundle management server and/or an address of a server
  • -spbmAttestation may include information indicating that the server has confirmed the movement history of the bundle in 1850 of FIG. 18.
  • -spbmAttestation may optionally include a time when the server confirms the movement history of the bundle or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • -spbmAttestation may include the server's signature information in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a server's signature certificate.
  • step 27045 although not shown in Fig. 27, the server 2700 uses an asymmetric encryption key pair public key "spbm.attestation.ePK.KA” and a private key “spbm.attestation. eSK.KA” can be created.
  • the key pair "spbm.attestation.ePK.KA and spbm.attestation.eSK.KA” may be set to the same value as the previously created "spbm.ePK.KA and spbm.eSK.KA”.
  • the key pair "spbm.attestation.ePK.KA and spbm.attestation.eSK.KA” will be set to the same value as the previously used "public key included in spbm.Cert.KA and the corresponding private key”. May be.
  • the server 2700 may generate a session key ShKey04 using spbm.attestation.eSK.KA and ssp2.ePK.KA. If spbm.eSK.KA or the private key corresponding to the public key included in spbm.Cert.Ka is reused for spbm.attstation.eSK.KA, the value of the session key ShKey04 is also the value of the previously generated ShKey03. Can be set to a value.
  • step 27045 although not shown in FIG. 27, the server 2700 may configure “certificate verification data”.
  • "Certificate verification data” may include “spbm.Cert.DS”.
  • an electronic signature value of the server for "spbm.attestation.ePK.KA” and/or “spbm.attestation.ePK.KA” may be further included.
  • some and/or all of the “certificate” and “certificate verification data” generated in step 27045 may be encrypted using ShKey04.
  • the server 2700 may transmit “spbmAttestation” and “certificate verification data” generated in step 27045 to the second SSP 2760 through the second LBA 2770.
  • the second SSP 2760 may verify the received “spbmAttestaion” and/or “certificate verification data”. If the transmitted data includes encrypted data, the second SSP 2760 generates a session key ShKey04 using the transmitted spbm.attestation.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, you can perform verification. If the received data includes a digital signature, the second SSP 2760 may verify the validity of the digital signature using this certificate after verifying spbm.Cert.DS.
  • the second SSP 2760 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active) after completing the verification.
  • the second SSP 2760 may convert the state of the bundle to the Disabled state.
  • the second SSP 2760 may transmit the result of performing step 27060 to the second LBA 2770.
  • the second SSP 2760 may transmit the verification success or failure result of step 27060 to the second LBA 2770.
  • FIG. 28 is a diagram illustrating a configuration of a terminal according to an embodiment of the present disclosure.
  • the terminal may include a transceiver 2810 and at least one processor 2820.
  • the terminal may further include an SSP 2830.
  • the SSP 2830 may be inserted into the terminal or may be embedded in the terminal.
  • the at least one processor 2820 may also be referred to as a'control unit'.
  • the configuration of the terminal is not limited to FIG. 28, and may include more or fewer components than the components illustrated in FIG. 28.
  • the transmission/reception unit 2810, at least one processor 2820, and a memory may be implemented in the form of one chip.
  • the SSP 2830 when the SSP 2830 is embedded, it may be implemented in the form of a single chip, including the SSP 2830.
  • the transmission/reception unit 2810 may transmit and receive signals, information, and data according to various embodiments of the present disclosure with a transmission/reception unit of another terminal or an external server.
  • the transceiver 2810 may include an RF transmitter that up converts and amplifies a frequency of a transmitted signal, and an RF receiver that amplifies a received signal with low noise and down converts the frequency.
  • this is only an embodiment of the transmission/reception unit 2810, and components of the transmission/reception unit 2810 are not limited to the RF transmitter and the RF receiver.
  • the transmission/reception unit 2810 may receive a signal through a wireless channel, output it to the at least one processor 2820, and transmit a signal output from the at least one processor 2820 through a wireless channel.
  • the transmission/reception unit 2810 includes information on the SSP included in the other terminal from the transmission/reception unit of another terminal or an external server, authentication information for authenticating other terminals, authentication information for authenticating the server, and The authentication information capable of authenticating the data, a bundle movement code, a bundle movement setting, a bundle, and various certificates described in FIGS. 22 to 27 may be transmitted or received.
  • At least one processor 2820 is a component for overall control of the terminal.
  • the at least one processor 2820 may control the overall operation of the terminal according to various embodiments of the present disclosure as described above.
  • the SSP 2830 may include a processor or controller for installing and controlling a bundle, or may have an application installed.
  • At least one processor or controller in the SSP 2830 may determine whether to transmit a specific bundle by checking the bundle movement setting. In addition, it is possible to determine whether the bundle movement setting is checked and whether the result of the bundle movement between devices of the corresponding bundle should be registered in the server, or whether a notification is required if registration is required.
  • At least one processor or controller in the SSP may generate a bundle movement code to control a transmission process of a specific bundle.
  • At least one processor or controller in the SSP may generate its own SSP information, and may check and verify SSP information of another SSP transmitted from the outside.
  • At least one processor or controller in the SSP may generate authentication information capable of verifying itself, and may verify authentication information of another SSP transmitted from the outside.
  • the SSP 2830 may generate a bundle, and may install the bundle alone or in cooperation with one or more processors 2820. In addition, the SSP 2830 may manage the bundle.
  • the SSP 2830 may generate various types of certificates described in FIGS. 22 to 27 and verify the received certificates.
  • the SSP 2830 may change the state of the bundle based on the contents of the received certificate as described in FIGS. 22 to 27.
  • the SSP 2830 may operate under the control of the processor 2820.
  • the SSP 2830 may include a processor or controller for installing and controlling a bundle, or may have an application installed. Some or all of the applications may be installed in the SSP 2830 or a memory (not shown).
  • the terminal may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the terminal.
  • the memory is a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium.
  • the processor 2820 may perform various operations using various programs, contents, data, etc. stored in the memory.
  • the server may be a server operated by a service provider, a bundle management server, or a server operated by cooperation between a service provider and a bundle management server, or linked with a service provider and/or a bundle management server. It may be any server that is operated and operated.
  • the term "bundle management server”, which is one of the possible examples of servers, is used to refer to the server, but as described above, the type of server is not limited to the bundle management server.
  • the bundle management server may include a transceiver 2910 and at least one processor 2920.
  • the configuration of the bundle management server is not limited to FIG. 29, and may include more or fewer components than the components illustrated in FIG. 29.
  • the transmission/reception unit 2910, at least one processor 2920, and a memory may be implemented in the form of a single chip.
  • the transceiving unit 2910 may transmit and receive signals, information, and data according to various embodiments of the present disclosure to and from the terminal.
  • the transceiver 2910 may include an RF transmitter that up-converts and amplifies a frequency of a transmitted signal, and an RF receiver that amplifies a received signal with low noise and down-converts a frequency.
  • this is only an embodiment of the transmission/reception unit 2910, and components of the transmission/reception unit 2910 are not limited to the RF transmitter and the RF receiver.
  • the transceiver 2910 may receive a signal through a wireless channel, output it to the at least one processor 2920, and transmit a signal output from the at least one processor 2920 through a wireless channel.
  • At least one processor 2920 is a component for overall control of the bundle management server.
  • the processor 2920 may control the overall operation of the bundle management server according to various embodiments of the present disclosure as described above.
  • the at least one processor 2920 may be referred to as a control unit.
  • the bundle management server may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the bundle management server.
  • the memory is a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium.
  • the processor 2920 may perform various operations using various programs, contents, data, etc. stored in the memory.
  • FIG. 30 is a diagram illustrating another detailed procedure for a procedure in which transmission of a bundle is completed among the procedures presented in FIG. 19 and a procedure in which a transmission result of a bundle is registered in the server.
  • the terminal may include at least one LBA and at least one SSP.
  • the first terminal 3000 includes a first LBA 3020 and a first SSP 3010
  • the second terminal 3050 includes a second LBA 3070 and It may include a second SSP (3060).
  • the first terminal 3000 may be a terminal equipped with a first SSP 3010 and a first LBA 3020 for controlling the first SSP 3010
  • the second terminal 3050 2 It may be a terminal in which the SSP 3060 is mounted and the second LBA 3070 for controlling the second SSP 3060 is installed.
  • step 30000 the following procedures may be performed in step 30000.
  • the second LBA 3070 and the second SSP 3060 may cooperate with each other to install a bundle in the second terminal 3050.
  • the following procedures can be performed together. If metadata is transmitted, the second LBA 3070 or the second SSP 3060 may verify the contents included in the metadata. If "bundle movement setting" is transmitted, the second LBA 3070 may transmit the information to the second SSP 3060. If a transaction ID has been transmitted, the second LBA 3070 or the second SSP 3060 may check whether the transaction ID is the same as the transaction ID used in the current session.
  • the second LBA 3070 or the second SSP 3060 is It is possible to check whether the information matches the information of the bundle currently being received. If ssp1.Cert.DS is transmitted, the second SSP 3060 may verify the validity of this certificate to authenticate the first SSP 3010. If the transmitted data contains encrypted data, the second SSP 3060 generates a session key ShKey02 using the transmitted ssp1.bundle.ePK.KA and its ssp2.eSK.KA, and this session key. After decrypting the encrypted data using, you can perform verification. If the received data includes a digital signature, the second SSP 3060 may verify the validity of the digital signature using this certificate after verifying ssp1.Cer.DS.
  • the 2nd LBA 3070 and/or the 2nd SSP 3060 uses the "registration setting" of the corresponding bundle to'whether notification is necessary' and/or'whether or not pre-announcement is required' and/or You can check'whether the notification contents need to be encrypted.' This process is part of step 30000 and can be performed independently of other procedures in step 30000 and in any order. Or, after step 30000, before notification is made at 30040 or 30050, it may be performed at the moment when it is necessary to check the “registration setting” and make a decision.
  • the second SSP 3060 may set the state of a corresponding bundle to “IN TRANSITION”.
  • IN TRANSITION is a state in which the bundle has been successfully installed but cannot be used (also, a state that can be used only by an operation such as'request from the first terminal 3000' and/or'request from an external server' (Disabled, It can mean a state that can be changed to (Enable, Active state).
  • the second LBA 3070 may request a “certificate” from the second SSP 3060.
  • the second SSP 3060 may generate a “certificate”.
  • this certificate may be called finalizationRequest.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • the finalizationRequest may include the "bundle identifier" of the corresponding bundle in 510 of FIG. 18.
  • the finalizationRequest may include the "SSP identifier" of the second SSP in 530 of FIG. 18.
  • the finalizationRequest may include information indicating that the second SSP has set the bundle state to the “IN TRANSITION” state in 1850 of FIG. 18.
  • the finalizationRequest may selectively include a time when the second SSP sets the bundle state to the “IN TRANSITION” state in 1870 of FIG. 18 or a time when a certificate is created.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • the finalizationRequest may include signature information of the second SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • the second SSP 3060 may transmit a finalization Request to the first SSP 3010.
  • the second SSP 3060 may transmit a finalizationRequest to the first SSP 3010 through the following process. That is, the second SSP 3060 transmits a finalization Request to the second LBA 3070 in a response of step 30010, and the second LBA 3070 sends a finalization request to the first SSP 3010 through the first LBA 3020. I can deliver.
  • the first SSP 3010 may verify the received finalizationRequest.
  • This verification process may include checking the validity of the signature of the second SSP included in the finalizationRequest.
  • the verification process may further include a process of checking whether the "bundle identifier" included in the finalizationRequest matches the bundle identifier of the corresponding bundle.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the finalizationRequest is a correct identifier of the second SSP.
  • the verification process may further include a process of checking whether command information included in the finalizationRequest changes the state of the bundle to the “IN TRANSITION” state.
  • the first SSP 3010 may set the state of the corresponding bundle to "IN TRANSITION” after completing the verification.
  • "IN TRANSITION” is a state in which the bundle has been successfully installed but cannot be used (also, a state that can be used only by additional operations such as'request from the second terminal 3050' and/or'request from an external server' (Disabled , Enable, Active state).
  • the first SSP 3010 may generate a "certificate".
  • this certificate may be called finalizationResponse.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • the finalizationResponse may include a "bundle identifier" of a corresponding bundle in 510 of FIG. 18. Alternatively, it may include some and/or all data of the finalizationRequest received in the previous step.
  • the finalizationResponse may include the "SSP identifier" of the first SSP in 530 of FIG. 18.
  • the finalizationResponse may include information indicating that the first SSP has set the bundle state to the “IN TRANSITION” state in 1850 of FIG. 18.
  • the finalizationResponse may optionally include a time when the first SSP sets the bundle status to the “IN TRANSITION” state or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • the finalizationResponse may include signature information of the first SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the first SSP.
  • a first SSP 3010 may transmit a finalizationResponse to a second SSP 3060.
  • the first SSP 3010 may transmit a finalizationResponse to the second SSP 3060 through the first LBA 3020 and the second LBA 3070.
  • the second SSP 3060 may verify the received finalizationResponse.
  • This verification process may include checking the validity of the signature of the first SSP included in the finalizationResponse.
  • the verification process may optionally further include a process of checking whether the "bundle identifier" included in the finalizationResponse matches the bundle identifier of the corresponding bundle.
  • this verification process may include a process of checking whether some or all of the data of the finalizationRequest included in the finalizationResponse is consistent with the information transmitted by the finalizationResponse.
  • the verification process may further include a process of verifying the "SSP identifier" included in the finalizationResponse.
  • the verification process may further include a process of checking whether command information included in the finalizationResponse sets the state of the bundle to “IN TRANSITION”.
  • a pre-notification procedure may be performed in step 30040.
  • This procedure may be a procedure that is applied when it is set that a notification is required in "Registration Settings”. If a notice procedure is carried out, this procedure may be as follows.
  • the second SSP 3060 may generate sspInfoSelected and transmit this information to the second LBA 3070. This process may be omitted if necessary. In this case, the description of sspInfoSelected will be referred to the description of FIG. 26. Thereafter, of the procedure described in FIG. 27, a procedure before “a procedure of changing the state of the bundle to one of the available states (one of Disabled, Enable, and Active)” in step 27055 may be performed.
  • the second SSP 3060 may change the state of the bundle to one of the available states (one of Disabled, Enable, and Active). For example, as shown in the drawing, the second SSP 3060 may convert the state of the bundle to the Disabled state.
  • the second SSP 3060 may generate a "certificate".
  • this certificate may be called spblAttestation.
  • the structure of this certificate may follow the structure disclosed in FIG. 18.
  • -spblAttestation may include a "bundle separator" of a corresponding bundle in 510 of FIG. 18.
  • some and/or all data of'finalizationRequest and/or finalizationResponse and/or spbmAttestaion' may be included.
  • -spblAttestation may include “SSP identifier” of the second SSP in 530 of FIG. 18.
  • -spblAttestation may include information indicating that the second SSP has changed the bundle to one of the usable states in 1850 of FIG. 18.
  • -spblAttestation may optionally include a time when the second SSP changes the state of the bundle to one of the usable states or a time when a certificate is created in 1870 of FIG. 18.
  • information on a signing certificate used for an electronic signature to be described later and information on a certificate chain related thereto may be included.
  • -spblAttestation may include the signature information of the second SSP in 1890 of FIG. 18.
  • This signature may be signature information obtained by digitally signing the above-described information with a signature certificate of the second SSP.
  • a post-notification procedure may be performed. This procedure may be applied when it is set in “Registration Settings” that no notice is required. If a post-notification procedure is carried out, this procedure may be as follows.
  • the second SSP 3060 may generate sspInfoSelected and transmit this information to the second LBA 3070. This process may be omitted if necessary. In this case, the description of sspInfoSelected will be referred to the description of FIG. 22. Thereafter, the procedure described in FIG. 23 may be performed.
  • the second SSP 3060 may transmit spblAttestation to the second LBA 3070. Thereafter, the procedure described in FIG. 25 may be performed.
  • the second SSP 3060 may transmit spblAttestation to the first SSP 3010 through the second LBA 3070 and the first LBA 3020.
  • the first SSP 3010 may verify the received spblAttestation.
  • This verification process may include checking the validity of the signature of the second SSP included in the spblAttestation.
  • the verification process may further include a process of checking whether the "bundle separator" included in spblAttestation matches the bundle identifier of the corresponding bundle.
  • the verification process may further include a process of checking whether the "SSP identifier" included in the spblAttestation is a correct identifier of the second SSP.
  • the verification process may further include a process of checking whether command information included in spblAttestation sets the bundle status to one of the usable statuses.
  • the first SSP 3010 may delete the bundle.
  • step 30045 and/or step 30055 and/or step 30060 may be omitted as necessary.
  • the second terminal may repeatedly retransmit the notification to the server.
  • the retransmission process may be performed until this maximum value is satisfied according to the preset maximum number of retransmissions, or may be repeated until a response is received from the server.
  • the state of the bundle installed in the first terminal 3000 and/or the second terminal 3050 may be changed from “IN TRANSITION” to one of the usable states (eg, a disabled state).
  • module used in the present disclosure includes a unit composed of hardware, software, or firmware, and may be used interchangeably with terms such as, for example, logic, logic blocks, parts, or circuits.
  • the module may be an integrally configured component or a minimum unit that performs one or more functions, or a part thereof.
  • the module may be configured as an application-specific integrated circuit (ASIC).
  • ASIC application-specific integrated circuit
  • Various embodiments of the present disclosure are software (eg, programs) including instructions stored in a machine-readable storage media (eg, internal memory or external memory) that can be read by a machine (eg, a computer).
  • a machine eg, a computer
  • the device is a device capable of calling a stored command from a storage medium and operating according to the called command, and may include a terminal according to various embodiments.
  • the processor may perform a function corresponding to the command directly or by using other components under the control of the processor.
  • Instructions may include code generated or executed by a compiler or interpreter.
  • a storage medium that can be read by a device may be provided in the form of a non-transitory storage medium.
  • non-transient means that the storage medium does not contain a signal and is tangible, but does not distinguish between semi-permanent or temporary storage of data in the storage medium.
  • a method according to various embodiments disclosed in the present disclosure may be provided in a computer program product.
  • Computer program products can be traded between sellers and buyers as commodities.
  • the computer program product may be distributed online in the form of a device-readable storage medium (eg, compact disc read only memory (CD-ROM)) or through an application store (eg, Play StoreTM).
  • CD-ROM compact disc read only memory
  • application store eg, Play StoreTM
  • at least some of the computer program products may be temporarily stored or temporarily generated in a storage medium such as a server of a manufacturer, a server of an application store, or a memory of a relay server.
  • Each of the constituent elements may be composed of singular or plural entities, and some sub-elements of the aforementioned sub-elements are omitted, or other sub-elements are various. It may be further included in the embodiment.
  • some constituent elements eg, a module or a program
  • functions performed by each corresponding constituent element prior to the consolidation may be performed identically or similarly.
  • Operations performed by modules, programs, or other components according to various embodiments may be sequentially, parallel, repetitively or heuristically executed, or at least some operations may be executed in a different order, omitted, or other operations may be added. I can.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 본 개시는 스마트 보안 매체 간에 번들이 전송된 후 번들의 상태를 설정하기 위한 방법 및 장치를 기술한다.

Description

기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치
본 개시는 스마트 보안 매체에 관한 것으로, 보다 상세하게는, 스마트 보안 매체 간 번들 이동이 이루어진 후 번들의 상태를 설정하는 방법 및 장치에 관한 것이다.
본 개시는 스마트 보안 매체에 관한 것으로, 보다 상세하게는, 스마트 보안 매체 간 번들 이동이 이루어진 후 번들 이동 결과를 서버에 등록하는 방법 및 장치에 관한 것이다.
4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE 시스템 이후 (Post LTE) 시스템이라 불리어지고 있다. 높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역 (예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(Full Dimensional MIMO: FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나 (large scale antenna) 기술들이 논의되고 있다. 또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀 (advanced small cell), 클라우드 무선 액세스 네트워크 (cloud radio access network: cloud RAN), 초고밀도 네트워크 (ultra-dense network), 기기 간 통신 (Device to Device communication: D2D), 무선 백홀 (wireless backhaul), 이동 네트워크 (moving network), 협력 통신 (cooperative communication), CoMP (Coordinated Multi-Points), 및 수신 간섭제거 (interference cancellation) 등의 기술 개발이 이루어지고 있다. 이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM (Hybrid FSK and QAM Modulation) 및 SWSC (Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC(Filter Bank Multi Carrier), NOMA(non orthogonal multiple access), 및SCMA(sparse code multiple access) 등이 개발되고 있다.
한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT(Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터(Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 연구되고 있다. IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크(cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.
개시된 실시 예는 두 전자 장치에 포함된 보안 모듈 사이에 번들을 이동하는 경우 번들 전송이 이루어진 후 번들의 상태를 설정하는 장치 및 방법을 제공하는 것이다.
또한, 개시된 실시 예는 두 전자 장치에 포함된 보안 모듈 사이에 번들을 이동하는 경우 번들 전송이 이루어진 후 번들의 전송 결과를 서버에 등록하는 장치 및 방법을 제공하는 것이다.
상기와 같은 문제점을 해결하기 위한 본 발명은 제1 단말의 동작 방법에 있어서, 제2 단말로, 번들을 전송하는 단계; 상기 제2 단말로부터, 제2 단말의 번들 상태 정보를 포함하여 생성된 제1 증명서를 수신하는 단계; 상기 수신된 제1 증명서를 검증하는 단계; 상기 제1 증명서를 검증한 후, 제1 단말의 번들 상태 정보를 포함하는 제2 증명서를 생성하는 단계; 및 상기 제2 단말로 상기 제2 증명서를 전송하는 단계를 포함하는 것을 특징으로 한다.
일부의 예들에서는, 상기 제1 단말의 번들 상태 정보는 상기 제1 단말의 번들 상태가 DELETE, IN TRANSITION, SUSPENSION 중 적어도 하나로 설정되는 것을 포함하는 것을 특징으로 한다.
일부의 예들에서는, 상기 제1 단말의 번들 상태가 IN TRANSITION 로 설정된 경우, 상기 제2 단말로부터 제2 단말의 번들 상태 변경에 대한 정보를 포함하여 생성된 제3 증명서를 수신하는 단계; 상기 수신된 제3 증명서를 검증하는 단계; 및 상기 제3 증명서를 검증한 후, 상기 제1 단말의 번들을 삭제(DELETE)하는 단계를 더 포함하는 것을 특징으로 한다.
일부의 예들에서는, 상기 제2 단말에 의해, 상기 제1 증명서 및 상기 제2 증명서의 검증 결과에 대한 정보를 포함하는 제4 증명서가 생성되고, 상기 제4 증명서가 서버로 전송되고, 및 상기 서버에 의해, 상기 제4 증명서는 검증되는 것을 특징으로 한다.
일부의 예들에서는, 서버에 의해, 상기 서버와의 인증 결과를 포함하는 제5 증명서가 생성되고, 상기 제5 증명서는 상기 제2 단말로 전송되고, 및 상기 제2 단말에 의해, 상기 제5 증명서는 검증되는 것을 특징으로 한다.
본 발명의 다른 예에서는, 제2 단말의 동작 방법에 있어서, 제1 단말로부터, 번들을 수신하는 단계; 상기 번들을 설치하는 단계; 제2 단말의 번들 상태 정보를 포함하는 제1 증명서를 생성하는 단계; 상기 제1 단말로, 상기 제1 증명서를 전송하는 단계; 상기 제1 단말로부터, 제1 단말의 번들 상태 정보를 포함하여 생성된 제2 증명서를 수신하는 단계; 상기 수신된 제2 증명서를 검증하는 단계; 및 상기 제2 증명서를 검증한 후, 제2 단말의 번들 상태 설정 정보를 변경하는 단계를 포함하는 것을 특징으로 하는 한다.
또 다른 예들에서는, 제1 단말에 있어서, 적어도 하나의 신호를 송수신을 할 수 있는 송수신부; 및 상기 송수신부와 결합된 제어부를 포함하고, 상기 제어부는 : 제2 단말로, 번들을 전송하고, 상기 제2 단말로부터, 제2 단말의 번들 상태 정보를 포함하여 생성된 제1 증명서를 수신하고, 상기 수신된 제1 증명서를 검증하고, 상기 제1 증명서를 검증한 후, 제1 단말의 번들 상태 정보를 포함하는 제2 증명서를 생성하고, 그리고 상기 제2 단말로 상기 제2 증명서를 전송하도록 구성되는 것을 특징으로 한다.
또 다른 예들에서는, 제2 단말에 있어서, 적어도 하나의 신호를 송수신을 할 수 있는 송수신부; 및 상기 송수신부와 결합된 제어부를 포함하고, 상기 제어부는 : 제1 단말로부터, 번들을 수신하고, 상기 번들을 설치하고, 제2 단말의 번들 상태 정보를 포함하는 제1 증명서를 생성하고, 상기 제1 단말로, 상기 제1 증명서를 전송하고, 상기 제1 단말로부터, 제1 단말의 번들 상태 정보를 포함하여 생성된 제2 증명서를 수신하고, 상기 수신된 제2 증명서를 검증하고, 그리고 상기 제2 증명서를 검증한 후, 제2 단말의 번들 상태 설정 정보를 변경하도록 구성되는 것을 특징으로 한다.
본 개시의 다양한 실시 예에 따르면, 한 기기에 설치되었던 번들은 안전하고 효율적인 방법으로 다른 기기로 전송 및 설치될 수 있고, 전송 및 설치를 마친 후 번들의 상태가 설정될 수 있다.
또한, 본 개시의 다양한 실시 예에 따르면, 한 기기에 설치되었던 번들은 안전하고 효율적인 방법으로 다른 기기로 전송 및 설치될 수 있고, 전송 및 설치를 마친 후 번들의 전송 결과가 서버에 등록될 수 있다.
도 1은 본 개시의 실시 예에 따른 SSP의 개념도를 나타낸다.
도 2는 본 개시의 실시 예에 따른 SSP의 내부 구조에 대한 개념도를 나타낸다.
도 3은 본 개시의 실시 예에 따른 단말이 SSP로 번들을 다운로드하고 설치하기 위해 사용되는 단말 내 구성 요소의 예를 도시하는 도면이다.
도 4는 본 개시의 실시 예에 따른 두 단말 사이에서 번들의 전송이 이루어지기 위해 두 단말이 상호 동작하는 방법의 예를 도시하는 도면이다.
도 5는 본 개시의 일부 실시 예에 따른 "증명서(Attestaion)"의 구성을 도시하는 도면이다.
도 6은 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 번들이 전송되는 절차를 개념적으로 도시하는 도면이다.
도 7은 도 6에서 제시된 절차 중 번들 전송을 위해 준비하는 절차에 대한 세부 절차를 도시하는 도면이다.
도 8은 도 6에서 제시된 절차 중 번들의 전송이 이루어지는 절차에 대한 세부 절차를 도시하는 도면이다.
도 9는 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 세부 절차를 도시하는 도면이다.
도 10은 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다.
도 11은 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다.
도 12는 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다.
도 13은 사용이 중지되었던 번들을 다시 사용 가능하도록 만드는 절차의 예를 도시하는 도면이다.
도 14는 사용이 중지되었던 번들을 다시 사용 가능하도록 만드는 또 다른 절차의 예를 도시하는 도면이다.
도 15는 사용이 중지되었던 번들을 다시 사용 가능하도록 만드는 또 다른 절차의 예를 도시하는 도면이다.
도 16은 본 개시의 일부 실시 예에 따른 단말의 구성을 도시하는 도면이다.
도 17은 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다.
도 18은 본 개시의 일부 실시 예에 따른 "증명서(Attestaion)"의 구성을 도시하는 도면이다.
도 19는 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 번들이 전송되는 절차를 개념적으로 도시하는 도면이다.
도 20은 도 19에서 제시된 절차 중 번들 전송을 위해 준비하는 절차에 대한 세부 절차를 도시하는 도면이다.
도 21은 도 19에서 제시된 절차 중 번들의 전송이 이루어지는 절차에 대한 세부 절차를 도시하는 도면이다.
도 22는 도 19에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 세부 절차를 도시하는 도면이다.
도 23는 도 22에서 제시된 절차 후, 번들의 전송 결과가 서버에 등록되는 절차를 도시하는 도면이다.
도 24는 도 19에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다.
도 25는 도 24에서 제시된 절차 후, 번들의 전송 결과가 서버에 등록되는 절차를 도시하는 도면이다.
도 26은 도 19에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다.
도 27은 도 26에서 제시된 절차 후, 번들의 전송 결과가 서버에 등록되는 절차를 도시하는 도면이다.
도 28은 본 개시의 일부 실시 예에 따른 단말의 구성을 도시하는 도면이다.
도 29는 본 개시의 일부 실시 예에 따른 서버의 구성을 도시하는 도면이다.
도 30은 도 19에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차 및 번들의 전송 결과가 서버에 등록되는 절차를 도시하는 도면이다.
이하에서는 본 개시의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
실시 예를 설명함에 있어서 본 개시가 속하는 기술 분야에 익히 알려져 있고 본 개시와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 개시의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성한다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA 또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.
또한, 본 개시에서는 SSP를 보안 매체의 일 예로 들어 각 실시예들을 설명하지만, 본 발명의 권리범위가 SSP에 의한 것으로 제한되지는 않는다. 예를 들면, SSP와 실질적으로 동일 또는 유사한 기능을 수행하는 다른 보안 매체에도, 이하 설명할 다양한 실시예들이 실질적으로 동일 또는 유사하게 적용될 수 있음은 해당 기술분야의 통상의 기술자들에게 자명하다.
이하의 설명에서 사용되는 특정 용어들은 본 개시의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 개시의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
"SE(Secure Element)"는 보안 정보(예: 이동통신망 접속 키, 신분증/여권 등의 사용자 신원확인 정보, 신용카드 정보, 암호화 키 등)를 저장하고, 저장된 보안 정보를 이용하는 제어 모듈(예: USIM 등의 망 접속 제어 모듈, 암호화 모듈, 키 생성 모듈 등)을 탑재하고 운영할 수 있는 단일 칩으로 구성된 보안 모듈을 의미한다. SE는 다양한 전자 장치(예: 스마트폰, 태블릿, 웨어러블 장치, 자동차, IoT 장치 등)에 사용될 수 있으며, 보안 정보와 제어 모듈을 통해 보안 서비스(예: 이통통신 망 접속, 결제, 사용자 인증 등)를 제공할 수 있다.
SE는 UICC(Universal Integrated Circuit Card), eSE (Embedded Secure Element), UICC와 eSE가 통합된 형태인 SSP(Smart Secure Platform)등으로 나뉠 수 있으며, 전자 장치에 연결 또는 설치되는 형태에 따라 탈착식(Removable), 고정식(Embedded), 그리고 특정 소자 또는 SoC(system on chip)에 통합되는 통합식(Integrated)으로 세분화 될 수 있다.
"UICC(Universal Integrated Circuit Card)"는 이동 통신 단말기 등에 삽입하여 사용하는 스마트카드(smart card)이고 UICC 카드라고도 지칭될 수 있다. UICC에는 이동통신사업자의 망에 접속하기 위한 접속 제어 모듈이 포함될 수 있다. 접속 제어 모듈의 예로는 USIM(Universal Subscriber Identity Module), SIM(Subscriber Identity Module), ISIM(IP Multimedia Service Identity Module) 등이 있다. USIM이 포함된 UICC를 통상 USIM 카드라고 부르기도 한다. 마찬가지로 SIM 모듈이 포함된 UICC를 통상적으로 SIM카드라고 부르기도 한다. 한편, SIM 모듈은 UICC 제조시 탑재되거나 사용자가 원하는 시점에 사용하고자 하는 이동통신 서비스의 SIM 모듈을 UICC 카드에 다운로드 받을 수 있다. UICC 카드는 또한 복수개의 SIM 모듈을 다운로드 받아서 설치하고 그 중의 적어도 한 개의 SIM 모듈을 선택하여 사용할 수 있다. 이러한 UICC 카드는 단말에 고정하거나 고정하지 않을 수 있다. 단말에 고정하여 사용하는 UICC를 eUICC(embedded UICC)라고 하며, 특히 단말의 통신 프로세서(Communication Processor), 어플리케이션 프로세서(Application Processor) 또는 이 두 프로세서가 통합된 단일 프로세서 구조를 포함하는 System-On-Chip(SoC)에 내장된 UICC를 iUICC(Integrated UICC)라고 지칭될 수 있다. 통상적으로 eUICC와 iUICC는 단말에 고정하여 사용하고, 원격으로 SIM 모듈을 다운로드 받아서 선택할 수 있는 UICC 카드를 의미할 수 있다. 본 개시에서는 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드를 eUICC 또는 iUICC로 통칭한다. 즉 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하거나 고정하지 않는 UICC 카드를 통칭하여 eUICC 또는 iUICC로 사용한다. 또한 다운로드 받는 SIM 모듈정보를 통칭하여 eUICC 프로파일 또는 iUICC 프로파일, 또는 더 간단히 프로파일 이라는 용어로 사용한다.
본 개시에서 용어 UICC는 SIM과 혼용될 수 있고, 용어 eUICC는 eSIM과 혼용될 수 있다. 또한 본 개시에서 USIM Profile(USIM Profile)은 프로파일과 동일한 의미 또는 프로파일 내 USIM 어플리케이션에 포함된 정보를 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.
"eSE(Embedded Secure Element)"는 전자 장치에 고정하여 사용하는 고정식 SE를 의미한다. eSE는 통상적으로 단말 제조사의 요청에 의해 제조사 전용으로 제조되며, 운영체제와 프레임워크를 포함하여 제조 될 수 있다. eSE는 원격으로 애플릿 형태의 서비스 제어 모듈을 다운받아 설치하고 전자지갑, 티켓팅, 전자여권, 디지털키 등과 같은 다양한 보안 서비스 용도로 사용될 수 있다. 본 개시에서는 원격으로 서비스 제어 모듈을 다운로드 받아 설치할 수 있는 전자 장치에 부착된 단일 칩 형태의 SE를 eSE로 통칭한다.
"SSP(Smart Secure Platform)"은 UICC와 eSE의 기능을 단일 칩에서 통합 지원이 가능한 것으로, 탈착식(rSSP, Removable SSP), 고정식(eSSP, Embedded SSP) 그리고 SoC에 내장된 통합식(iSSP, Integrated SSP)로 구분 될 수 있다. SSP는 하나의 프라이머리 플랫폼(PP, Primary Platform)과 PP상에서 동작하는 적어도 하나의 세컨더리 플랫폼 번들(SPB, Secondary Platform Bundle)을 포함할 수 있으며, 프라이머리 플랫폼은 하드웨어 플랫폼과 low level Operating System(LLOS)을 중 적어도 하나를 포함할 수 있고, 세컨더리 플랫폼 번들은 High-level Operating System(HLOS) 및 HLOS 위에서 구동되는 애플리케이션 중 적어도 하나를 포함할 수 있다. 세컨더리 플랫폼 번들은 SPB 또는 번들이라고 불리기도 한다. 번들은 PP가 제공하는 Primary Platform Interface (PPI)를 통해 PP의 중앙처리장치, 메모리 등의 자원에 접근하고 이를 통해 PP상에서 구동될 수 있다. 번들에는 SIM(Subscriber Identification Module), USIM(Universal SIM), ISIM(IP Multimedia SIM)등의 통신 어플리케이션이 탑재될 수 있으며, 또한 전자지갑, 티켓팅, 전자여권, 디지털 키 등과 같은 다양한 응용 어플리케이션이 탑재될 수 있다. 본 개시에서 SSP는 스마트 보안 매체로 명명될 수도 있다.
SSP는 다운로드 되고 설치되는 번들에 따라서 상기 기술된 UICC 또는 eSE 용도로 사용될 수 있으며, 복수개의 번들을 단일 SSP에 설치하고 동시에 운영하여 UICC와 eSE의 용도를 혼용할 수 있다. 즉, 프로파일을 포함하는 번들이 동작하는 경우 SSP는 이동통신사업자의 망에 접속하기 위한 UICC 용도로 사용 될 수 있다. 해당 UICC 번들은 상기 eUICC 또는 iUICC와 같이 적어도 하나 이상의 프로파일을 원격에서 번들 내로 다운로드 받아 선택하여 동작할 수 있다. 또한, SSP상에서 전자지갑, 티켓팅, 전자여권 또는 디지털키 등의 서비스를 제공할 수 있는 응용 어플리케이션을 탑재한 서비스 제어 모듈을 포함하는 번들이 동작하는 경우 SSP는 상기 eSE의 용도로 사용될 수 있다. 다수의 서비스 제어 모듈은 하나의 번들에 통합되어 설치되고 동작하거나, 각기 독립적인 번들로 설치되고 동작할 수 있다.
SSP는 OTA(Over The Air)기술을 이용하여 외부의 번들 관리 서버(Secondary Platform Bundle Manager, SPB Manager)로부터 번들을 다운 받아 설치할 수 있고, 또 다른 단말로부터 번들을 전송 받아 설치할 수도 있다. 본 개시에서 다운 혹은 전송 받은 번들을 설치하는 방법은 단말에 삽입 및 탈거가 가능한 착탈식 SSP(rSSP), 단말에 설치되는 고정식 SSP(eSSP), 단말에 설치되는 SoC내부에 포함되는 통합식 SSP(iSSP)에 동일하게 적용될 수 있다.
"SSP 식별자(SSP ID)"는, 단말에 내장된 SSP의 고유 식별자로서 sspID로 지칭될 수 있다. 또한 본 개시의 실시 예에서와 같이 단말과 SSP 칩이 분리되지 않을 경우에는 단말 ID일 수 있다. 또한, SSP 내의 특정한 번들 식별자(SPB ID)를 지칭할 수도 있다. 좀더 자세히는 SSP에서 다른 번들을 설치하고 활성화, 비활성화, 삭제를 관리하는 관리 번들 또는 로더(SPBL, Secondary Platform Bundle Loader)의 번들 식별자를 지칭 할 수도 있다. 또한, SSP 내에 있는 프라이머리 플랫폼의 아이디(Primary Platform Identifier)를 지칭할 수도 있다. SSP는 복수개의 SSP 식별자를 가질 수도 있으며, 복수개의 SSP 식별자는 고유한 단일의 SSP 식별자로부터 유도된 값일 수 있다.
"SPB(Secondary Platform Bundle)"은 SSP의 프라이머리 플랫폼(PP, Primary Plaform) 상에서 PP의 리소스를 사용하여 구동되는 것으로 예를 들면 UICC 번들은 기존 UICC 내에 저장되는 어플리케이션, 파일시스템, 인증키 값 등과 이들이 동작하는 운영체체(HLOS)를 소프트웨어 형태로 패키징 한 것을 의미할 수 있다. 본 개시에서, SPB는 번들로 지칭될 수 있다.
본 개시에서 단말의 "상태"는 다음과 같을 수 있다.
[활성화(enable)]
본 개시에서 단말 또는 외부 서버가 번들을 활성화(enable)하는 동작은, 해당 SPB의 상태를 활성화 상태(enabled)로 변경하여 단말이 해당 번들이 제공하는 서비스(예: 통신사업자를 통해 통신서비스, 신용카드 결제 서비스, 사용자 인증 서비스 등)를 받을 수 있도록 설정하는 동작을 의미할 수 있다. 활성화 상태의 번들은 "활성화된 번들 (enabled Bundle)"로 표현될 수 있다. 활성화 상태의 번들은 SSP 내부 또는 외부의 저장공간에 암호화된 상태로 저장되어 있을 수 있다.
[구동 상태(Active)]
본 개시에서 활성화된 번들은 번들 외부 입력(예: 사용자 입력, 푸쉬, 단말 내 어플리케이션의 요청, 통신 사업자의 인증 요청, PP 관리 메시지 등) 또는 번들 내부의 동작(예: 타이머, Polling)에 따라 구동 상태(Active)로 변경될 수 있다. 구동 상태의 번들은 SSP 내부 또는 외부의 저장공간에서 SSP 내부의 구동 메모리에 로딩되고 SSP 내부의 보안 제어 장치 (Secure CPU)를 이용하여 보안 정보를 처리하고 단말에 보안 서비스를 제공하는 것을 의미할 수 있다.
[비활성화(Disabled)]
본 개시에서 단말 또는 외부 서버가 번들을 비활성화(disable)하는 동작은, 해당 번들의 상태를 비활성화 상태(disabled)로 변경하여 단말이 해당 번들이 제공하는 서비스를 받을 수 없도록 설정하는 동작을 의미할 수 있다. 비활성화 상태의 SPB는 "비활성화된 번들(disabled Bundle)"로 표현될 수 있다. 비활성화 상태의 번들은 SSP 내부 또는 외부의 저장공간에 암호화된 상태로 저장되어 있을 수 있다.
[삭제(Deleted)]
본 개시에서 단말 또는 외부 서버가 번들을 삭제(delete)하는 동작은, 해당 번들의 상태를 삭제 상태(deleted)로 변경하거나 해당 번들을 포함한 해당 번들의 관련 데이터를 삭제하여 단말 또는 외부 서버가 더 이상 해당 번들을 구동, 활성화 또는 비활성화할 수 없도록 설정하는 동작을 의미할 수 있다. 삭제 상태의 번들은 "삭제된 번들(deleted Bundle)"로 표현될 수 있다.
"번들 이미지(Bundle Image, 또는 Image)"는 번들과 혼용되거나 특정 번들의 데이터 객체(data object)를 나타내는 용어로 사용될 수 있으며, 번들 TLV 또는 번들 이미지 TLV(Bundle Image TLV)로 명명될 수 있다. 번들 이미지가 암호화 파라미터를 이용해 암호화된 경우 보호된 번들 이미지 (Protected Bundle Image(PBI)) 또는 보호된 번들 이미지 TLV (PBI TLV)로 명명될 수 있다. 번들 이미지가 특정 SSP에 의해서만 복호화 가능한 암호화 파라미터를 이용해 암호화된 경우 묶인 번들 이미지(Bound Bundle Image(BBI)) 또는 묶인 번들 이미지 TLV(BBI TLV)로 명명될 수 있다. 번들 이미지 TLV는 TLV(Tag, Length, Value) 형식으로 번들을 구성하는 정보를 표현하는 데이터 세트(set) 일 수 있다.
"번들 구분자"는 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID), 번들 Matching ID, 이벤트 식별자(Event ID)와 매칭되는 인자로 지칭될 수 있다. 번들 식별자(SPB ID)는 각 번들의 고유 식별자를 나타낼 수 있다. 번들 패밀리 식별자는 번들 (예를 들어, 이동통신사 망 접속을 위한 텔레콤 번들)의 종류를 구분하는 식별자를 나타낼 수 있다. 본 개시에서 번들 패밀리 식별자는 Famaily ID, Fid 또는 FID로 지칭될 수 있다. 번들 패밀리 관리자 식별자는 번들 패밀리 식별자를 관리하는 주체 (예를 들어, 통신사업자, 단말제조사, 특정 단체 등)를 구분하는 식별자를 나타낼 수 있다. 본 개시에서 번들 패밀리 관리자 식별자는 OID 또는 Oid로 지칭될 수 있다. 번들 구분자는 번들 관리 서버 혹은 단말에서 번들을 색인할 수 있는 값으로 사용될 수 있다.
"번들 메타데이터"는 번들을 지칭 혹은 기술할 수 있는 정보의 집합을 나타내는 용어이다. 번들 메타데이터는 상기에 기술한 번들 구분자를 포함할 수 있다. 또한 번들 메타데이터는 번들의 속성이나 특성, 혹은 설정에 대한 정보를 더 포함할 수 있다. 번들 메타데이터는 "메타데이터"라 표현될 수 있다.
"번들 관리서버"는 서비스 제공자(Service Provider) 또는 다른 번들 관리서버의 요청에 의해 번들을 생성하거나, 생성된 번들을 암호화 하거나, 번들 원격관리 명령어를 생성하거나, 생성된 번들 원격관리 명령어를 암호화하는 기능을 포함할 수 있다. 상기 기능을 제공하는 번들 관리서버는 SPBM (Secondary Platform Bundle Manager), RBM(Remote Bundle Manager), IDS(Image Delivery Server), SM-DP(Subscription Manager Data Preparation), SM-DP+(Subscription Manager Data Preparation plus), 관리자 번들 서버, Managing SM-DP+(Managing Subscription Manager Data Preparation plus), 번들 암호화 서버, 번들 생성서버, 번들 제공자(Bundle Provisioner, BP), 번들 공급자(Bundle Provider), BPC holder(Bundle Provisioning Credentials holder) 중 적어도 하나로 표현될 수 있다.
본 개시에서 번들 관리서버는 SSP에서 번들을 다운로드, 설치 또는 업데이트하고 번들의 상태를 원격 관리하기 위한 키 및 인증서를 설정을 관리하는 역할을 수행할 수 있다. 상기 기능을 제공하는 번들 관리 서버는 SPBM(Secondary Platform Bundle Manager), RBM(Remote Bundle Manager), IDS(Image Delivery Server), SM-SR(Subscription Manager Secure Routing), SM-SR+(Subscription Manager Secure Routing Plus), off-card entity of eUICC Profile Manager 또는 PMC holder(Profile Management Credentials holder), EM(eUICC Manager) 중 적어도 하나로 표현될 수 있다.
본 개시에서 개통중개서버는 하나 이상의 번들 관리서버 내지 개통중개서버로부터 이벤트 등록 요청(Register Event Request, Event Register Request)을 수신할 수 있다. 또한 하나 이상의 개통중개서버가 복합적으로 사용될 수 있으며, 이 경우 제1 개통중개서버는 번들 관리서버뿐만 아니라 제2 개통중개서버로부터 이벤트 등록 요청을 수신할 수도 있다. 본 개시에서 개통중개서버의 기능은 번들 관리서버에 통합될 수 있다. 상기 기능을 제공하는 개통중개서버는 SPBM(Secondary Platform Bundle Manager), RBM(Remote Bundle Manager), SPBDS(Secondary Platform Bundle Discovery Sever), BDS(Bundle Discovery Sever), SM-DS(Subscription Manager Discovery Service), DS(Discovery Service), 근원개통중개서버(Root SM-DS), 대체개통중개서버(Alternative SM-DS) 중 적어도 하나로 표현될 수 있다.
본 개시에서 번들 관리서버는 번들 또는 번들 원격 관리 명령어를 생성하고 암호화 하여 전달하는 기능과 SSP의 설정 및 설치된 번들을 관리하는 기능을 합친 것을 통칭하는 것일 수도 있다. 또한 개통중개서버 기능을 합친 것을 통칭하는 것 일 수도 있다. 따라서 이하 본 개시의 다양한 실시 예에서 번들 관리서버 및 개통 중개서버의 동작은 하나의 번들 관리서버에서 이루어질 수도 있다. 또한 각 기능은 서로 분리된 다수의 번들 관리 서버에서 나누어 수행될 수도 있다. 또한, 본 개시의 명세서에서 번들 관리서버 또는 개통중개서버는 번들 서버로 표현될 수 있다. 번들 서버는 번들 관리서버, 개통중개서버 중 하나 일 수 있고 번들 관리서버와 개통중개서버 모두 포함하는 장치일 수도 있다.
"서비스 제공자(Service Provider)"는 번들 관리서버에 요구사항을 발행하여 번들 생성을 요청하고, 해당 번들을 통해 단말에 서비스를 제공하는 사업체를 나타낼 수 있다. 예를 들면, 통신 어플리케이션이 탑재된 번들을 통해 통신망 접속 서비스를 제공하는 통신사업자(Mobile Operator)를 나타낼 수 있으며, 통신사업자의 사업지원시스템(Business Supporting System, BSS), 운영지원시스템(Operational Supporting System, OSS), POS 단말(Point of Sale Terminal), 그리고 기타 IT 시스템을 모두 통칭할 수 있다. 또한 본 개시에서 서비스 제공자는 특정 사업체를 하나만 표현하는데 한정되지 않고, 하나 이상의 사업체의 그룹 또는 연합체(association 또는 consortium) 내지 해당 그룹 또는 연합체를 대표하는 대행사(representative)를 지칭하는 용어로 사용될 수도 있다. 또한 본 개시에서 서비스 제공자는 사업자(Operator 또는 OP 또는 Op.), 번들 소유자(Bundle Owner, BO), 이미지 소유자(Image Owner, IO) 등으로 명명될 수 있으며, 각 서비스 제공자는 이름 그리고/또는 고유 식별자(Object Identifier, OID)를 적어도 하나 이상 설정하거나 할당 받을 수 있다. 만일 서비스 제공자가 하나 이상의 사업체의 그룹 또는 연합체 또는 대행사를 지칭하는 경우, 임의의 그룹 또는 연합체 또는 대행사의 이름 또는 고유 식별자는 해당 그룹 또는 연합체에 소속한 모든 사업체 내지 해당 대행사와 협력하는 모든 사업체가 공유하는 이름 또는 고유 식별자일 수 있다.
"가입자(Subscriber)"는 단말에 대한 소유권을 지닌 서비스 공급자(Service Provider)를 지칭하거나, 단말에 대한 소유권을 가지고 있는 사용자(End User)를 지칭하는 용어로 사용될 수 있다. 일반적으로 전자는 M2M 단말(M2M Device)로, 후자는 사용자 단말(Consumer Device)로 명명될 수 있다. M2M 단말의 경우 단말에 대한 소유권을 지니지는 않았으나 서비스 공급자(Service Provider)로 부터 단말을 양도 또는 임대 받아 사용하는 사용자(End User)가 존재할 수 있고, 이 경우 사용자는 서비스 공급자와 다르거나 같을 수도 있다.
"가입자 의도(Subscriber intent)"는 가입자가 번들을 로컬관리 또는 원격관리하고자 하는 의도를 통칭하는 용어로 사용될 수 있다. 또한 로컬관리의 경우 가입자 의도는 사용자 의도(End User intent)를 지칭하고, 원격관리의 경우 가입자 의도는 서비스 공급자 의도(Service Provider intent)를 지칭하는 용어로 사용될 수도 있다.
"사용자 동의(End User consent)"는 사용자가 로컬관리 내지 원격관리의 수행에 동의하는지를 지칭하는 용어로 사용될 수 있다.
'단말'은 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말의 다양한 실시 예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있다. 또한, 단말은 M2M(Machine to Machine) 단말, MTC(Machine Type Communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 개시에서 단말은 전자장치라 지칭할 수도 있다.
본 개시에서 전자장치에는 번들을 다운로드 하여 설치 가능한 SSP가 내장될 수 있다. SSP가 전자장치에 내장되지 않은 경우, 물리적으로 전자장치와 분리된 SSP는 전자장치에 삽입되어 전자장치와 연결될 수 있다. 예를 들어, SSP는 카드 형태로 전자장치에 삽입될 수 있다. 전자 장치는 단말을 포함할 수 있고, 이때, 단말은 번들을 다운로드하여 설치 가능한 SSP를 포함하는 단말일 수 있다. 단말에 SSP는 내장될 수 있을 뿐만 아니라, 단말과 SSP가 분리된 경우 SSP는 단말에 삽입될 수 있고, 단말에 삽입되어 단말과 연결될 수 있다.
"Local Bundle Assistant(LBA)"는 SSP를 제어하도록 단말 또는 전자장치 내에 설치된 소프트웨어 또는 애플리케이션을 지칭할 수 있다. 이 소프트웨어 또는 애플리케이션은 Local Bundle Manager(LBM)라 지칭할 수 있다.
"로더(SPBL, Secondary Platform Bundle Loader)"는 SSP에서 다른 번들을 설치하고 활성화, 비활성화, 삭제를 관리하는 관리 번들을 지칭할 수 있다. 단말의 LBA 또는 원격의 서버는 로더를 통해 특정 번들을 설치, 활성화, 비활성화, 삭제할 수 있다. 본 개시에서 로더의 동작은 로더를 포함하는 SSP의 동작으로도 기술될 수 있다.
"이벤트(Event)"는 번들 다운로드(Bundle Download), 또는 원격 번들 관리(Remote Bundle Management), 또는 기타 번들이나 SSP의 관리/처리 명령어를 통칭하는 용어일 수 있다. 이벤트(Event)는 원격 Bundle 제공 동작(Remote Bundle Provisioning Operation, 또는 RBP 동작, 또는 RBP Operation) 또는 이벤트 기록(Event Record)으로 명명될 수 있으며, 각 이벤트(Event)는 그에 대응하는 이벤트 식별자(Event Identifier, Event ID, EventID) 또는 매칭 식별자(Matching Identifier, Matching ID, MatchingID)와, 해당 이벤트가 저장된 번들 관리서버 또는 개통중개서버의 주소(FQDN, IP Address, 또는 URL) 또는 각 서버 식별자를 적어도 하나 이상 포함하는 데이터로 지칭될 수 있다. 번들 다운로드(Bundle Download)는 번들 설치(Bundle Installation)와 혼용될 수 있다. 또한 이벤트 종류(Event Type)는 특정 이벤트가 번들 다운로드인지 원격 번들 관리(예를 들어, 삭제, 활성화, 비활성화, 교체, 업데이트 등)인지 또는 기타 번들이나 SSP 관리/처리 명령인지를 나타내는 용어로 사용될 수 있으며, 동작 종류(Operation Type 또는 OperationType), 동작 분류(Operation Class 또는 OperationClass), 이벤트 요청 종류(Event Request Type), 이벤트 분류(Event Class), 이벤트 요청 분류(Event Request Class) 등으로 명명될 수 있다.
"로컬 번들 관리(Local Bundle Management, LBM)"는 번들 로컬관리(Bundle Local Management), 로컬관리(Local Management), 로컬관리 명령(Local Management Command), 로컬 명령(Local Command), 로컬 번들 관리 패키지(LBM Package), 번들 로컬 관리 패키지(Bundle Local Management Package), 로컬관리 패키지(Local Management Package), 로컬관리 명령 패키지(Local Management Command Package), 로컬명령 패키지(Local Command Package)로 명명될 수 있다. LBM은 단말에 설치된 소프트웨어 등을 통해 임의의 번들을 설치(Install)하거나, 특정 번들의 상태(Enabled, Disabled, Deleted)를 변경하거나, 특정 번들의 내용(예를 들면, 번들의 별칭(Bundle Nickname), 또는 번들 요약 정보(Bundle Metadata) 등)을 변경(update)하는 용도로 사용될 수 있다. LBM은 하나 이상의 로컬관리명령을 포함할 수도 있으며, 이 경우 각 로컬관리명령의 대상이 되는 번들은 로컬관리명령마다 서로 같거나 다를 수 있다.
"원격 번들 관리(Remote Bundle Management, RBM)"는 번들 원격관리(Bundle Remote Management), 원격관리(Remote Management), 원격관리 명령(Remote Management Command), 원격 명령(Remote Command), 원격 번들 관리 패키지(RBM Package), 번들 원격 관리 패키지(Bundle Remote Management Package), 원격관리 패키지(Remote Management Package), 원격관리 명령 패키지(Remote Management Command Package), 원격명령 패키지(Remote Command Package)로 명명될 수 있다. RBM은 임의의 번들을 설치(Install)하거나, 특정 번들의 상태(Enabled, Disabled, Deleted)를 변경하거나, 특정 번들의 내용(예를 들면, 번들의 별칭(Bundle Nickname), 또는 번들 요약 정보(Bundle Metadata) 등)을 변경(update)하는 용도로 사용될 수 있다. RBM은 하나 이상의 원격관리명령을 포함할 수도 있으며, 각 원격관리명령의 대상이 되는 번들은 원격관리명령마다 서로 같거나 다를 수 있다.
"목표 번들(target Bundle)"은 로컬관리명령 내지 원격관리명령의 대상이 되는 번들을 지칭하는 용어로 사용될 수 있다.
"번들 규칙(Bundle Rule)"은 목표 번들에 대해 로컬관리 내지 원격관리를 수행할 때 단말이 확인해야 할 정보를 지칭하는 용어로 사용될 수 있다. 또한 번들 규칙은 번들 정책(Bundle Policy), 규칙(Rule), 정책(Policy) 등의 용어와 혼용될 수 있다.
"인증서(Certificate)" 또는 디지털 인증서(Digital Certificate)는 공개 키(Public Key, PK)와 비밀 키(Secret Key, SK)의 쌍으로 구성되는 비대칭 키(Asymmetric Key) 기반의 상호 인증(Mutual Authentication)에 사용되는 디지털 인증서(Digital Certificate)를 나타낼 수 있다. 각 인증서는 하나 또는 하나 이상의 공개 키(Public Key, PK)와, 각 공개 키에 대응하는 공개 키 식별자(Public Key Identifier, PKID)와, 해당 인증서를 발급한 인증서 발급자(Certificate Issuer, CI)의 식별자(Certificate Issuer ID) 및 디지털 서명(Digital Signature)을 포함할 수 있다. 또한 인증서 발급자(Certificate Issuer)는 인증 발급자(Certification Issuer), 인증서 발급기관(Certificate Authority, CA), 인증 발급기관(Certification Authority) 등으로 명명될 수 있다. 본 개시에서 공개 키(Public Key, PK)와 공개 키 식별자(Public Key ID, PKID)는 특정 공개 키 내지 해당 공개 키가 포함된 인증서, 또는 특정 공개 키의 일부분 내지 해당 공개 키가 포함된 인증서의 일부분, 또는 특정 공개 키의 연산 결과(예를 들면, 해시(Hash))값 내지 해당 공개 키가 포함된 인증서의 연산 결과(예를 들면, 해시(Hash))값, 또는 특정 공개 키의 일부분의 연산 결과(예를 들면, 해시(Hash))값 내지 해당 공개 키가 포함된 인증서의 일부분의 연산 결과(예를 들면, 해시(Hash))값, 또는 데이터들이 저장된 저장 공간을 지칭하는 동일한 의미로 혼용될 수 있다.
"인증서 연쇄(Certificate Chain)" 또는 인증서 계층구조(Certificate Hierarchy)는 "인증서 발급자(Certificate Issuer)"가 발급한 인증서들(1차 인증서)이 다른 인증서(2차 인증서)를 발급하는데 사용되거나, 2차 인증서들이 3차 이상의 인증서들을 연계적으로 발급하는데 사용되는 경우, 해당 인증서들의 상관관계를 나타낼 수 있다. 이 때 최초 인증서 발급에 사용된 CI 인증서는 인증서 근원(Root of Certificate), 최상위 인증서, 근원 CI(Root CI), 근원 CI 인증서(Root CI Certificate), 근원 CA(Root CA) 근원 CA 인증서(Root CA Certificate)등으로 명명될 수 있다.
그리고, 본 개시를 설명함에 있어서, 관련된 공지기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우, 그 상세한 설명은 생략한다.
이하에서는 단말 간 번들을 이동하고 설치하는 방법 및 장치에 관한 다양한 실시 예들을 설명한다.
도 1은 본 개시의 실시 예에 따른 SSP의 개념도를 나타낸다.
다양한 실시예에 따르면, 도 1의 예에서와 같이, 단말(110)은 SSP(120)를 포함할 수 있다. 예를 들면, SSP(120)는 단말(110)의 SoC(130)에 내장될 수 있다. 이때, SoC(130)는 통신 프로세서(Communication Processor), 어플리케이션 프로세서(Application Processor) 또는 이 두 프로세서가 통합된 프로세서일 수 있다. 다른 예를 들면, SSP(120)는 SoC에 통합되지 않고 독립된 칩 형태로 착탈형(122)일 수도 있고, 단말(110)에 미리 내장된 내장형(124)일 수도 있다.
다양한 실시예에 따르면, 단말에 포함된 SSP(120)는 하나 이상의 텔레콤 번들, 하나 이상의 페이먼트 번들 또는 하나 이상의 전자신분증 번들 중 적어도 하나를 포함할 수 있다. 예를 들면, 도 1에 도시된 바와 같이, SSP(120)에 복수의 텔레콤 번들(140, 150)이 포함된 경우, 단말(110)은 설정에 따라 복수의 텔레콤 번들(140, 150)을 동시 또는 시분할로 동작하게 하여 이동통신 네트워크를 이용할 수 있다. 또한, SSP(120)에 페이먼트 번들(170) 및 전자신분증 번들(180)이 포함된 경우, 단말(110)은 페이먼트 번들(170)을 이용하여 단말 앱을 통한 온라인 결제 또는 외부 신용카드 PoS (Point of Sale) 기기를 통한 오프라인 결제를 이용할 수 있으며, 전자신분증 번들(180)을 이용하여 단말 소유자의 신분을 인증할 수 있다.
도 2는 본 개시의 실시 예에 따른 SSP(Smart Secure Platform)의 내부 구조에 대한 개념도를 나타낸다.
다양한 실시예에 따르면, 도 2의 예에서와 같이, SSP(210)는 하나의 프라이머리 플랫폼(Primary Platform, PP)(220)과 그 위에서 동작하는 적어도 하나의 세컨더리 플랫폼 번들(Secondary Platform Bundle, SPB)(230, 240)을 포함할 수 있다.
다양한 실시예에 따르면, 프라이머리 플랫폼(220)은 하드웨어(개시되지 않음)와 적어도 하나의 하위계층 운영체제(low level Operating System, LLOS)(222)를 포함할 수 있다.
다양한 실시예에 따르면, 세컨더리 플랫폼 번들(230)은 상위계층 운영체제(High-level Operating System, HLOS)(232)와 그 위에서 동작하는 적어도 하나의 애플리케이션(234)을 포함할 수 있다.
다양한 실시예에 따르면, 각 세컨더리 플랫폼 번들(230, 240)은 프라이머리 플랫폼 인터페이스(Primary Platform Interface, PPI)(250)를 이용하여 프라머리 플랫폼(220)의 중앙처리장치, 메모리 등의 자원에 접근하고 이를 통해 SSP(210)에서 구동될 수 있다.
도 3은 본 개시의 실시 예에 따른 단말이 SSP로 번들을 다운로드하고 설치하기 위한 단말 내부 구성요소의 예를 도시하는 도면이다.
다양한 실시예에 따르면, 도 3의 예에서와 같이, 단말(310)은 SSP(330) 및/또는 SSP(330)를 제어하기 위한 LBA(312)를 포함할 수 있다. 예를 들면, 단말(310) 은 SSP(330)가 장착되고 SSP(330)을 제어하기 위한 LBA(312)가 설치된 단말일 수 있다. 일 예로, SSP(330)은 단말(310)에 내장되거나 착탈형 일 수도 있다.
다양한 실시예에 따르면, SSP(330)는 프라이머리 플랫폼(331), 세컨더리 플랫폼 번들 로더(Secondary Platform Bundle Loader, SPBL)(333), 및 하나 이상의 세컨더리 플랫폼 번들(335, 337, 또는 339) 중 적어도 하나를 포함할 수 있다.
다양한 실시예에 따르면, 세컨더리 플랫폼 번들(335, 337, 또는 339)은 단말 출하 시점에는 SSP(330)내부에 설치되지 않고, 출하 후 원격으로 다운로드 및 설치될 수 있다.
다양한 실시예에 따르면, 도 3의 예에서와 같이, 각 번들은 서로 다른 번들 패밀리 식별자 및/또는 번들 패밀리 관리자 식별자(341, 342, 또는 343)를 가질 수 있다. 이러한 번들 패밀리 식별자와 번들 패밀리 관리자 식별자는 번들의 다운로드 및 설치에 필요한 정보로써 이용될 수 있다. 즉, SSP(330) 또는 SPBL(333)은 번들 패밀리 식별자와 번들 패밀리 관리자 식별자에 따라 특정 번들의 다운로드와 설치를 허용하거나 거부할 수 있다.
도 4는 본 개시의 실시 예에 따른 두 단말 사이에서 번들의 전송이 이루어지기 위해 두 단말이 상호 동작하는 방법의 예를 도시하는 도면이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 4의 예에서와 같이, 제1 단말(400)은 LBA(410)과 SSP(420)을 포함하고, 제2 단말(450)은 LBA(460)과 SSP(470)을 포함할 수 있다.
다양한 실시예에 따르면, 사용자는 단말에 명령을 보내거나, 혹은 사용자가 제공받아야 할 정보를 단말로부터 수신할 수 있다. 예를 들면, 4010 동작 및 4060 동작에서와 같이, 제1 사용자(440) 및 제2 사용자(490)는 제1 단말(400) 및 제2 단말(450)의 LBA(410, 460) 에 명령을 보내거나, 혹은 LBA(410, 460)로부터 사용자가 제공받아야 할 정보를 수신할 수 있다.
다양한 실시예에 따르면, 상기의 동작은 사용자가 전송하고자 하는 번들을 선택하는 과정을 포함할 수 있다. 또한, 상기의 동작은 사용자가 전송 받고자 하는 번들의 정보를 확인하는 과정을 더 포함할 수도 있다. 또한, 상기의 동작은 사용자가 전송하고자 하는 번들의 전송 여부를 승인하는 동작을 더 포함할 수도 있다. 또한, 상기의 동작은 사용자가 전송 받고자 하는 번들의 전송 여부를 승인하는 동작을 더 포함할 수도 있다.
또한, 다양한 실시예에 따르면, 상기의 동작은 사용자가 사용이 중지된 번들을 사용 재개로 만들기 위해 번들을 선택하는 과정을 포함할 수 있다. 또한, 상기의 동작은 사용자가 사용 재개 요청을 받은 번들의 정보를 확인하는 과정을 더 포함할 수도 있다. 또한, 상기의 동작은 사용자가 사용 재개로 만들 번들을 승인하는 동작을 더 포함할 수도 있다. 또한, 상기의 동작은 사용자가 사용 재개 요청을 받은 번들의 사용 재개를 승인하는 동작을 더 포함할 수도 있다.
상기에 기술된 선택과 승인의 동작들은 서로가 독립적인 동작들로서 모두 동작되지 않을 수도 있고, 하나 이상의 동작이 서로 독립적으로 선택되어 동작될 수도 있다.
또한, 4020 동작 및 4070 동작에서 LBA(410, 460)는 SSP(420, 470)에 명령을 내리거나 혹은 SSP(420, 470)와 데이터를 송수신할 수 있다.
일 예에 따르면, 상기의 동작에서 LBA는 전술한 사용자의 명령을 수신하여 이 명령을 SSP에 전달할 수 있다. 상기의 동작에서 LBA가 사용자의 명령을 수신하여 이 명령을 SSP에 전달했을 경우, LBA는 그 결과로서 SSP가 송신하는 결과를 수신할 수 있다.
다른 예에 따르면, 상기의 동작에서 LBA는 다른 단말 혹은 외부 서버로부터 수신한 명령이나 데이터를 SSP에 전달할 수 있다. 상기의 동작에서 LBA가 다른 단말 혹은 외부 서버로부터 받은 명령이나 데이터를 SSP에 전달했을 경우, LBA는 그 결과로서 SSP가 송신하는 결과를 수신할 수 있다.
다양한 실시예에 따르면, 상기의 동작에서 LBA는 사용자의 명령 혹은 다른 단말 혹은 외부 서버로부터 받은 명령이나 데이터를 기반으로 하여 새로운 명령과 데이터를 정의해 이것을 SSP에 전달할 수 있다. 상기의 동작에서 LBA는 사용자의 명령 혹은 다른 단말 혹은 외부 서버로부터 받은 명령이나 데이터를 기반으로 하여 새로운 명령과 데이터를 정의해 이것을 SSP에 전달했을 경우, LBA는 그 결과로서 SSP가 송신하는 결과를 수신할 수 있다.
다양한 실시예에 따르면, 상기의 동작에서 LBA와 SSP는 서로 데이터를 송수신하며 번들을 설치할 수 있다.
다양한 실시예에 따르면, 4050 동작에서 두 LBA(410, 460)는 서로 연결되어 상대에게 명령을 내리거나 상대와 데이터를 송수신할 수 있다. 이 때, 4050 동작에서의 연결은 단말과 단말의 직접적인 기기 간 연결일 수도 있고, 비록 도시되지는 않았으나 두 LBA(410, 460)의 연결 사이에 외부 개체(예컨대, 외부 서버)가 연결되어 있는 간접적인 기기 간 연결일 수도 있다.
상기에 기술된 두 LBA 간의 연결 방법에 대한 보다 상세한 기술은 후술한 도면들을 참조하기로 한다.
다양한 실시예에 따르면, 4030 동작 및 4080 동작에서 SSP(420, 470)는 SSP 내부에서 필요한 데이터를 생성하거나 처리, 혹은 검증할 수 있다.
다양한 실시 예에 따르면, 상기의 동작에서 SSP는 번들 이동 설정을 확인할 수 있다. 또한, 상기의 동작에서 SSP는 번들 이동 코드를 생성하고 활용할 수 있다. 상기에 기술된 번들 이동 설정 관련 동작과 번들 이동 코드 관련 동작은 서로 독립적인 기능으로서, 두 기능 모두 실행되지 않거나, 또는, 두 기능 중 어느 하나만 실행되거나, 또는, 두 기능 모두가 실행될 수도 있다. 두 기능 모두가 실행되는 경우에도 두 기능은 완전히 독립된 기능으로서 수행될 수 있다.
다양한 실시예에 따르면, 상기의 동작에서 SSP는 자신의 SSP 정보를 생성하거나 상대 단말 및/혹은 서버로부터 받은 SSP 정보를 검증할 수 있다. 또한 상기의 동작에서 SSP는 자신을 검증할 수 있는 인증 데이터를 생성할 수도 있고 상대 단말로부터 받은 인증 데이터를 검증할 수도 있다.
다양한 실시예에 따르면, 상기의 동작에서 SSP는 도 5에서 기술할 "증명서"를 생성할 수 있고, 수신한 "증명서"를 검증할 수 있다. SSP가 생성/검증 가능한 다양한 "증명서"의 예들은 이후 기술될 도 10 내지 도 15 및 도 22 내지 도 27을 참고하기로 한다.
다양한 실시예에 따르면, 상기의 동작에서 SSP는 번들의 상태를 설정할 수 있다. SSP가 설정할 수 있는 다양한 번들의 상태와 설정 조건은 이후 기술될 도 10 내지 도 15 및 도 22 내지 도 27을 참고하기로 한다.
다양한 실시예에 따르면, 상기의 동작에서 SSP는 번들을 생성할 수 있다.
도 5는 본 개시의 일부 실시 예에 따른 "증명서(Attestation)"의 구성을 도시하는 도면이다.
다양한 실시예에 따르면, 증명서는 "번들 구분자"를 선택적으로 포함할 수 있다(510). 예를 들어, 증명서는 도 5에 도시된 것처럼 번들 구분자 중 하나인 번들 식별자(SPB ID)를 선택적으로 포함할 수 있다.
다양한 실시예에 따르면, 증명서는 또 다른 증명서를 선택적으로 더 포함할 수 있다(530). 증명서 안에 포함되는 또 다른 증명서의 다양한 실례는 후에 기술될 도 10 내지 도 15의 설명을 참조하기로 한다.
다양한 실시예에 따르면, 증명서는 "SSP 식별자(SSP ID)"를 선택적으로 더 포함할 수 있다(540).
다양한 실시예에 따르면, 증명서는 SSP가 수행한 동작에 대한 정보를 선택적으로 더 포함할 수 있다(550). SSP가 수행하는 동작의 다양한 실례는 후에 기술될 도 10 내지 도 15의 설명을 참조하기로 한다.
다양한 실시예에 따르면, 증명서는 필요한 경우에 앞서 기술한 정보(530, 540, 550) 이외의 기타 데이터를 선택적으로 더 포함할 수 있다(520). 증명서 안에 포함될 수 있는 기타 데이터의 다양한 실례는 후에 기술될 도 10 내지 도 15의 설명을 참조하기로 한다.
다양한 실시예에 따르면, 증명서는 앞서 기술한 정보들에 대한 전자 서명 데이터를 포함할 수 있다(560). 이 서명 데이터는 SSP의 서명용 인증서에 의해 생성된 전자 서명일 수 있다.
도 6은 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 번들이 전송되는 절차를 개념적으로 도시하는 도면이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 6의 예에서와 같이, 제1 단말(600)은 제1 LBA(620)과 제1 SSP(610)을 포함하고, 제2 단말(650)은 제2 LBA(670)과 제2 SSP(660)을 포함할 수 있다. 일 예로, 제1 단말(600)은 제1 SSP(610)가 장착되고 제1 SSP(610)을 제어하기 위한 제1 LBA(620)이 설치된 단말일 수 있고, 제2 단말(650)은 제2 SSP(660)가 장착되고 제2 SSP(660)을 제어하기 위한 제2 LBA(670)이 설치된 단말일 수 있다.
도 6을 참조하면, 6000 단계에서 제1 단말(600)의 제1 SSP(610), 제1 LBA(620)과 제2 단말(650)의 제2 LBA(670) 는 번들 전송을 위해 필요한 준비 절차(번들 전송 준비 절차)를 수행할 수 있다. 상기 절차에 대한 보다 자세한 설명은 후술될 도 7의 상세 설명을 참조하기로 한다.
도 6을 참조하면, 6005 단계에서 제1 단말(600)으로부터 제2 단말(650)으로 번들이 전송되는 절차(번들 전송 절차)가 수행될 수 있다. 상기 절차에 대한 보다 자세한 설명은 후술될 도 8의 상세 설명을 참조하기로 한다.
도 6을 참조하면, 6010 단계에서 제 1단말(600)과 제 2단말(660)은 전송된 번들의 설치 절차와 번들의 상태를 설정하는 절차 (번들 전송 마무리 절차)를 수행할 수 있다. 상기 절차에 대한 자세한 설명은 후술될 도 9 내지 도 12의 상세 설명을 참조하기로 한다.
도 7은 도 6에서 제시된 절차 중 번들 전송을 위해 준비하는 절차에 대한 세부 절차를 도시하는 도면이다. 보다 상세하게는, 도 7은 본 개시의 실시 예에 따른 하나의 단말이 다른 단말로 번들을 전송하기 위하여 필요한 준비 과정을 거치는 절차를 예시적으로 도시하는 도면이다. 본 명세서에서, 도 7의 절차는 번들 전송 준비 절차로 지칭될 수 있다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 7의 예에서와 같이, 제1 단말(700)은 제1 LBA(720)과 제1 SSP(710)을 포함하고, 제2 단말(750)은 제2 LBA(770)과 제2 SSP(760)을 포함할 수 있다. 일 예로, 제1 단말(700)은 제1 SSP(710)가 장착되고 제1 SSP(710)을 제어하기 위한 제1 LBA(720)이 설치된 단말일 수 있고, 제2 단말(750)은 제2 SSP(760)가 장착되고 제2 SSP(760)을 제어하기 위한 제2 LBA(770)이 설치된 단말일 수 있다.
다양한 실시예에 따르면, 제1 단말(700)은 기 설치된 번들을 보유하고 있을 수 있으며, 이 번들과 연계된 메타데이터를 더 보유하고 있을 수 있다.
다양한 실시예에 따르면, 제1 단말(700)은 해당 번들과 연계되어 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 또는 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나를 보유하고 있을 수 있다.
다양한 실시예에 따르면, 제1 단말(700)은 해당 번들과 연계되어 '번들 이동 설정'을 보유하고 있을 수 있다. 번들 이동 설정은 해당 번들의 기기 간 전송 가능 여부와 관련된 정보를 선택적으로 포함하고 있을 수 있다. 또한, 번들 이동 설정은 해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부에 대한 정보를 선택적으로 더 포함하고 있을 수 있다. 예를 들어, 해당 번들이 '복수의 단말에서 동시에 중복으로 사용되는 것이 금지'되어 있는 경우, 즉 '어느 한 시점에 번들은 하나의 단말에서만 사용되어야' 하는 경우, 이에 대한 정보가 포함되어 있을 수 있다.
도 7을 참조하면, 7000 단계에서 기기 간 전송될 번들의 정보가 제1 LBA(720)에 전달될 수 있다. 이 전달 과정은 예컨대, 도 7에 도시된 바와 같이, 제1 단말(700)이 제공하는 UI를 통해 사용자가 직접 번들을 선택하는 과정을 통해 이루어질 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 제1 LBA(720)에게 입력될 수도 있으며, 또는 제1 LBA(720)이 원격 서버에 접속하여 해당 정보를 읽어올 수도 있다.
도 7을 참조하면, 7005 단계에서 7000 단계를 통해 선택된 번들에 관련된 정보가 제1 LBA(720)로부터 제1 SSP(710)으로 전달될 수 있다. 예컨대, 도 7에 도시된 바와 같이, 상기 선택된 번들에 관련된 정보가 Select SPB command를 통해 제1 LBA(720)로부터 제1 SSP(710)으로 전달될 수 있다. 이 때, 제1 LBA(720)로부터 제1 SSP(710)으로 전달되는 정보는 7000 단계에서 선택되었던 번들을 식별(identify)하기 위한 정보를 포함할 수 있다.
도 7을 참조하면, 7010 단계에서 제1 SSP(710)은 전송을 요청 받은 번들의 기기 간 전송 가능 여부를 확인할 수 있다. 이 과정은 우선 7005 단계에서 수신한 정보에 기초하여 전송을 요청 받은 번들을 식별하고, 해당 번들과 연관된(associated with) '번들 이동 설정'을 확인함으로써 수행될 수 있다. 이 과정에서, '번들 이동 설정'이 '해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부에 대한 정보'를 포함하고 있을 경우 제 1 SSP(710)은 이 사실을 확인할 수 있다.
또한, 7010 단계에서 제1 SSP(710)은 선택적으로 '번들 이동 코드'를 설정할 수 있다. '번들 이동 코드'는 해당 번들의 기기 간 전송 과정에서 해당 번들을 지칭하기 위해 사용되는 코드로서 해당 번들을 식별할 수 있는 값이어야 한다. 제1 SSP(710)은 앞서 기술한 '번들 이동 코드'와 전송하려는 번들의 정보를 바인딩(binding)할 수 있다.
도 7을 참조하면, 7015 단계에서 7005 단계에 대한 응답 결과가 제1 SSP(710)으로부터 제1 LBA(720)으로 전송될 수 있다. 예컨대, 도 7에 도시된 바와 같이, Select SPB command에 대한 응답이 Select SPB response를 통해 제1 SPB(710)로부터 제1 LBA(720)으로 전달될 수 있다. 이 응답 값은 7010 단계에서 기술된 '번들 이동 코드'를 포함할 수 있다.
도 7을 참조하면, 7020 단계에서 기기 간 번들 전송을 위해 필요한 정보가 제1 단말 (700)의 제1 LBA(720)으로부터 제2 단말(750)의 제2 LBA(770)으로 전달될 수 있다. 이 때 제1 LBA(720)으로부터 제2 LBA(770)으로 전달되는 정보에는 '번들 이동 코드'가 포함될 수 있다. 또한, 제1 LBA(820)으로부터 제2 LBA(870)으로 전달되는 정보는 향후 7025 단계에서 제1 LBA(720)과 제2 LBA(770) 사이에 수립될(established) 연결을 위해 필요한 정보들을 선택적으로 더 포함할 수 있다. 또한, 제1 LBA(720)으로부터 제2 LBA(770)으로 전달되는 정보에는 기기 간 번들 이동이 수행될 것임을 알려주는 정보가 선택적으로 더 포함될 수 있다.
상술한 7020 단계를 통해 제1 LBA(720)으로부터 제2 LBA(770)으로 전달되는 정보들은 다양한 방법으로 전달될 수 있다. 예를 들면, 제1 LBA(720)는 제2 LBA(770)로 전달해야 할 정보를 제1 단말(700)의 UI를 통해 사용자에게 제공할 수 있으며, 사용자는 제공받은 정보를 제2 단말(750)의 UI를 이용해 제2 LBA(770)에 입력할 수 있다. 혹은, 제1 LBA(720)는 제2 LBA(770)로 전달해야 할 정보를 이미지 (예를 들어 QR 코드)의 형태로 만들어 제1 단말(700)의 화면에 표시하고, 사용자는 제2 단말(750)를 이용해 이 이미지를 스캔함으로써 제2 LBA(770)에 정보를 전달할 수 있다. 하지만 제1 LBA(720)으로부터 제2 LBA(770)으로 정보를 전달하는 방법은 상기의 방법들에 국한되지 않는다.
도 7을 참조하면, 7025 단계에서 제1 LBA(720)과 제2 LBA(770) 사이에 연결이 수립(또는, 설정)될 수 있다. 만일 7020 단계에서 연결을 위해 필요한 정보들이 전송되었다면, 제1 LBA(720)과 제2 LBA(770)는 이 정보를 이용해 연결을 수립할 수도 있다. 제1 LBA(820)과 제2 LBA(870)의 연결은 직접적인 기기 간 연결일 수도 있고 (예컨대, NFC, 블루투스, UWB, WiFi-Direct, LTE D2D(device-to-device), 5G D2D) 혹은 제1 LBA(720)과 제2 LBA(770) 사이에 원격 서버(가령, 릴레이 서버) 가 위치한 원거리 연결일 수도 있다.
도 7을 참조하면, 7025 단계는 마지막 단계로서 도시되었지만 이 단계는 전술한 다른 단계, 즉 7000 단계, 7005 단계, 7010 단계, 7015 단계, 7020 단계와는 독립적인 단계로서 다른 단계들과 순서에 구애되지 않고 수행될 수 있다. 예컨대, 7025 단계는 7015 단계와 7020 단계의 사이에서 수행될 수도 있으며, 이 경우 7020 단계에서 제1 LBA(720)으로부터 제2 LBA 2(770)으로 전송되는 정보는 7025 단계에서 수립된 연결을 통해 전송될 수도 있다.
도 8은 도 6에서 제시된 절차 중 번들의 전송이 이루어지는 절차에 대한 세부 절차를 도시하는 도면이다. 보다 상세하게는, 도 8은 본 개시의 실시 예에 따른 하나의 단말이 다른 단말로 번들을 전송하는 절차를 예시적으로 도시하는 도면이다. 본 개시에서 도 8의 절차는 번들 전송 절차로 지칭될 수 있다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 8의 예에서와 같이, 제1 단말(800)은 제1 LBA(820)과 제1 SSP(810)을 포함하고, 제2 단말(850)은 제2 LBA(870)과 제2 SSP(860)을 포함할 수 있다. 일 예로, 제1 단말(800)은 제1 SSP(810)가 장착되고 제1 SSP(810)을 제어하기 위한 제1 LBA(820)이 설치된 단말일 수 있고, 제2 단말(850)은 제2 SSP(860)가 장착되고 제2 SSP(860)을 제어하기 위한 제2 LBA(870)이 설치된 단말일 수 있다.
도 8을 참조하면, 8000 단계에서 제2 LBA(870)은 제2 SSP 2(860)에게 "SSP 정보 (SspInfo)"를 요청할 수 있다. 8000 단계에서 제2 LBA(870)가 제2 SSP(860)에게 "SSP 정보 (SspInfo)"를 요청할 때, 제2 LBA(870)는 제2 SSP(860)에게 기기 간 번들 이동이 수행될 것임을 알려줄 수 있다.
또한, 8000 단계는 도 8에서 도시했던 과정에 바로 이어서 자동으로 수행될 수도 있고, 외부의 입력을 받은 후 수행될 수도 있다. 이 때, '외부의 입력'은 제2 단말(850)이 제공하는 UI를 통해 사용자가 직접 전송 받을 번들을 선택하는 과정을 통해 이루어질 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 제2 LBA(870)에게 입력될 수도 있으며, 또는 제2 LBA(870)이 원격 서버에 접속하여 해당 정보를 읽어올 수도 있다.
도 8을 참조하면, 8005 단계에서 제2 SSP(860)는 자신의 "SSP 정보"를 생성할 수 있다. "SSP 정보"에는 번들 전송을 위해 제공되어야 하는 제2 SSP의 정보가 포함될 수 있다. 이때, "SSP 정보"에는 제2 SSP(860)가 번들을 수신하기 전 거쳐야 할 인증서 협상 과정을 위한 정보(인증서 협상 정보)가 포함될 수 있다. 이 "인증서 협상 정보"는 제2 SSP(860)가 다른 SSP를 검증하는데 이용할 수 있는 인증서 정보들(SenderSpblVerification)과 다른 SSP가 자신을 검증하는데 이용될 수 있는 인증서 정보들(ReceiverSpblVerification)를 포함할 수 있다. 또한, "인증서 협상 정보"는 제2 SSP(860)가 지원하는 키 합의 알고리즘의 리스트를 선택적으로 더 포함할 수 있으며, 제2 SSP (860)가 지원하는 암호화 알고리즘의 리스트를 선택적으로 더 포함할 수 있다. 또한 "SSP 정보"에는 제2 SSP(960)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보 중 적어도 하나를 포함하는 SSP 버전 정보가 선택적으로 더 포함될 수 있다.
도 8을 참조하면, 8010 단계에서 제2 SSP(860)는 제2 LBA(870)와 제1 LBA(820)을 거쳐 제1 SSP(810)에게 8005 단계에서 생성했던 "SSP 정보"를 전달할 수 있다.
이상에 기술된 8000에서 8010 단계에 따르면 제2 LBA(870)가 제2 SSP(860)에게 "SSP 정보 (SspInfo)" 를 요청하고, 제2 SSP(860)가 자신의 "SSP 정보"를 생성한 뒤, 제2 SSP(860)가 제2 LBA(870)와 제1 LBA(820)을 거쳐 제1 SSP(810)에게 "SSP 정보"를 전달할 수 있다. 하지만, 실시예에 따라서는, 제 2 단말(850)에서 제 1 단말(800)로 "SSP 정보"가 전달되는 과정은 다음과 같을 수도 있다. 예컨대, 제2 LBA(870)가 스스로 "SSP 정보"를 생성한 뒤 제1 LBA(820)을 거쳐 제1 SSP(810)에게 "SSP 정보"를 전달할 수 있다.
도 8을 참조하면, 8015 단계에서 제1 SSP(810)은 수신된 "SSP 정보"를 확인하고 이 정보에 기반하여 자신을 인증할 수 있는 "제1 단말 인증 정보(Device1.Auth)"를 생성할 수 있다. 이 과정에 대한 보다 구체적인 절차는 다음과 같다.
제1 SSP(810)은 수신된 "SenderSpblVerification"을 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 키 합의용 인증서(ssp1.Cert.KA)를 선택할 수 있다. 혹은, 제1 SSP(810)은 수신된 "제2 SSP(860)가 지원하는 키 합의 알고리즘의 리스트"를 이용해 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair) 공개키 "ssp1.ePK.KA"와 비밀키 "ssp1.eSK.KA"를 을 생성한 뒤, 이 키 쌍 중 공개키(ssp1.ePK.KA)를 선택할 수 있다. 또한, 제1 SSP(810)은 수신된 "SenderSpblVerification"를 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 서명용 인증서(ssp1.Cert.DS)를 더 선택할 수 있다.
또한, 제1 SSP(810)은 수신된 "ReceiverSpblVerification"을 이용해 검증을 수행할 제2 SSP(860)의 인증서 정보를 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CiPkIdToBeUsed"로 설정할 수 있다.
또한, 제1 SSP(810)은 수신된 "제2 SSP(860)가 지원하는 암호화 알고리즘의 리스트"를 이용해 향후 사용될 암호화 알고리즘을 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CryptoToBeUsed"로 설정할 수 있다.
또한, 제1 SSP(810)은 수신된 "제2 SSP(860)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보"의 리스트를 확인하여 그 중 자신 역시 지원하는 표준 규격의 버전이 존재하는지를 확인할 수 있다.
"제1 단말 인증 정보(Device1.Auth)"는 상기에 설명된 "ssp1.Cert.KA", "ssp1.ePK.KA" "CiPkIdToBeUsed", "CryptoToBeUsed" 중 적어도 하나를 포함할 수 있다. 또한, "제1 단말 인증 정보(Device1.Auth)"는 상기에 설명된 "ssp1.Cert.DS"를 선택적으로 더 포함할 수 있다. 또한, "제1 단말 인증 정보(Device1.Auth)"는 향후 전송될 번들에 연관된 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나를 선택적으로 더 포함할 수 있다.
이때, 상기에 언급한 "제1 단말 인증 정보(Device1.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp1.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 "제1 단말 인증 정보"의 일부로서 추가될 수 있다.
도 8을 참조하면, 8020 단계에서 제1 SSP(810)은 제1 LBA(820)을 거쳐 제2 LBA(870)에게 8015 단계에서 생성했던 "제1 단말 인증 정보(Device1.Auth)"를 전달할 수 있다.
도 8을 참조하면, 8025단계에서 제2 LBA(870)은 제2 SSP(860)에게 "제1 단말 인증 정보(Device1.Auth)"를 전달할 수 있다. 또한, 제2 LBA(870)은 제2 SSP(860)에게 "번들 이동 코드"를 더 전달할 수 있다.
도 8을 참조하면, 8030 단계에서 제2 SSP(860)은 수신된 "제1 단말 인증 정보(Device1.Auth)"를 검증할 수 있다. 만일, 제2 SSP(860)이 "ssp1.Cert.KA"를 수신한 경우, 해당 인증서의 서명을 확인하여 인증서의 유효성을 확인할 수 있다. 또한, 제2 SSP(860)이 "ssp1.ePK.KA"와 이에 대한 디지털 서명을 전송 받은 경우에는, 먼저 ssp1.Cert.DS의 유효성을 검사한 뒤 이 인증서를 이용하여 디지털 서명을 확인해 수신된 공개키 ssp1.ePK.KA 의 무결성을 확인할 수 있다. 또한, 제2 SSP(860)은 수신된 "CiPkIdToBeUsed"를 확인해 자신을 검증할 수 있는 적어도 하나 이상의 서명용 인증서(ssp2.Cert.DS)를 선택할 수 있다.
또한, 도면에는 도시되어 있지 않지만, 8030 단계에서 제2 SSP(960)은 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair)으로 공개키 "ssp2.ePK.KA"와 비밀키 "ssp2.eSK.KA"를 생성한 뒤, 이 키 쌍 중 공개키(ssp2.ePK.KA)를 선택할 수 있다. 또한, 제2 SSP(860)은 ssp1.Cert.KA에 포함되어 있는 키 합의용 공개키나 ssp1.ePK.KA 중 하나를 선택한 뒤, 이 값과 ssp2.eSK.KA를 이용하여 향후 단말 1과의 통신 중 암호화에 사용될 세션 키 ShKey01을 생성할 수 있다. ShKey01은 수신된 "CryptoToBeUsed"에 포함되어 있는 암호화 알고리즘용 세션 키여야 한다.
또한, 8030 단계에서 제2 SSP(860)은 자신을 인증할 수 있는 "제2 단말 인증 정보(Device2.Auth)"를 생성할 수 있다. 이때, "제2 단말 인증 정보(Device2.Auth)"는 "ssp2.Cert.DS"를 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 "ssp2.ePK.KA"를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 SSP 2(860)에 의해 생성된 현재 세션을 지칭하는 트랜잭션 아이디(transaction ID)를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 "번들 이동 코드"를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 제2 SSP(960)의 SSP 식별자를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 향후 전송될 번들에 연관된 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나를 선택적으로 더 포함할 수 있다.
이때, 상기에 언급한 "제2 단말 인증 정보(Device2.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp2.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 "제2 단말 인증 정보"의 일부로서 추가될 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"의 일부 혹은 전체는 앞서 생성된 세션 키 ShKey01를 이용해 암호화될 수 있다.
도 8을 참조하면, 8035 단계에서 제2 SSP(860)는 제2 LBA(870)와 제1 LBA(820)을 거쳐 제1 SSP(810)에게 8030 단계에서 생성했던 "제2 단말 인증 정보(Device2.Auth)"를 전달할 수 있다. 이때, "번들 이동 코드"가 선택적으로 더 전송될 수 있다.
도 8을 참조하면, 8040 단계에서 제1 SSP(810)은 수신된 "제2 단말 인증 정보(Device2.Auth)"를 검증할 수 있다. 제1 SSP(810)은 수신된 "ssp2.Cert.DS"의 서명을 검증하여 해당 인증서의 유효성을 검증할 수 있다. 또한, 제1 SSP(810)은 수신된 번들 패밀리 식별자(SPB Family ID) 및/또는 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID)가 자신이 전송하고자 하는 번들과 연관되어 올바르게 설정된 값인지를 검사할 수 있다. 또한, 제1 SSP(810)은 수신된 트랜잭션 아이디(transaction ID) 및/또는 제2 SSP(860)의 SSP 식별자를 저장할 수 있다. 또한, 제1 SSP(810)은 수신된 트랜잭션 아이디(transaction ID)나 제2 SSP(960)의 SSP 식별자를, 현재 진행되고 있는 세션 혹은 전송하고자 하는 번들과 바인딩(binding)시킬 수 있다.
이 과정에서, 만일 "제2 단말 인증 정보(Device2.Auth)"에 암호화된 데이터가 포함되어 있을 경우, 제1 SSP(810)은 전송 받은 ssp2.ePK.KA와 자신의 ssp1.Cert.KA에 포함되어 있는 키 합의용 공개키에 대응되는 비밀키나 ssp1.eSK.KA를 이용하여 세션 키 ShKey01를 생성하고, 이 세션 키를 이용하여 암호화된 데이터를 복호화한 뒤 검증 과정을 수행할 수 있다. 또한 이 과정에서, 만일 "제2 단말 인증 정보(Device2.Auth)"에 디지털 서명이 포함되어 있을 경우, 제1 SSP(810)은 "ssp2.Cert.DS"를 이용하여 수신된 디지털 서명의 유효성을 검증할 수 있다.
또한 8040 단계에서, 도 8에 도시되어 있지는 않지만, 제1 SSP(810)은 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair) 공개키 "ssp1.bundle.ePK.KA"와 비밀키 "ssp1.bundle.eSK.KA"를 을 생성할 수 있다. 이때, 키 쌍 "ssp1.bundle.ePK.KA 와 ssp1.bundle.eSK.KA"는 앞서 생성되었던 "ssp1.ePK.KA 와 ssp1.eSK.KA"와 동일한 값으로 설정될 수도 있다. 또는, 키 쌍 "ssp1.bundle.ePK.KA 와 ssp1.bundle.eSK.KA"는 앞서 사용되었던 "ssp1.Cert.KA에 포함되어 있는 공개키와 이에 대응되는 비밀키"와 동일한 값으로 설정될 수도 있다. 또한, 제1 SSP(810)은 ssp1.bundle.eSK.KA와 ssp2.ePK.KA를 이용하여 세션 키 ShKey02를 생성할 수 있다. 만일 ssp1.bundle.eSK.KA를 위해 ssp1.eSK.KA 혹은' ssp1.Cert.Ka에 포함되어 있는 공개키에 대응되는 비밀키'가 재사용되었다면, 세션 키 ShKey02의 값 역시 이전에 생성되었던 ShKey01의 값으로 설정될 수 있다.
또한 8040 단계에서 제1 SSP(810)은 제2 단말(850)으로 전송할 번들 및/또는 번들과 연관된 메타데이터를 구성할 수 있다. 이때, 제1 SSP(810)은 수신된 "번들 이동 코드"를 이용하여 자신이 전송하고자 하는 번들을 식별할 수 있다. 또한, 구성될 번들에는 "ssp1.Cert.DS"가 포함될 수 있다. 또한, 구성될 번들에는 "ssp1.bundle.ePK.KA"가 더 포함될 수 있다. 또한, 구성될 번들은 해당 세션을 식별하는 트랜잭션 아이디(transaction ID)를 더 포함할 수 있다. 또한, 구성될 번들에는 전송될 번들과 연관된 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 선택적으로 더 포함될 수 있다. 다양한 실시예에 따르면, 8040 단계에서 구성되는 번들(또는, 번들과 연관된 메타데이터) 안에는 "번들 이동 설정"이 포함될 수 있다.
다양한 실시예에 따르면, 8040 단계에서 구성될 번들에는 ssp1.Cert.DS를 이용하여 생성된 디지털 서명 데이터가 추가될 수 있다. 즉, 상기에 명시된 번들의 구성 요소 일부 혹은 전체에 대하여 생성된 디지털 서명 데이터가 번들의 일부로서 추가될 수 있다. 또한, 구성될 번들의 일부 혹은 전체는 ShKey02를 이용해 암호화될 수 있다.
도 8을 참조하면, 8045 단계에서 제1 SSP(810)은 제1 LBA(820)을 거쳐 제2 LBA(870)에게 8040 단계에서 생성했던(구성된) 번들을 전달할 수 있다. 이때, 전송되는 번들과 연관된 메타데이터가 선택적으로 더 전송될 수 있다. 또한, 전송되는 번들과 연관된 "번들 이동 설정"이 더 전송될 수 있다. 예를 들면, “번들 이동 설정”이 번들 또는 메타데이터에 포함되지 않고, 별도의 포맷(예컨대, 메시지)으로 전송될 수 있다.
도 9는 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 세부 절차를 도시하는 도면이다. 보다 상세하게는, 도 9는 본 개시의 실시 예에 따른 번들의 전송이 이루어진 후, 단말에 번들이 설치되는 과정과 번들 상태 설정이 이루어지는 절차를 도시하는 도면의 한 가지 가능한 예시이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 9의 예에서와 같이, 제1 단말(900)은 제1 LBA(920)과 제1 SSP(910)을 포함하고, 제2 단말(950)은 제2 LBA(970)과 제2 SSP(960)을 포함할 수 있다. 일 예로, 제1 단말(900)은 제1 SSP(910)가 장착되고 제1 SSP(910)을 제어하기 위한 제1 LBA(920)이 설치된 단말일 수 있고, 제2 단말(950)은 제2 SSP(960)가 장착되고 제2 SSP(960)을 제어하기 위한 제2 LBA(970)이 설치된 단말일 수 있다.
1. 번들 설치
도 9를 참조하면, 9000 단계에서 제2 LBA(970)과 제2 SSP(960)은 서로 협업하여 제2 단말(950)에 번들을 설치할 수 있다. 이 과정에서 다음의 절차들이 함께 수행될 수 있다. 만일 메타데이터가 전송된 경우, 제2 LBA(970) 혹은 제2 SSP(960)은 메타데이터에 포함된 내용을 검증할 수 있다. 만일 "번들 이동 설정"이 전송되었다면, 제2 LBA(970)은 이 정보를 제2 SSP(960)으로 전달할 수 있다. 만일 트랜잭션 아이디(transaction ID)가 전송되었다면, 제2 LBA(970) 혹은 제2 SSP(960)은 이 트랜잭션 아이디가 현재 세션에서 사용되었던 트랜잭션 아이디와 동일한지의 여부를 검사할 수 있다. 만일 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 전송되었다면, 제2 LBA(970) 혹은 제2 SSP(960)은 이 정보가 현재 수신하려는 번들의 정보와 일치하는지의 여부를 확인할 수 있다. 만일 ssp1.Cert.DS이 전송되었다면, 제2 SSP(960)은 이 인증서의 유효성을 검증해 제1 SSP(910)을 인증할 수 있다. 만일 전송 받은 데이터에 암호화된 데이터가 포함되어 있다면, 제2 SSP(960)은 전송 받은 ssp1.bundle.ePK.KA 와 자신의 ssp2.eSK.KA를 이용하여 세션 키 ShKey02를 생성하고, 이 세션 키를 이용해 암호화된 데이터를 복호화한 뒤 검증을 수행할 수 있다. 만일 수신된 데이터에 디지털 서명이 포함되어 있다면, 제2 SSP(960)은 ssp1.Cer.DS를 검증한 뒤, 이 인증서를 이용해 디지털 서명의 유효성을 검증할 수 있다.
2. 중복 사용 가능 여부 확인
또한, 도면에는 도시되지 않았지만, 제 2 LBA(970) 및/또는 제 2 SSP(960)는 해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부를 선택적으로 판단할 수 있다. 이 판단을 하는 몇 가지 가능한 방법은 다음과 같다. 한 가지 가능한 예로, 만일 번들 이동 설정에 해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부가 포함되어 있다면, 제 2 LBA(970) 및/또는 제 2 SSP(960)는 이 정보를 확인함으로써 판단을 내릴 수 있다. 다른 가능한 예로, 제 2 LBA(970) 및/또는 제 2 SSP(960)는 수신한 번들 패밀리 식별자(SPB Family ID) 및/또는 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID)를 이용해 해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부를 확인할 수도 있다. 이 과정은 9000 단계의 일부로써 9000 단계에서 이루어지는 절차들과 순서에 상관 없이 이루어질 수도 있고, 혹은 9000 단계 이후에 수행될 수도 있다.
3. 번들 상태 설정
만약 해당 번들이 복수의 단말에서 중복 사용이 가능한 번들로 판단된 경우 번들의 상태를 추가적으로 설정하는 과정은 필요하지 않을 수 있다. 혹은, 제 2 LBA(970) 및/또는 제 2 SSP(960)가 해당 번들의 중복 사용 여부를 판단하지 않는 경우에도, 제 2 LBA(970) 및/또는 제 2 SSP(960)의 구현에 따라 번들의 상태를 추가적으로 설정하는 과정은 필요하지 않을 수 있다.
도 10은 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다. 보다 상세하게는, 도 10은 본 개시의 실시 예에 따른 번들의 전송이 이루어진 후, 단말에 번들이 설치되는 과정과 번들 상태 설정이 이루어지는 절차를 도시하는 도면의 또 다른 예시이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 10의 예에서와 같이, 제1 단말(1000)은 제1 LBA(1020)과 제1 SSP(1010)을 포함하고, 제2 단말(1050)은 제2 LBA(1070)과 제2 SSP(1060)을 포함할 수 있다. 일 예로, 제1 단말(1000)은 제1 SSP(1010)가 장착되고 제1 SSP(1010)을 제어하기 위한 제1 LBA(1020)이 설치된 단말일 수 있고, 제2 단말(1050)은 제2 SSP(1060)가 장착되고 제2 SSP(1060)을 제어하기 위한 제2 LBA(1070)이 설치된 단말일 수 있다.
1. 번들 설치
도 10을 참조하면, 10000 단계에서 제2 LBA(1070)과 제2 SSP(1060)은 서로 협업하여 제2 단말(1050)에 번들을 설치할 수 있다. 이에 대한 상세한 설명은 도 9의 "번들 설치" 과정을 참조한다.
2. 중복 사용 가능 여부 확인
또한, 도면에는 도시되지 않았지만, 제 2 LBA(1070) 및/또는 제 2 SSP(1060)는 해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부를 선택적으로 판단할 수 있다 이에 대한 상세한 설명은 도 9의 "중복 사용 가능 여부 확인" 과정을 참조한다.
3. 번들 상태 설정
만약 해당 번들이 복수의 단말에서 중복 사용이 가능하지 않은 번들로 판단된 경우 아래와 같이 번들의 상태를 추가적으로 설정한다. 혹은, 제 2 LBA(1070) 및/또는 제 2 SSP(1060)가 해당 번들의 중복 사용 여부를 판단하지 않는 경우에도, 제 2 LBA(1070) 및/또는 제 2 SSP(1060)의 구현에 따라 아래와 같이 번들의 상태를 추가적으로 설정하는 과정이 수행될 수 있다.
도 10을 참조하면, 10005 단계에서 제 2 SSP(1060)은 해당 번들의 상태를 "IN TRANSITION"으로 설정할 수 있다. "IN TRANSITION"은 번들이 성공적으로 설치되었지만 아직 사용이 불가한 상태 (또한, '다른 단말의 요청 (예를 들면, 'finalizationResponse 나 recoveryRequest 를 송신함으로서 이루어지는 요청)' 및/또는 '(본 개시에서는 설명되지 않았지만) 외부 서버의 요청'과 같은 추가 동작에 의해서만 사용 가능한 상태 (Disabled, Enable, Active 상태)로 변경될 수 있는 상태)를 의미한다.
도 10을 참조하면, 10010 단계에서 제 2 LBA(1070)은 제 2 SSP(1060)에게 "증명서"를 요청할 수 있다.
도 10을 참조하면, 10015 단계에서 제 2 SSP(1060)은 "증명서"를 생성할 수 있다. 도 10 에서 이 증명서는 finalizationRequest라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationRequest는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationRequest는 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationRequest는 550에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- finalizationRequest는 520에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- finalizationRequest는 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 10을 참조하면, 10020 단계에서 제 2 SSP(1060)은 제 1 SSP(1010)에게 finalizationRequest를 전달할 수 있다. 예를 들어, 제 2 SSP(1060)은 제 1 SSP(1010)에게 다음과 같은 과정을 거쳐 finalizationRequest를 전달할 수 있다. 즉, 제 2 SSP(1060)은 제 2 LBA (1070) 에게 10010 단계의 응답으로 finalizationRequest를 전달하고, 제 2 LBA는 제 1 LBA(1020)을 거쳐 제 1 SSP 에게 finalizationRequest를 전달할 수 있다.
도 10을 참조하면, 10025 단계에서 제 1 SSP(1010)은 수신한 finalizationRequest를 검증할 수 있다. 이 검증 과정은, finalizationRequest에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationRequest에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자 인지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 명령어 정보가 번들의 상태를 “IN TRANSITION” 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 10025 단계에서 제 1 SSP(1010)는 검증을 마친 후 번들을 삭제할 수 있다.
또한, 10025 단계에서 제 1 SSP(1010)는 "증명서"를 생성할 수 있다. 도 10 에서 이 증명서는 finalizationResponse라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationResponse는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 550에 제 1 SSP가 번들을 삭제했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 520에 제 1 SSP가 번들을 삭제한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- finalizationResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
또한, 가능한 증명서 구성의 다른 한 가지 예는 다음과 같다.
- finalizationResponse는 530에 수신한 finalizationRequest를 포함할 수 있다. 이 때, 수신한 finalizationRequest의 일부 정보는 필요에 의해 생략될 수 있다. 예를 들어, finalizationRequest에 포함되어 있는 제 2 SSP의 서명 정보는 경우에 따라 생략될 수 있다. 또한, 예를 들어, finalizationRequest에 포함되어 있는 시간 정보는 경우에 따라 생략될 수 있다.
- finalizationResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 550에 제 1 SSP가 번들을 삭제했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 520에 제 1 SSP가 번들을 삭제한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- finalizationResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 10을 참조하면, 10030 단계에서 제 1 SSP(1010)은 제 2 SSP(1060)에게 finalizationResponse를 전달할 수 있다. 예를 들어, 제 1 SSP(1010)은 제 1 LBA(1020)과 제 2 LBA(1070)을 거쳐 제 2 SSP(1060)에게 finalizationResponse를 전달할 수 있다.
도 10을 참조하면, 10035 단계에서 제 2 SSP(1060)은 수신한 finalizationResponse를 검증할 수 있다. 이 검증 과정은, finalizationResponse에 포함된 제 1 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 finalizationRequest가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 명령어 정보가 번들을 삭제하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 10035 단계에서 제 2 SSP(1060)는 검증을 마친 후 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제 2 SSP(1060)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
도 10을 참조하면, 10040 단계에서 제 2 SSP (1060)은 10035 단계에서 수행한 작업에 대한 결과 (예를 들어, 성공과 실패 여부)를 제 2 LBA(1070)에게 전송할 수 있다.
도 11은 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다. 보다 상세하게는, 도 11은 본 개시의 실시 예에 따른 번들의 전송이 이루어진 후, 단말에 번들이 설치되는 과정과 번들 상태 설정이 이루어지는 절차를 도시하는 도면의 또 다른 예시이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 11의 예에서와 같이, 제1 단말(1100)은 제1 LBA(1120)과 제1 SSP(1110)을 포함하고, 제2 단말(1150)은 제2 LBA(1170)과 제2 SSP(1160)을 포함할 수 있다. 일 예로, 제1 단말(1100)은 제1 SSP(1110)가 장착되고 제1 SSP(1110)을 제어하기 위한 제1 LBA(1120)이 설치된 단말일 수 있고, 제2 단말(1150)은 제2 SSP(1160)가 장착되고 제2 SSP(1160)을 제어하기 위한 제2 LBA(1170)이 설치된 단말일 수 있다.
1. 번들 설치
도 11을 참조하면, 11000 단계에서 제2 LBA(1170)과 제2 SSP(1160)은 서로 협업하여 제2 단말(1150)에 번들을 설치할 수 있다. 이에 대한 상세한 설명은 도 9의 "번들 설치" 과정을 참조한다.
2. 중복 사용 가능 여부 확인
또한, 도면에는 도시되지 않았지만, 제 2 LBA(1170) 및/또는 제 2 SSP(1160)는 해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부를 선택적으로 판단할 수 있다 이에 대한 상세한 설명은 도 9의 "중복 사용 가능 여부 확인" 과정을 참조한다.
3. 번들 상태 설정
만약 해당 번들이 복수의 단말에서 중복 사용이 가능하지 않은 번들로 판단된 경우 아래와 같이 번들의 상태를 추가적으로 설정한다. 혹은, 제 2 LBA(1170) 및/또는 제 2 SSP(1160)가 해당 번들의 중복 사용 여부를 판단하지 않는 경우에도, 제 2 LBA(1170) 및/또는 제 2 SSP(1160)의 구현에 따라 아래와 같이 번들의 상태를 추가적으로 설정하는 과정이 수행될 수 있다.
도 11을 참조하면, 11005 단계에서 제 2 SSP(1160)은 해당 번들의 상태를 "IN TRANSITION"으로 설정할 수 있다. "IN TRANSITION" 상태에 대한 설명은 10005 단계의 설명을 참조한다.
도 11을 참조하면, 11010 단계에서 제 2 LBA(1170)은 제 2 SSP(1160)에게 "증명서"를 요청할 수 있다.
도 11을 참조하면, 11015 단계에서 제 2 SSP(1160)은 "증명서"를 생성할 수 있다. 도 11 에서 이 증명서는 finalizationRequest라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationRequest는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationRequest는 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationRequest는 550에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- finalizationRequest는 520에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- finalizationRequest는 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 11을 참조하면, 11020 단계에서 제 2 SSP(1160)은 제 1 SSP(1110)에게 finalizationRequest를 전달할 수 있다. 예를 들어, 제 2 SSP(1160)은 제 1 SSP(1110)에게 다음과 같은 과정을 거쳐 finalizationRequest를 전달할 수 있다. 즉, 제 2 SSP(1160)은 제 2 LBA (1170) 에게 11010 단계의 응답으로 finalizationRequest를 전달하고, 제 2 LBA는 제 1 LBA(1120)을 거쳐 제 1 SSP 에게 finalizationRequest를 전달할 수 있다.
도 11을 참조하면, 11025 단계에서 제 1 SSP(1110)은 수신한 finalizationRequest를 검증할 수 있다. 이 검증 과정은, finalizationRequest에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationRequest에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자인지를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 명령어 정보가 번들의 상태를 “IN TRANSITION” 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 11025 단계에서 제 1 SSP(1110)는 검증을 마친 후 번들의 상태를 "IN TRANSITION" 상태로 설정할 수 있다.
또한, 11025 단계에서 제 1 SSP(1110)는 "증명서"를 생성할 수 있다. 도 11 에서 이 증명서는 finalizationResponse라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationResponse는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 550에 제 1 SSP가 번들의 상태를 "IN TRANSITION" 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 520에 제 1 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- finalizationResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
또한, 가능한 증명서 구성이 다른 한 가지 예는 다음과 같다.
- finalizationResponse는 530에 수신한 finalizationRequest를 포함할 수 있다. 이 때, 수신한 finalizationRequest의 일부 정보는 필요에 의해 생략될 수 있다. 예를 들어, finalizationRequest에 포함되어 있는 제 2 SSP의 서명 정보는 경우에 따라 생략될 수 있다. 또한, 예를 들어, finalizationRequest에 포함되어 있는 시간 정보는 경우에 따라 생략될 수 있다.
- finalizationResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 550에 제 1 SSP가 번들의 상태를 "IN TRANSITION" 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 520에 제 1 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- finalizationResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 11을 참조하면, 11030 단계에서 제 1 SSP(1110)은 제 2 SSP(1160)에게 finalizationResponse를 전달할 수 있다. 예를 들어, 제 1 SSP(1110)은 제 1 LBA(1120)과 제 2 LBA(1170)을 거쳐 제 2 SSP(1160)에게 finalizationResponse를 전달할 수 있다.
도 11을 참조하면, 11035 단계에서 제 2 SSP(1160)은 수신한 finalizationResponse를 검증할 수 있다. 이 검증 과정은, finalizationResponse에 포함된 제 1 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 finalizationRequest가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 명령어 정보가 올바른 것인지 확인하는 과정을 더 포함할 수 있다.
또한, 11035 단계에서 제 2 SSP(1160)는 검증을 마친 후 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제 2 SSP(1160)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
또한, 11035 단계에서 제 2 SSP(1160)는 "증명서"를 생성할 수 있다. 도 10 에서 이 증명서는 spblAttestation 이라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- spblAttestation은 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- spblAttestation은 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- spblAttestation은 550에 제 2 SSP가 번들의 상태를 사용 가능한 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- spblAttestation은 520에 제 2 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- spblAttestation은 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
또한, 가능한 증명서 구성이 다른 한 가지 예는 다음과 같다.
- spblAttestation은 530에 수신한 finalizationResponse를 포함할 수 있다. 이 때, 수신한 finalizationResponse의 일부 정보는 필요에 의해 생략될 수 있다. 예를 들어, finalizationResponse에 포함되어 있는 서명 정보의 일부는 경우에 따라 생략될 수 있다. 또한, 예를 들어, finalizationResponse에 포함되어 있는 시간 정보의 일부는 경우에 따라 생략될 수 있다.
- spblAttestation은 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- spblAttestation은 550에 제 2 SSP가 번들의 상태를 사용 가능한 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- spblAttestation은 520에 제 2 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- spblAttestation은 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 11을 참조하면, 11040 단계에서 제 2 SSP(1160)은 제 1 SSP(1110)에게 spblAttestation을 전달할 수 있다. 예를 들어, 제 2 SSP(1160)은 제 2 LBA (1170)와 제 1 LBA(1120)을 거쳐 제 1 SSP 에게 spblAttestation을 전달할 수 있다.
도 11을 참조하면, 11045 단계에서 제 1 SSP(1110)은 수신한 spblAttestation을 검증할 수 있다. 이 검증 과정은, spblAttestation에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, spblAttestation에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은, spblAttestation에 포함된 finalizationResponse가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은 spblAttestation에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자인지를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 spblAttestation에 포함된 명령어 정보가 번들의 상태를 사용 가능한 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 11045 단계에서 제 1 SSP(1110)는 검증을 마친 후 번들을 삭제할 수 있다.
도 12는 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다. 보다 상세하게는, 도 12는 본 개시의 실시 예에 따른 번들의 전송이 이루어진 후, 단말에 번들이 설치되는 과정과 번들 상태 설정이 이루어지는 절차를 도시하는 도면의 또 다른 예시이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 12의 예에서와 같이, 제1 단말(1200)은 제1 LBA(1220)과 제1 SSP(1210)을 포함하고, 제2 단말(1250)은 제2 LBA(1270)과 제2 SSP(1260)을 포함할 수 있다. 일 예로, 제1 단말(1200)은 제1 SSP(1210)가 장착되고 제1 SSP(1210)을 제어하기 위한 제1 LBA(1220)이 설치된 단말일 수 있고, 제2 단말(1250)은 제2 SSP(1260)가 장착되고 제2 SSP(1260)을 제어하기 위한 제2 LBA(1270)이 설치된 단말일 수 있다.
1. 번들 설치
도 12를 참조하면, 12000 단계에서 제2 LBA(1270)과 제2 SSP(1260)은 서로 협업하여 제2 단말(1250)에 번들을 설치할 수 있다. 이에 대한 상세한 설명은 도 9의 "번들 설치" 과정을 참조한다.
2. 중복 사용 가능 여부 확인
또한, 도면에는 도시되지 않았지만, 제 2 LBA(1270) 및/또는 제 2 SSP(1260)는 해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부를 선택적으로 판단할 수 있다 이에 대한 상세한 설명은 도 9의 "중복 사용 가능 여부 확인" 과정을 참조한다.
3. 번들 상태 설정
만약 해당 번들이 복수의 단말에서 중복 사용이 가능하지 않은 번들로 판단된 경우 아래와 같이 번들의 상태를 추가적으로 설정한다. 혹은, 제 2 LBA(1270) 및/또는 제 2 SSP(1260)가 해당 번들의 중복 사용 여부를 판단하지 않는 경우에도, 제 2 LBA(1270) 및/또는 제 2 SSP(1260)의 구현에 따라 아래와 같이 번들의 상태를 추가적으로 설정하는 과정이 수행될 수 있다.
도 12를 참조하면, 12005 단계에서 제 2 SSP(1260)은 해당 번들의 상태를 "IN TRANSITION"으로 설정할 수 있다. "IN TRANSITION" 상태에 대한 설명은 10005 단계의 설명을 참조한다.
도 12를 참조하면, 12010 단계에서 제 2 LBA(1270)은 제 2 SSP(1260)에게 "증명서"를 요청할 수 있다.
도 12를 참조하면, 12015 단계에서 제 2 SSP(1260)은 "증명서"를 생성할 수 있다. 도 12 에서 이 증명서는 finalizationRequest라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationRequest는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationRequest는 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationRequest는 550에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- finalizationRequest는 520에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- finalizationRequest는 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 12를 참조하면, 12020 단계에서 제 2 SSP(1260)은 제 1 SSP(1210)에게 finalizationRequest를 전달할 수 있다. 예를 들어, 제 2 SSP(1260)은 제 1 SSP(1210)에게 다음과 같은 과정을 거쳐 finalizationRequest를 전달할 수 있다. 즉, 제 2 SSP(1260)은 제 2 LBA (1270) 에게 12010 단계의 응답으로 finalizationRequest를 전달하고, 제 2 LBA는 제 1 LBA(1220)을 거쳐 제 1 SSP 에게 finalizationRequest를 전달할 수 있다.
도 12를 참조하면, 12025 단계에서 제 1 SSP(1210)은 수신한 finalizationRequest를 검증할 수 있다. 이 검증 과정은, finalizationRequest에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationRequest에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자인지를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 명령어 정보가 번들의 상태를 “IN TRANSITION” 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 12025 단계에서 제 1 SSP(1210)는 검증을 마친 후 번들의 상태를 "SUSPENSION" 상태로 설정할 수 있다. "SUSPENSION"은 번들 사용이 불가한 상태(또한, '다른 단말의 요청 (예를 들면, recoveryRequest 를 송신함으로써 이루어지는 요청)' 및/또는 '(본 개시에서는 설명되지 않았지만) 외부 서버의 요청' 에 의해서만 사용 가능한 상태 (Disabled, Enable, Active 상태)로 변경될 수 있는 상태)를 의미한다. 또한, 도면에 도시되지는 않았지만, 상기에 기술된 "SUSPENSION" 상태는 "IN TRANSITION" 상태로 대체될 수도 있다.
또한, 12025 단계에서 제 1 SSP(1210)는 "증명서"를 생성할 수 있다. 도 12 에서 이 증명서는 finalizationResponse라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationResponse는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 550에 제 1 SSP가 번들의 상태를 "SUSPENSION" (혹은, IN TRANSITION) 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 520에 제 1 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- finalizationResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
또한, 가능한 증명서 구성의 다른 한 가지 예는 다음과 같다.
- finalizationResponse는 530에 수신한 finalizationRequest를 포함할 수 있다. 이 때, 수신한 finalizationRequest의 일부 정보는 필요에 의해 생략될 수 있다. 예를 들어, finalizationRequest에 포함되어 있는 제 2 SSP의 서명 정보는 경우에 따라 생략될 수 있다. 또한, 예를 들어, finalizationRequest에 포함되어 있는 시간 정보는 경우에 따라 생략될 수 있다.
- finalizationResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 550에 제 1 SSP가 번들의 상태를 "SUSPENSION" (혹은, IN TRANSITION) 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 520에 제 1 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- finalizationResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 12를 참조하면, 12030 단계에서 제 1 SSP(1210)은 제 2 SSP(1260)에게 finalizationResponse를 전달할 수 있다. 예를 들어, 제 1 SSP(1210)은 제 1 LBA(1220)과 제 2 LBA(1270)을 거쳐 제 2 SSP(1260)에게 finalizationResponse를 전달할 수 있다.
도 12를 참조하면, 12035 단계에서 제 2 SSP(1260)은 수신한 finalizationResponse를 검증할 수 있다. 이 검증 과정은, finalizationResponse에 포함된 제 1 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 finalizationRequest가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 명령어 정보가 올바른 것인지 확인하는 과정을 더 포함할 수 있다.
또한, 12035 단계에서 제 2 SSP(1260)는 검증을 마친 후 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제 2 SSP(1260)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
도 12를 참조하면, 12040 단계에서 제 2 SSP (1260)은 12035 단계에서 수행한 작업에 대한 결과 (예를 들어, 성공과 실패 여부)를 제 2 LBA(1270)에게 전송할 수 있다.
도 13은 사용이 중지되었던 번들을 다시 사용 가능하도록 만드는 절차의 예를 도시하는 도면이다. 보다 상세하게는 "IN TRANSITION" 상태나 "SUSPENSION" 상태에 있는 번들을 다시 사용 가능한 상태로 설정하는 절차를 도시하는 도면의 한 가지 예시이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 13의 예에서와 같이, 제1 단말(1300)은 제1 LBA(1320)과 제1 SSP(1310)을 포함하고, 제2 단말(1350)은 제2 LBA(1370)과 제2 SSP(1360)을 포함할 수 있다. 일 예로, 제1 단말(1300)은 제1 SSP(1310)가 장착되고 제1 SSP(1310)을 제어하기 위한 제1 LBA(1320)이 설치된 단말일 수 있고, 제2 단말(1350)은 제2 SSP(1360)가 장착되고 제2 SSP(1360)을 제어하기 위한 제2 LBA(1370)이 설치된 단말일 수 있다.
도 13 에서 개시된 절차가 수행되기 전 번들의 상태가 "IN TRANSITION" 상태나 "SUSPENSION" 상태로 설정되어 있는 경우의 가능한 예는 다음과 같다. 예를 들어, 도 11에 개시된 번들의 전송이 마무리되는 단계에서, 11025 단계가 수행되었으나 11045 단계가 수행되지 않은 경우, 제1 단말(1300)에 있는 번들의 상태는 "IN TRANSITION" 상태로 설정되어 있을 것이다. 또 다른 예로, 도 12에 개시된 번들의 전송이 마무리되는 단계에서, 12025 단계가 수행되었다면, 제1 단말(1300)에 있는 번들의 상태는 "IN TRANSITION" 상태 혹은 "SUSPENSION" 상태로 설정되어 있을 것이다.
도 13을 참조하면, 13000 단계에서 사용 재개를 요청할 번들의 정보가 제2 LBA(1370)에 전달될 수 있다. 이 전달 과정은 제2 단말(1350)이 제공하는 UI를 통해 사용자가 직접 번들을 선택하는 과정을 통해 이루어질 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 제2 LBA(1370)에게 입력될 수도 있으며, 또는 제2 LBA(1370)가 원격 서버에 접속하여 해당 정보를 읽어올 수도 있다.
도 13을 참조하면, 13005 단계에서 13000 단계에서 선택된 번들의 정보가 제2 LBA(1370)로부터 제 2 SSP(1360)에게 전달될 수 있다. 이 때, 제2 LBA(1370)로부터 제2 SSP(1360)로 전달되는 정보는 13000 단계에서 선택되었던 번들을 식별(identify)하기 위한 정보를 포함할 수 있다.
도 13을 참조하면, 13010 단계에서 제2 SSP(1360)는 해당 번들을 삭제할 수 있다. 또한, 제2 SSP(1360)는 "증명서"를 생성할 수 있다. 도 13 에서 이 증명서는 recoveryRequest라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- recoveryRequest는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- recoveryRequest는 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- recoveryRequest는 550에 제 2 SSP가 번들을 삭제했음을 의미하는 정보를 포함할 수 있다.
- recoveryRequest는 520에 제 2 SSP가 번들을 삭제한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- recoveryRequest는 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 13을 참조하면, 13015 단계에서 제2 SSP(1360)는 제1 SSP(1310)에게 recoveryRequest를 전달할 수 있다. 예를 들어, 제2 SSP(1360)는 제1 SSP(1310)에게 다음과 같은 과정을 거쳐 recoveryRequest를 전달할 수 있다. 즉, 제2 SSP(1360)는 제2 LBA(1370)에게 13005 단계의 응답으로 recoveryRequest를 전달하고, 제2 LBA(1370)는 제1 LBA(1320)를 거쳐 제1 SSP(1310) 에게 recoveryRequest를 전달할 수 있다.
도 13을 참조하면, 13020 단계에서 제1 SSP(1310)는 수신한 recoveryRequest를 검증할 수 있다. 이 검증 과정은, recoveryRequest에 포함된 제 2 SSP(1360)의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, recoveryRequest에 포함된 "번들 구분자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 recoveryRequest에 포함된 "SSP 식별자"를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 recoveryRequest에 포함된 명령어 정보가 번들을 삭제하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 13020 단계에서 제1 SSP(1310)는 검증을 마친 후 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제1 SSP(1310)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
도 13을 참조하면, 13025 단계에서 제1 SSP(1310)는 13020 단계에서 수행한 작업에 대한 결과 (예를 들어, 성공과 실패 여부)를 제1 LBA(1320)에게 전송할 수 있다.
도 14는 사용이 중지되었던 번들을 다시 사용 가능하도록 만드는 또 다른 절차의 예를 도시하는 도면이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 14의 예에서와 같이, 제1 단말(1400)은 제1 LBA(1420)과 제1 SSP(1410)을 포함하고, 제2 단말(1450)은 제2 LBA(1470)과 제2 SSP(1460)을 포함할 수 있다. 일 예로, 제1 단말(1400)은 제1 SSP(1410)가 장착되고 제1 SSP(1410)을 제어하기 위한 제1 LBA(1420)이 설치된 단말일 수 있고, 제2 단말(1450)은 제2 SSP(1460)가 장착되고 제2 SSP(1460)을 제어하기 위한 제2 LBA(1470)이 설치된 단말일 수 있다.
도 14 에서 개시된 절차가 수행되기 전 번들의 상태가 "IN TRANSITION" 상태나 "SUSPENSION" 상태로 설정되어 있는 경우의 가능한 예는 다음과 같다. 예를 들어, 도 11에 개시된 번들의 전송이 마무리되는 단계에서, 11025 단계가 수행되었으나 11045 단계가 수행되지 않은 경우, 제1 단말(1400)에 있는 번들의 상태는 "IN TRANSITION" 상태로 설정되어 있을 것이다. 또 다른 예로, 도 12에 개시된 번들의 전송이 마무리되는 단계에서, 12025 단계가 수행되었다면, 제1 단말(1400)에 있는 번들의 상태는 "IN TRANSITION " 상태 혹은 "SUSPENSION" 상태로 설정되어 있을 것이다.
도 14를 참조하면, 14000 단계에서 사용 재개를 요청할 번들의 정보가 제2 LBA(1470)에 전달될 수 있다. 이 전달 과정은 제2 단말(1450)이 제공하는 UI를 통해 사용자가 직접 번들을 선택하는 과정을 통해 이루어질 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 제2 LBA(1470)에게 입력될 수도 있으며, 또는 제2 LBA(1470)가 원격 서버에 접속하여 해당 정보를 읽어올 수도 있다.
도 14를 참조하면, 14005 단계에서 14000 단계에서 선택된 번들의 정보가 제2 LBA(1470)로부터 제 2 SSP(1460)에게 전달될 수 있다. 이 때, 제2 LBA(1470)로부터 제2 SSP(1460)로 전달되는 정보는 14000 단계에서 선택되었던 번들을 식별(identify)하기 위한 정보를 포함할 수 있다.
도 14를 참조하면, 14010 단계에서 제2 SSP(1460)는 해당 번들의 상태를 "IN TRANSITION" 상태로 설정할 수 있다. 또한, 제2 SSP(1460)는 해당 번들의 상태 변경과 관련된 "증명서"를 생성할 수 있다. 도 14 에서 이 증명서는 recoveryRequest라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- recoveryRequest는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- recoveryRequest는 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- recoveryRequest는 550에 제 2 SSP가 번들의 상태를 "IN TRANSITION" 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- recoveryRequest는 520에 제 2 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- recoveryRequest는 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 14를 참조하면, 14015 단계에서 제2 SSP(1460)는 제1 SSP(1410)에게 recoveryRequest를 전달할 수 있다. 예를 들어, 제2 SSP(1460)는 제1 SSP(1410)에게 다음과 같은 과정을 거쳐 recoveryRequest를 전달할 수 있다. 즉, 제2 SSP(1460)는 제2 LBA(1470)에게 14005 단계의 응답으로 recoveryRequest를 전달하고, 제2 LBA(1470)는 제1 LBA(1420)를 거쳐 제1 SSP(1410) 에게 recoveryRequest를 전달할 수 있다.
도 14를 참조하면, 14020 단계에서 제1 SSP(1410)는 수신한 recoveryRequest를 검증할 수 있다. 이 검증 과정은, recoveryRequest에 포함된 제 2 SSP(1460)의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, recoveryRequest에 포함된 "번들 구분자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 recoveryRequest에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 recoveryRequest에 포함된 명령어 정보가 번들의 상태를 "IN TRANSITION"상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 14020 단계에서 제1 SSP(1410)는 검증을 마친 후 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제1 SSP(1410)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
또한, 14020 단계에서 제1 SSP(1410)는 "증명서"를 생성할 수 있다. 도 14 에서 이 증명서는 recoveryResponse라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- recoveryResponse는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- recoveryResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- recoveryResponse는 550에 제 1 SSP가 번들의 상태를 사용 가능한 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- recoveryResponse는 520에 제 1 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- recoveryResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
또한, 가능한 증명서 구성의 다른 한 가지 예는 다음과 같다.
- recoveryResponse는 530에 수신한 recoveryRequest를 포함할 수 있다. 이 때, 수신한 recoveryRequest의 일부 정보는 필요에 의해 생략될 수 있다. 예를 들어, recoveryRequest에 포함되어 있는 제 2 SSP의 서명 정보는 경우에 따라 생략될 수 있다. 또한, 예를 들어, recoveryRequest에 포함되어 있는 시간 정보는 경우에 따라 생략될 수 있다.
- recoveryResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- recoveryResponse는 550에 제 1 SSP가 번들의 상태를 사용 가능한 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- recoveryResponse는 520에 제 1 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- recoveryResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 14를 참조하면, 14025 단계에서 제1 SSP(1410)는 제2 SSP(1460)에게 recoveryResponse를 전달할 수 있다. 예를 들어, 제 1 SSP(1410)는 제1 LBA(1420)와 제 2 LBA(1470)를 거쳐 제 2 SSP(1460)에게 recoveryResponse를 전달할 수 있다.
도 14를 참조하면, 14030 단계에서 제2 SSP(1460)는 수신한 recoveryResponse를 검증할 수 있다. 이 검증 과정은, recoveryResponse에 포함된 제 1 SSP(1460)의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, recoveryResponse에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은, recoveryResponse에 포함된 recoveryRequest가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은 recoveryResponse에 포함된 "SSP 식별자" 를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 recoveryResponse에 포함된 명령어 정보가 올바른 명령어 정보인지 확인하는 과정을 더 포함할 수 있다.
또한, 14030 단계에서 제 2 SSP(1460)는 검증을 마친 후 번들을 삭제할 수 있다.
도 14를 참조하면, 14035 단계에서 제2 SSP(1460)는 14030 단계에서 수행한 작업에 대한 결과 (예를 들어, 성공과 실패 여부)를 제2 LBA(1470)에게 전송할 수 있다.
도 15는 사용이 중지되었던 번들을 다시 사용 가능하도록 만드는 또 다른 절차의 예를 도시하는 도면이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 15의 예에서와 같이, 제1 단말(1500)은 제1 LBA(1520)과 제1 SSP(1510)을 포함하고, 제2 단말(1550)은 제2 LBA(1570)과 제2 SSP(1560)을 포함할 수 있다. 일 예로, 제1 단말(1500)은 제1 SSP(1510)가 장착되고 제1 SSP(1510)을 제어하기 위한 제1 LBA(1520)이 설치된 단말일 수 있고, 제2 단말(1550)은 제2 SSP(1560)가 장착되고 제2 SSP(1560)을 제어하기 위한 제2 LBA(1570)이 설치된 단말일 수 있다.
도 15에서 개시된 절차가 수행되기 전 번들의 상태가 "IN TRANSITION" 상태나 "SUSPENSION" 상태로 설정되어 있는 경우의 가능한 예는 다음과 같다. 예를 들어, 도 11에 개시된 번들의 전송이 마무리되는 단계에서, 11025 단계가 수행되었으나 11045 단계가 수행되지 않은 경우, 제1 단말(1500)에 있는 번들의 상태는 "IN TRANSITION" 상태로 설정되어 있을 것이다. 또 다른 예로, 도 12에 개시된 번들의 전송이 마무리되는 단계에서, 12025 단계가 수행되었다면, 제1 단말(1500)에 있는 번들의 상태는 "IN TRANSITION " 상태 혹은 "SUSPENSION" 상태로 설정되어 있을 것이다.
도 15를 참조하면, 15000 단계에서 사용 재개를 요청할 번들의 정보가 제2 LBA에 전달될 수 있다. 이 전달 과정은 제2 단말(1550)이 제공하는 UI를 통해 사용자가 직접 번들을 선택하는 과정을 통해 이루어질 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 제2 LBA(1570)에게 입력될 수도 있으며, 또는 제2 LBA(1570)가 원격 서버에 접속하여 해당 정보를 읽어올 수도 있다.
도 15를 참조하면, 15005 단계에서 15000 단계에서 선택된 번들의 정보가 제2 LBA(1570)로부터 제 2 SSP(1560)에게 전달될 수 있다. 이 때, 제2 LBA(1570)로부터 제2 SSP(1560)로 전달되는 정보는 15000 단계에서 선택되었던 번들을 식별(identify)하기 위한 정보를 포함할 수 있다.
도 15를 참조하면, 15010 단계에서 제2 SSP(1560)는 해당 번들의 상태를 "SUSPENSION"으로 변경할 수 있다. 이때, 도면에는 도시되지 않았지만 상기에 기술된 "SUSPENSION" 상태는 "IN TRANSITION" 상태로 대체될 수 있다.
또한, 제2 SSP(1560)는 "증명서"를 생성할 수 있다. 도 15 에서 이 증명서는 recoveryRequest라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- recoveryRequest는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- recoveryRequest는 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- recoveryRequest는 550에 제 2 SSP가 번들의 상태를 "SUSPENSION"이나 "IN TRANSITION"으로 변경했음을 의미하는 정보를 포함할 수 있다.
- recoveryRequest는 520에 제 2 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다.
- recoveryRequest는 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 15를 참조하면, 15015 단계에서 제2 SSP(1560)는 제1 SSP(1510)에게 recoveryRequest를 전달할 수 있다. 예를 들어, 제2 SSP(1560)는 제1 SSP(1510)에게 다음과 같은 과정을 거쳐 recoveryRequest를 전달할 수 있다. 즉, 제2 SSP(1560)는 제2 LBA(1570)에게 15005 단계의 응답으로 recoveryRequest를 전달하고, 제2 LBA(1570)는 제1 LBA(1520)를 거쳐 제1 SSP(1510) 에게 recoveryRequest를 전달할 수 있다.
도 15를 참조하면, 15020 단계에서 제1 SSP(1510)는 수신한 recoveryRequest를 검증할 수 있다. 이 검증 과정은, recoveryRequest에 포함된 제 2 SSP(1560)의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, recoveryRequest에 포함된 "번들 구분자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 recoveryRequest에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 recoveryRequest에 포함된 명령어 정보가 번들의 상태를 올바로 변경하는 것인지 확인하는 과정을 더 포함할 수 있다.
또한, 15020 단계에서 제1 SSP(1510)는 검증을 마친 후 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제1 SSP(1510)는 번들의 상태를 Disabled 상태로 변경할 수 있다.
도 15를 참조하면, 15025 단계에서 제1 SSP(1510)는 15020 단계에서 수행한 작업에 대한 결과 (예를 들어, 성공과 실패 여부)를 제1 LBA(1520)에게 전송할 수 있다.
도 16은 본 개시의 실시 예에 따른 단말의 구성을 도시하는 도면이다.
도 16 에서 도시된 바와 같이, 단말은 송수신부(Transceiver)(1610) 및 적어도 하나의 프로세서(1620)를 포함할 수 있다. 또한, 단말은 SSP(1630)를 더 포함할 수 있다. 예를 들면, SSP(1630)는 단말에 삽입될 수 있고, 단말에 내장될 수도 있다. 상기 적어도 하나 이상의 프로세서(1620)는 '제어부'로 명명할 수도 있다. 다만, 단말의 구성은 도 16에 제한되지 않으며, 도 16에 도시된 구성 요소들보다 더 많은 구성 요소를 포함하거나, 더 적은 구성 요소를 포함할 수도 있다. 일부 실시예에 따르면, 송수신부(1610), 적어도 하나의 프로세서(1620) 및 메모리(미도시)는 하나의 칩(Chip) 형태로 구현될 수 있다. 또한, SSP(1630)가 내장되는 경우, SSP(1630)를 포함하여, 하나의 칩 형태로 구현될 수 있다.
다양한 실시예에 따르면, 송수신부(1610)는 다른 단말의 송수신부 혹은 외부 서버와 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다. 송수신부(1610)는 송신되는 신호의 주파수를 상승 변환(up converting) 및 증폭하는 RF 송신기와, 수신되는 신호를 저 잡음 증폭하고 주파수를 하강 변환(down converting)하는 RF 수신기 등으로 구성될 수 있다. 다만, 이는 송수신부(1610)의 일 실시예일뿐이며, 송수신부(1610)의 구성요소가 RF 송신기 및 RF 수신기에 한정되는 것은 아니다. 또한, 송수신부(1610)는 무선 채널을 통해 신호를 수신하여 적어도 하나의 프로세서(1620)로 출력하고, 적어도 하나의 프로세서(1620)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다.
다양한 실시예에 따르면, 송수신부(1610)는 다른 단말의 송수신부 혹은 외부 서버로부터 다른 단말에 포함된 SSP의 정보, 다른 단말을 인증할 수 있는 인증 정보, 자신을 인증할 수 있는 인증 정보, 번들 이동 코드, 번들 이동 설정, 번들, 도 10 내지 도 15에서 기술된 다양한 증명서 등을 송신하거나 수신할 수 있다.
한편, 적어도 하나의 프로세서(1620)는 단말을 전반적으로 제어하기 위한 구성요소이다. 적어도 하나의 프로세서(1620)는 전술한 바와 같은 본 개시의 다양한 실시 예에 따라, 단말의 전반적인 동작을 제어할 수 있다.
한편, SSP(1630)는 번들을 설치하고 제어하기 위한 프로세서 또는 컨트롤러를 포함하거나, 어플리케이션이 설치되어 있을 수 있다.
다양한 실시예에 따르면, SSP(1630) 내의 적어도 하나의 프로세서 또는 컨트롤러는 번들 이동 설정을 확인하여 특정 번들의 전송 여부를 결정할 수 있다. 또한, 번들 이동 설정을 확인하여 해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부를 확인할 수 있다.
또한, 다양한 실시예에 따르면 SSP 내의 적어도 하나 이상의 프로세서 또는 컨트롤러는 번들 이동 코드를 생성하여 특정 번들의 전송 과정을 제어할 수 있다.
또한, 다양한 실시예에 따르면 SSP 내의 적어도 하나 이상의 프로세서 또는 컨트롤러는 자신의 SSP 정보를 생성할 수 있고, 외부로부터 전송 받은 다른 SSP의 SSP 정보를 확인하고 검증할 수 있다.
또한, 다양한 실시예에 따르면 SSP 내의 적어도 하나 이상의 프로세서 또는 컨트롤러는 자신을 검증할 수 있는 인증 정보를 생성할 수 있고, 외부로부터 전송 받은 다른 SSP의 인증 정보를 검증할 수도 있다.
또한, 다양한 실시예에 따르면 SSP(1330)는 번들을 생성할 수 있고, 단독 혹은 하나 이상의 프로세서 (1620)와 협력하여 번들을 설치할 수 있다. 또한, SSP(1630)는 번들을 관리할 수 있다.
또한, 다양한 실시예에 따르면 SSP(1630)은 도 10 내지 도 15에서 기술된 다양한 형태의 증명서를 생성할 수 있고, 수신된 증명서를 검증할 수 있다.
또한, 다양한 실시예에 따르면 SSP(1630)은 도 10 내지 도 15에서 기술된 것처럼 수신된 증명서의 내용을 기반으로 하여 번들의 상태를 변경할 수 있다.
또한, 다양한 실시예에 따르면, SSP(1630)는 프로세서(1620)의 제어에 따라 동작할 수도 있다. 또는 SSP(1630)는 번들을 설치하고 제어하기 위한 프로세서 또는 컨트롤러를 포함하거나, 어플리케이션이 설치되어 있을 수 있다. 어플리케이션의 일부 또는 전부는 SSP(1630) 또는 메모리(미도시)에 설치되어 있을 수도 있다.
한편, 단말은 메모리(미도시)를 더 포함할 수 있으며, 단말의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(Flash Memory Type), 하드 디스크 타입(Hard Disk Type), 멀티미디어 카드 마이크로 타입(Multimedia Card Micro Type), 카드 타입의 메모리(예를 들면, SD 또는 XD 메모리 등), 자기 메모리, 자기 디스크, 광디스크, 램(Random Access Memory, RAM), SRAM(Static Random Access Memory), 롬(Read-Only Memory, ROM), PROM(Programmable Read-Only Memory), EEPROM(Electrically Erasable Programmable Read-Only Memory) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서(1620)는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.
도 17은 도 6에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다. 보다 상세하게는, 도 17은 본 개시의 실시 예에 따른 번들의 전송이 이루어진 후, 단말에 번들이 설치되는 과정과 번들 상태 설정이 이루어지는 절차를 도시하는 도면의 또 다른 예시이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 17의 예에서와 같이, 제1 단말(1700)은 제1 LBA(1720)과 제1 SSP(1710)을 포함하고, 제2 단말(1750)은 제2 LBA(1770)과 제2 SSP(1760)을 포함할 수 있다. 일 예로, 제1 단말(1700)은 제1 SSP(1710)가 장착되고 제1 SSP(1710)을 제어하기 위한 제1 LBA(1720)이 설치된 단말일 수 있고, 제2 단말(1750)은 제2 SSP(1760)가 장착되고 제2 SSP(1760)을 제어하기 위한 제2 LBA(1770)이 설치된 단말일 수 있다.
1. 번들 설치
도 17을 참조하면, 17000 단계에서 제2 LBA(1770)과 제2 SSP(1760)은 서로 협업하여 제2 단말(1750)에 번들을 설치할 수 있다. 이에 대한 상세한 설명은 도 9의 "번들 설치" 과정을 참조한다.
2. 중복 사용 가능 여부 확인
또한, 도면에는 도시되지 않았지만, 제 2 LBA(1770) 및/또는 제 2 SSP(1760)는 해당 번들이 복수의 단말에서 중복 사용이 가능한지의 여부를 선택적으로 판단할 수 있다 이에 대한 상세한 설명은 도 9의 "중복 사용 가능 여부 확인" 과정을 참조한다.
3. 번들 상태 설정
만약 해당 번들이 복수의 단말에서 중복 사용이 가능하지 않은 번들로 판단된 경우 아래와 같이 번들의 상태를 추가적으로 설정한다. 혹은, 제 2 LBA(1770) 및/또는 제 2 SSP(1760)가 해당 번들의 중복 사용 여부를 판단하지 않는 경우에도, 제 2 LBA(1770) 및/또는 제 2 SSP(1760)의 구현에 따라 아래와 같이 번들의 상태를 추가적으로 설정하는 과정이 수행될 수 있다.
도 17을 참조하면, 17005 단계에서 제 2 SSP(1760)은 해당 번들의 상태를 "IN TRANSITION"으로 설정할 수 있다. "IN TRANSITION"은 번들이 성공적으로 설치되었지만 사용이 불가한 상태 (또한, '다른 단말의 요청 (예를 들면, finalizationResponse나 recoveryRequest 를 송신함으로서 이루어지는 요청)' 및/또는 '외부 서버의 요청'과 같은 추가 동작에 의해서만 사용 가능한 상태 (Disabled, Enable, Active 상태)로 변경될 수 있는 상태)를 의미한다.
도 17을 참조하면, 17010 단계에서 제 2 LBA(1770)은 제 2 SSP(1760)에게 "증명서"를 요청할 수 있다.
도 17을 참조하면, 17015 단계에서 제 2 SSP(1760)은 "증명서"를 생성할 수 있다. 도 17 에서 이 증명서는 finalizationRequest라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationRequest는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationRequest는 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationRequest는 550에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- finalizationRequest는 520에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 이후 전자 서명에 사용될 인증서의 정보를 선택적으로 더 포함할 수 있다.
- finalizationRequest는 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 17을 참조하면, 17020 단계에서 제 2 SSP(1760)은 제 1 SSP(1710)에게 finalizationRequest를 전달할 수 있다. 예를 들어, 제 2 SSP(1760)은 제 1 SSP(1710)에게 다음과 같은 과정을 거쳐 finalizationRequest를 전달할 수 있다. 즉, 제 2 SSP(1760)은 제 2 LBA (1770) 에게 17010 단계의 응답으로 finalizationRequest를 전달하고, 제 2 LBA는 제 1 LBA(1720)을 거쳐 제 1 SSP 에게 finalizationRequest를 전달할 수 있다.
도 17을 참조하면, 17025 단계에서 제 1 SSP(1710)은 수신한 finalizationRequest를 검증할 수 있다. 이 검증 과정은, finalizationRequest에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationRequest에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자 인지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 명령어 정보가 번들의 상태를 “IN TRANSITION” 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 17025 단계에서 제 1 SSP(1710)는 번들을 삭제할 수 있다.
또한, 17025 단계에서 제 1 SSP(1710)는 "증명서"를 생성할 수 있다. 도 17 에서 이 증명서는 finalizationResponse라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationResponse는 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 550에 제 1 SSP가 번들을 삭제했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 520에 제 1 SSP가 번들을 삭제한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 이후 전자 서명에 사용될 인증서의 정보를 선택적으로 더 포함할 수 있다.
- finalizationResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
또한, 가능한 증명서 구성이 다른 한 가지 예는 다음과 같다.
- finalizationResponse는 530에 finalizationRequest의 일부 및/또는 전체 데이터를 포함할 수 있다.
- finalizationResponse는 540에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 550에 제 1 SSP가 번들을 삭제했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 520에 제 1 SSP가 번들을 삭제한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 이후 전자 서명에 사용될 인증서의 정보를 선택적으로 더 포함할 수 있다.
- finalizationResponse는 560에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 17을 참조하면, 17030 단계에서 제 1 SSP(1710)은 제 2 SSP(1760)에게 finalizationResponse를 전달할 수 있다. 예를 들어, 제 1 SSP(1710)은 제 1 LBA(1720)과 제 2 LBA(1770)을 거쳐 제 2 SSP(1760)에게 finalizationResponse를 전달할 수 있다.
도 17을 참조하면, 17035 단계에서 제 2 SSP(1760)은 수신한 finalizationResponse를 검증할 수 있다. 이 검증 과정은, finalizationResponse에 포함된 제 1 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 finalizationRequest 의 일부 및/또는 전체 정보가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 명령어 정보가 번들을 삭제하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 17035 단계에서 제 2 SSP(1760)는 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제 2 SSP(1760)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
또한, 17035 단계에서 제 2 SSP(1760)는 "증명서"를 생성할 수 있다. 도 17 에서 이 증명서는 spblAttestation 이라 불릴 수 있다. 이 증명서의 구조는 도 5에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- spblAttestation은 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- spblAttestation은 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- spblAttestation은 550에 제 2 SSP가 번들의 상태를 사용 가능한 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- spblAttestation은 520에 제 2 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 이후 전자 서명에 사용될 인증서의 정보를 선택적으로 더 포함할 수 있다.
- spblAttestation은 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
또한, 가능한 증명서 구성의 다른 한 가지 예는 다음과 같다.
- spblAttestation은 530에 'finalizationRequest 및/또는 finalizationResponse' 의 일부 및/또는 전체 데이터를 포함할 수 있다.
- spblAttestation은 540에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- spblAttestation은 550에 제 2 SSP가 번들의 상태를 사용 가능한 상태로 변경했음을 의미하는 정보를 포함할 수 있다.
- spblAttestation은 520에 제 2 SSP가 번들의 상태를 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 이후 전자 서명에 사용될 인증서의 정보를 선택적으로 더 포함할 수 있다.
- spblAttestation은 560에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 17을 참조하면, 17040 단계에서 제 2 SSP(1760)은 제 1 SSP(1710)에게 spblAttestation을 전달할 수 있다. 예를 들어, 제 2 SSP(1760)은 제 2 LBA (1770)와 제 1 LBA(1720)을 거쳐 제 1 SSP(1710) 에게 spblAttestation을 전달할 수 있다.
도 17을 참조하면, 17045 단계에서 제 1 SSP(1710)은 수신한 spblAttestation을 검증할 수 있다. 이 검증 과정은, spblAttestation에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, spblAttestation에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은, spblAttestation에 포함된 finalizationRequest 및/또는 finalizationResponse 의 일부 및/또는 전체 정보가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은 spblAttestation에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자인지를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 spblAttestation에 포함된 명령어 정보가 번들의 상태를 사용 가능한 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 17045 단계에서 제 1 SSP(1710)는 finalizationResponse를 삭제할 수 있다.
17035 단계에서 spblAttestation 을 생성하는 단계 및/또는 17040 단계 및/또는 17045 단계는 필요에 따라 생략될 수 있다.
17020 단계 및/또는 17030 단계 및/또는 17040 단계에서 증명서 전송이 실패 시 해당 증명서는 상대 기기로 재전송될 수 있다.
이 때, 재전송은 기 설정되어 있는 최대 재전송 횟수만큼 시도될 수 있다. 혹은 해당 증명서가 상대 단말로 전송이 된 것을 확인할 때까지 반복되어 시도될 수 있다. 혹은 단말의 구현에 따라 해당 증명서가 삭제될 때까지 반복되어 재전송될 수도 있다. 예를 들어, finalizationResponse의 경우 17045 단계에서 삭제되기 전까지, 제 1 단말은 finalizationResponse의 재전송을 반복해 시도할 수 있다.
재전송을 시도 시 두 기기 간의 연결이 끊어진 상태라면 두 기기는 새로이 연결을 형성한 뒤 해당 증명서를 송수신할 수 있다. 이 때 두 단말은 과거 통신을 하며 송수신했던 기록들을 이용해, 새로이 수립될 연결의 대상을 선택 및/또는 검증할 수 있고, 새로이 연결이 수립된 상대와 어떠한 데이터를 송수신해야 하는지 결정할 수 있으며, 또한 상대 단말로부터 수신한 데이터의 유효성 및/또는 내용을 검증할 수 있다.
이때 재전송은 단말 내부의 동작에 의해 자동으로 개시될 수 있고, 외부 서버의 요청에 의해 개시될 수도 있으며, 혹은 사용자의 입력에 의하여 개시될 수도 있다.
도 18은 본 개시의 일부 실시 예에 따른 "증명서(Attestation)"의 구성을 도시하는 도면이다.
다양한 실시예에 따르면, 증명서는 “증명서 정보(Attestation Info)”를 선택적으로 포함할 수 있다(1810). 증명서 정보에 포함되는 데이터의 다양한 실례는 후에 기술될 도 22 내지 도 27 의 설명을 참조하기로 한다.
다양한 실시예에 따르면, 증명서는 "증명서를 발급한 주체의 식별자 (Issuer ID)"를 선택적으로 더 포함할 수 있다(1830). 증명서를 발급하는 주체의 다양한 실례는 후에 기술될 도 22 내지 도 27의 설명을 참조하기로 한다.
다양한 실시예에 따르면, 증명서는 “증명서 발급자가 수행한 동작에 대한 정보 (Command)”를 선택적으로 더 포함할 수 있다(1850). 증명서 발급자가 수행하는 동작의 다양한 실례는 후에 기술될 도 22 내지 도 27의 설명을 참조하기로 한다.
다양한 실시예에 따르면, 증명서는 앞서 기술한 정보 이외의 기타 데이터를 선택적으로 더 포함할 수 있다(1870). 증명서 안에 포함될 수 있는 기타 데이터의 다양한 실례는 후에 기술될 도 22 내지 도 27의 설명을 참조하기로 한다.
다양한 실시예에 따르면, 증명서는 앞서 기술한 정보들에 대한 전자 서명 데이터를 포함할 수 있다(1890). 이 서명 데이터는 증명서 발급자의 서명용 인증서에 의해 생성된 전자 서명일 수 있다.
도 19는 본 개시의 실시 예에 따른 하나의 단말에서 다른 단말로 번들이 전송되는 절차를 개념적으로 도시하는 도면이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 19의 예에서와 같이, 제1 단말(1900)은 제1 LBA(1920)과 제1 SSP(1910)을 포함하고, 제2 단말(1950)은 제2 LBA(1970)과 제2 SSP(1960)을 포함할 수 있다. 일 예로, 제1 단말(1900)은 제1 SSP(1910)가 장착되고 제1 SSP(1910)을 제어하기 위한 제1 LBA(1920)이 설치된 단말일 수 있고, 제2 단말(1950)은 제2 SSP(1960)가 장착되고 제2 SSP(1960)을 제어하기 위한 제2 LBA(1970)이 설치된 단말일 수 있다.
도 19를 참조하면, 19000 단계에서 제1 단말(1900)의 제1 SSP(1910), 제1 LBA(1920)과 제2 단말(1950)의 제2 LBA(1970) 는 번들 전송을 위해 필요한 준비 절차(번들 전송 준비 절차)를 수행할 수 있다. 상기 절차에 대한 보다 자세한 설명은 후술될 도 20의 상세 설명을 참조하기로 한다.
도 19를 참조하면, 19005 단계에서 제1 단말(1900)으로부터 제2 단말(1950)으로 번들이 전송되는 절차(번들 전송 절차)가 수행될 수 있다. 상기 절차에 대한 보다 자세한 설명은 후술될 도 21의 상세 설명을 참조하기로 한다.
도 19를 참조하면, 19010 단계에서 제1 단말(1900)과 제 2 단말(1960)은 전송된 번들의 설치 절차와 번들의 상태를 설정하는 절차 (번들 전송 마무리 절차)를 수행할 수 있다. 상기 절차에 대한 자세한 설명은 후술될 도 22, 도 24 및 도 26의 상세 설명을 참조하기로 한다.
도 20은 도 19에서 제시된 절차 중 번들 전송을 위해 준비하는 절차에 대한 세부 절차를 도시하는 도면이다. 보다 상세하게는, 도 20은 본 개시의 실시 예에 따른 하나의 단말이 다른 단말로 번들을 전송하기 위하여 필요한 준비 과정을 거치는 절차를 예시적으로 도시하는 도면이다. 본 명세서에서, 도 20의 절차는 번들 전송 준비 절차로 지칭될 수 있다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 20의 예에서와 같이, 제1 단말(2000)은 제1 LBA(2020)과 제1 SSP(2010)을 포함하고, 제2 단말(2050)은 제2 LBA(2070)과 제2 SSP(2060)을 포함할 수 있다. 일 예로, 제1 단말(2000)은 제1 SSP(2010)가 장착되고 제1 SSP(2010)을 제어하기 위한 제1 LBA(2020)이 설치된 단말일 수 있고, 제2 단말(2050)은 제2 SSP(2060)가 장착되고 제2 SSP(2060)을 제어하기 위한 제2 LBA(2070)이 설치된 단말일 수 있다.
다양한 실시예에 따르면, 제1 단말(2000)은 기 설치된 번들을 보유하고 있을 수 있으며, 이 번들과 연계된 메타데이터를 더 보유하고 있을 수 있다.
다양한 실시예에 따르면, 제1 단말(2000)은 해당 번들과 연계되어 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 또는 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나를 보유하고 있을 수 있다.
다양한 실시예에 따르면, 제1 단말(2000)은 해당 번들과 연계되어 '번들 이동 설정'을 보유하고 있을 수 있다. 번들 이동 설정은 해당 번들의 기기 간 전송 가능 여부와 관련된 정보를 선택적으로 포함하고 있을 수 있다.
또한, 번들 이동 설정은 해당 번들의 기기 간 전송 결과를 서버에 등록하는 과정에 대한 “등록 설정”을 선택적으로 더 포함하고 있을 수 있다. 가능한 “등록 설정”의 다양한 예시는 다음과 같다.
- 고지(Notification) 필요 여부: 기기 간 번들 전송 결과를 서버에 고지해야 하는지에 대한 설정
- 선 고지(Pre-notification) 필요 여부: 해당 번들이 하나의 기기에서 새로운 기기로 전송된 후 새로운 기기에서 사용되기 전 이 전송 내역이 서버에 고지 되어야 하는지, 혹은 이 전송 내역이 서버에 고지 되기 전 새로운 기기에서 사용될 수 있는지에 대한 설정
- 고지 내용의 암호화 필요 여부: 고지를 하는 과정에서 전송되는 데이터가 고지를 받는 서버와 고지를 하는 SSP 만이 내용을 볼 수 있도록 암호화될 필요가 있는지에 대한 설정
상기 “등록 설정”은 서비스 제공자에 의해 설정될 수도 있고, 번들 관리 서버에 의해 설정될 수도 있으며, 혹은 서비스 제공자와 번들 관리 서버의 협업에 의해 설정될 수도 있다. 또한, 이 번들 이동 설정은 번들 내부의 데이터로 포함될 수도 있고, 번들의 메타 데이터 안에 포함되어 있을 수도 있으며, 혹은 독립된 데이터로 존재할 수도 있다. 또한, 상기 번들 이동 설정은 서비스 제공자 및/또는 번들 관리 서버의 전자 서명을 포함하고 있을 수도 있다.
도 20을 참조하면, 20000 단계에서 기기 간 전송될 번들의 정보가 제1 LBA(2020)에 전달될 수 있다. 이 전달 과정은 예컨대, 도 20에 도시된 바와 같이, 제1 단말(2000)이 제공하는 UI를 통해 사용자가 직접 번들을 선택하는 과정을 통해 이루어질 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 제1 LBA(2020)에게 입력될 수도 있으며, 또는 제1 LBA(2020)이 원격 서버에 접속하여 해당 정보를 읽어올 수도 있다.
도 20을 참조하면, 20005 단계에서 20000 단계를 통해 선택된 번들에 관련된 정보가 제1 LBA(2020)로부터 제1 SSP(2010)으로 전달될 수 있다. 예컨대, 도 20에 도시된 바와 같이, 상기 선택된 번들에 관련된 정보가 Select SPB command를 통해 제1 LBA(2020)로부터 제1 SSP(2010)으로 전달될 수 있다. 이 때, 제1 LBA(2020)로부터 제1 SSP(2010)으로 전달되는 정보는 20000 단계에서 선택되었던 번들을 식별(identify)하기 위한 정보를 포함할 수 있다.
도 20을 참조하면, 20010 단계에서 제1 SSP(2010)은 전송을 요청 받은 번들의 기기 간 전송 가능 여부를 확인할 수 있다. 이 과정은 우선 20005 단계에서 수신한 정보에 기초하여 전송을 요청 받은 번들을 식별하고, 해당 번들과 연관된(associated with) '번들 이동 설정'을 확인함으로써 수행될 수 있다.
또한, 20010 단계에서 제1 SSP(2010)은 선택적으로 '번들 이동 코드'를 설정할 수 있다. '번들 이동 코드'는 해당 번들의 기기 간 전송 과정에서 해당 번들을 지칭하기 위해 사용되는 코드로서 해당 번들을 식별할 수 있는 값이어야 한다. 제1 SSP(2010)은 앞서 기술한 '번들 이동 코드'와 전송하려는 번들의 정보를 바인딩(binding)할 수 있다.
도 20을 참조하면, 20015 단계에서 20005 단계에 대한 응답 결과가 제1 SSP(2010)으로부터 제1 LBA(2020)으로 전송될 수 있다. 예컨대, 도 20에 도시된 바와 같이, Select SPB command에 대한 응답이 Select SPB response를 통해 제1 SPB(2010)로부터 제1 LBA(2020)으로 전달될 수 있다. 이 응답 값은 20010 단계에서 기술된 '번들 이동 코드'를 포함할 수 있다.
도 20을 참조하면, 20020 단계에서 기기 간 번들 전송을 위해 필요한 정보가 제1 단말 (2000)의 제1 LBA(2020)으로부터 제2 단말(2050)의 제2 LBA(2070)으로 전달될 수 있다. 이 때 제1 LBA(2020)으로부터 제2 LBA(2070)으로 전달되는 정보에는 '번들 이동 코드'가 포함될 수 있다. 또한, 제1 LBA(2020)으로부터 제2 LBA(2070)으로 전달되는 정보는 향후 20025 단계에서 제1 LBA(720)과 제2 LBA(2070) 사이에 수립될(established) 연결을 위해 필요한 정보들을 선택적으로 더 포함할 수 있다.
상술한 20020 단계를 통해 제1 LBA(2020)으로부터 제2 LBA (2070)으로 전달되는 정보들은 다양한 방법으로 전달될 수 있다. 예를 들면, 제1 LBA는 제2 LBA로 전달해야 할 정보를 제1 단말(2000)의 UI를 통해 사용자에게 제공할 수 있으며, 사용자는 제공받은 정보를 제2 단말(2050)의 UI를 이용해 제2 LBA에 입력할 수 있다. 혹은, 제1 LBA은 제2 LBA로 전달해야 할 정보를 이미지 (예를 들어 QR 코드)의 형태로 만들어 제1 단말의 화면에 표시하고, 사용자는 제2 단말(2050)를 이용해 이 이미지를 스캔함으로써 제2 LBA(2070)에 정보를 전달할 수 있다. 하지만 제1 LBA(2020)으로부터 제2 LBA(2070)으로 정보를 전달하는 방법은 상기의 방법들에 국한되지 않는다.
도 20을 참조하면, 20025 단계에서 제1 LBA(2020)과 제2 LBA(2070) 사이에 연결이 수립(또는, 설정)될 수 있다. 만일 20020 단계에서 연결을 위해 필요한 정보들이 전송되었다면, 제1 LBA(2020)과 제2 LBA(2070)는 이 정보를 이용해 연결을 수립할 수도 있다. 제1 LBA(2020)과 제2 LBA(2070)의 연결은 직접적인 기기 간 연결일 수도 있고 (예컨대, NFC, 블루투스, UWB, WiFi-Direct, LTE D2D(device-to-device), 5G D2D) 혹은 제1 LBA(2020)과 제2 LBA(2070) 사이에 원격 서버(가령, 릴레이 서버) 가 위치한 원거리 연결일 수도 있다.
도 20을 참조하면, 20025 단계는 마지막 단계로서 도시되었지만 이 단계는 전술한 다른 단계, 즉 20000 단계, 20005 단계, 20010 단계, 20015 단계, 20020 단계와는 독립적인 단계로서 다른 단계들과 순서에 구애되지 않고 수행될 수 있다. 예컨대, 20025 단계는 20015 단계와 20020 단계의 사이에서 수행될 수도 있으며, 이 경우 20020 단계에서 제1 LBA(2020)으로부터 제2 LBA 2(2070)으로 전송되는 정보는 20025 단계에서 수립된 연결을 통해 전송될 수도 있다.
도 21은 도 19에서 제시된 절차 중 번들의 전송이 이루어지는 절차에 대한 세부 절차를 도시하는 도면이다. 보다 상세하게는, 도 21은 본 개시의 실시 예에 따른 하나의 단말이 다른 단말로 번들을 전송하는 절차를 예시적으로 도시하는 도면이다. 본 개시에서 도 21의 절차는 번들 전송 절차로 지칭될 수 있다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 21의 예에서와 같이, 제1 단말(2100)은 제1 LBA(2120)과 제1 SSP(2110)을 포함하고, 제2 단말(2150)은 제2 LBA(2170)과 제2 SSP(2160)을 포함할 수 있다. 일 예로, 제1 단말(2100)은 제1 SSP(2110)가 장착되고 제1 SSP(2110)을 제어하기 위한 제1 LBA(2120)이 설치된 단말일 수 있고, 제2 단말(2150)은 제2 SSP(2160)가 장착되고 제2 SSP(2160)을 제어하기 위한 제2 LBA(2170)이 설치된 단말일 수 있다.
도 21을 참조하면, 21000 단계에서 제2 LBA(2170)은 제2 SSP 2(2160)에게 "SSP 정보 (SspInfo)"를 요청할 수 있다. 21000 단계에서 제2 LBA(2170)가 제2 SSP(2160)에게 "SSP 정보 (SspInfo)"를 요청할 때, 제2 LBA(2170)는 제2 SSP(2160)에게 기기 간 번들 이동이 수행될 것임을 알려줄 수 있다.
또한, 21000 단계는 도 21에서 도시했던 과정에 바로 이어서 자동으로 수행될 수도 있고, 외부의 입력을 받은 후 수행될 수도 있다. 이 때, '외부의 입력'은 제2 단말(2150)이 제공하는 UI를 통해 사용자가 직접 전송 받을 번들을 선택하는 과정을 통해 이루어질 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 제2 LBA(2170)에게 입력될 수도 있으며, 또는 제2 LBA(2170)이 원격 서버에 접속하여 해당 정보를 읽어올 수도 있다.
도 21을 참조하면, 21005 단계에서 제2 SSP(2160)는 자신의 "SSP 정보"를 생성할 수 있다. "SSP 정보"에는 번들 전송을 위해 제공되어야 하는 제2 SSP의 정보가 포함될 수 있다. 이때, "SSP 정보"에는 제2 SSP(2160)가 번들을 수신하기 전 거쳐야 할 인증서 협상 과정을 위한 정보(인증서 협상 정보)가 포함될 수 있다. 이 "인증서 협상 정보"는 제2 SSP(2160)가 다른 SSP를 검증하는데 이용할 수 있는 인증서 정보들(SenderSpblVerification)과 다른 SSP가 자신을 검증하는데 이용될 수 있는 인증서 정보들(ReceiverSpblVerification)를 포함할 수 있다. 또한, "인증서 협상 정보"는 제2 SSP(2160)가 지원하는 키 합의 알고리즘의 리스트를 선택적으로 더 포함할 수 있으며, 제2 SSP (2160)가 지원하는 암호화 알고리즘의 리스트를 선택적으로 더 포함할 수 있다. 또한 "SSP 정보"에는 제2 SSP(2160)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보 중 적어도 하나를 포함하는 SSP 버전 정보가 선택적으로 더 포함될 수 있다.
도 21을 참조하면, 21010 단계에서 제2 SSP(2160)는 제2 LBA(2170)와 제1 LBA(2120)을 거쳐 제1 SSP(2110)에게 21005 단계에서 생성했던 "SSP 정보"를 전달할 수 있다.
이상에 기술된 21000 단계와 21010 단계에 따르면 제2 LBA(2170)가 제2 SSP(2160)에게 "SSP 정보 (SspInfo)" 를 요청하고, 제2 SSP(2160)가 자신의 "SSP 정보"를 생성한 뒤, 제2 SSP(2160)가 제2 LBA(2170)와 제1 LBA(2120)을 거쳐 제1 SSP(2110)에게 "SSP 정보"를 전달할 수 있다. 하지만, 실시예에 따라서는, 제 2 단말(2150)에서 제 1 단말(2100)로 "SSP 정보"가 전달되는 과정은 다음과 같을 수도 있다. 예컨대, 제2 LBA(2170)가 스스로 "SSP 정보"를 생성한 뒤 제1 LBA(2120)을 거쳐 제1 SSP(2110)에게 "SSP 정보"를 전달할 수 있다.
도 21을 참조하면, 21015 단계에서 제1 SSP(2110)은 수신된 "SSP 정보"를 확인하고 이 정보에 기반하여 자신을 인증할 수 있는 "제1 단말 인증 정보(Device1.Auth)"를 생성할 수 있다. 이 과정에 대한 보다 구체적인 절차는 다음과 같다.
제1 SSP(2110)은 수신된 "SenderSpblVerification"을 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 키 합의용 인증서(ssp1.Cert.KA)를 선택할 수 있다. 혹은, 제1 SSP(2110)은 수신된 "제2 SSP(2160)가 지원하는 키 합의 알고리즘의 리스트"를 이용해 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair) 공개키 "ssp1.ePK.KA"와 비밀키 "ssp1.eSK.KA"를 을 생성한 뒤, 이 키 쌍 중 공개키(ssp1.ePK.KA)를 선택할 수 있다. 또한, 제1 SSP(2110)은 수신된 "SenderSpblVerification"를 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 서명용 인증서(ssp1.Cert.DS)를 더 선택할 수 있다.
또한, 제1 SSP(2110)은 수신된 "ReceiverSpblVerification"을 이용해 검증을 수행할 제2 SSP(2160)의 인증서 정보를 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CiPkIdToBeUsed"로 설정할 수 있다.
또한, 제1 SSP(2110)은 수신된 "제2 SSP(2160)가 지원하는 암호화 알고리즘의 리스트"를 이용해 향후 사용될 암호화 알고리즘을 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CryptoToBeUsed"로 설정할 수 있다.
또한, 제1 SSP(2110)은 수신된 "제2 SSP(2160)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보"의 리스트를 확인하여 그 중 자신 역시 지원하는 표준 규격의 버전이 존재하는지를 확인할 수 있다.
"제1 단말 인증 정보(Device1.Auth)"는 상기에 설명된 "ssp1.Cert.KA", "ssp1.ePK.KA" "CiPkIdToBeUsed", "CryptoToBeUsed" 중 적어도 하나를 포함할 수 있다. 또한, "제1 단말 인증 정보(Device1.Auth)"는 상기에 설명된 "ssp1.Cert.DS"를 선택적으로 더 포함할 수 있다. 또한, "제1 단말 인증 정보(Device1.Auth)"는 향후 전송될 번들에 연관된 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나를 선택적으로 더 포함할 수 있다.
이때, 상기에 언급한 "제1 단말 인증 정보(Device1.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp1.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 "제1 단말 인증 정보"의 일부로서 추가될 수 있다.
도 21을 참조하면, 21020 단계에서 제1 SSP(2110)은 제1 LBA(2120)을 거쳐 제2 LBA(2170)에게 21015 단계에서 생성했던 "제1 단말 인증 정보(Device1.Auth)"를 전달할 수 있다.
도 21을 참조하면, 21025 단계에서 제2 LBA(2170)은 제2 SSP(2160)에게 "제1 단말 인증 정보(Device1.Auth)"를 전달할 수 있다. 또한, 제2 LBA(2170)은 제2 SSP(2160)에게 "번들 이동 코드"를 더 전달할 수 있다.
도 21을 참조하면, 21030 단계에서 제2 SSP(2160)은 수신된 "제1 단말 인증 정보(Device1.Auth)"를 검증할 수 있다. 만일, 제2 SSP(2160)이 "ssp1.Cert.KA"를 수신한 경우, 해당 인증서의 서명을 확인하여 인증서의 유효성을 확인할 수 있다. 또한, 제2 SSP(2160)이 "ssp1.ePK.KA"와 이에 대한 디지털 서명을 전송 받은 경우에는, 먼저 ssp1.Cert.DS의 유효성을 검사한 뒤 이 인증서를 이용하여 디지털 서명을 확인해 수신된 공개키 ssp1.ePK.KA 의 무결성을 확인할 수 있다. 또한, 제2 SSP(2160)은 수신된 "CiPkIdToBeUsed"를 확인해 자신을 검증할 수 있는 적어도 하나 이상의 서명용 인증서(ssp2.Cert.DS)를 선택할 수 있다.
또한, 도면에는 도시되어 있지 않지만, 21030 단계에서 제2 SSP(2160)은 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair)으로 공개키 "ssp2.ePK.KA"와 비밀키 "ssp2.eSK.KA"를 생성한 뒤, 이 키 쌍 중 공개키(ssp2.ePK.KA)를 선택할 수 있다. 또한, 제2 SSP(2160)은 ssp1.Cert.KA에 포함되어 있는 키 합의용 공개키나 ssp1.ePK.KA 중 하나를 선택한 뒤, 이 값과 ssp2.eSK.KA를 이용하여 향후 단말 1과의 통신 중 암호화에 사용될 세션 키 ShKey01을 생성할 수 있다. ShKey01은 수신된 "CryptoToBeUsed"에 포함되어 있는 암호화 알고리즘용 세션 키여야 한다.
또한, 21030 단계에서 제2 SSP(2160)은 자신을 인증할 수 있는 "제2 단말 인증 정보(Device2.Auth)"를 생성할 수 있다. 이때, "제2 단말 인증 정보(Device2.Auth)"는 "ssp2.Cert.DS"를 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 "ssp2.ePK.KA"를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 SSP 2(2160)에 의해 생성된 현재 세션을 지칭하는 트랜잭션 아이디(transaction ID)를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 "번들 이동 코드"를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 제2 SSP(2160)의 SSP 식별자를 더 포함할 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"는 향후 전송될 번들에 연관된 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나를 선택적으로 더 포함할 수 있다.
이때, 상기에 언급한 "제2 단말 인증 정보(Device2.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp2.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 "제2 단말 인증 정보"의 일부로서 추가될 수 있다. 또한, "제2 단말 인증 정보(Device2.Auth)"의 일부 혹은 전체는 앞서 생성된 세션 키 ShKey01를 이용해 암호화될 수 있다.
도 21을 참조하면, 21035 단계에서 제2 SSP(2160)는 제2 LBA(2170)와 제1 LBA(2120)을 거쳐 제1 SSP(2110)에게 21030 단계에서 생성했던 "제2 단말 인증 정보(Device2.Auth)"를 전달할 수 있다. 이때, "번들 이동 코드"가 선택적으로 더 전송될 수 있다.
도 21을 참조하면, 21040 단계에서 제1 SSP(2110)은 수신된 "제2 단말 인증 정보(Device2.Auth)"를 검증할 수 있다. 제1 SSP(2110)은 수신된 "ssp2.Cert.DS"의 서명을 검증하여 해당 인증서의 유효성을 검증할 수 있다. 또한, 제1 SSP(2110)은 수신된 번들 패밀리 식별자(SPB Family ID) 및/또는 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID)가 자신이 전송하고자 하는 번들과 연관되어 올바르게 설정된 값인지를 검사할 수 있다. 또한, 제1 SSP(2110)은 수신된 트랜잭션 아이디(transaction ID) 및/또는 제2 SSP(2160)의 SSP 식별자를 저장할 수 있다. 또한, 제1 SSP(2110)은 수신된 트랜잭션 아이디(transaction ID)나 제2 SSP(2160)의 SSP 식별자를, 현재 진행되고 있는 세션 혹은 전송하고자 하는 번들과 바인딩(binding)시킬 수 있다.
이 과정에서, 만일 "제2 단말 인증 정보(Device2.Auth)"에 암호화된 데이터가 포함되어 있을 경우, 제1 SSP(2110)은 전송 받은 ssp2.ePK.KA와 자신의 ssp1.Cert.KA에 포함되어 있는 키 합의용 공개키에 대응되는 비밀키나 ssp1.eSK.KA를 이용하여 세션 키 ShKey01를 생성하고, 이 세션 키를 이용하여 암호화된 데이터를 복호화한 뒤 검증 과정을 수행할 수 있다. 또한 이 과정에서, 만일 "제2 단말 인증 정보(Device2.Auth)"에 디지털 서명이 포함되어 있을 경우, 제1 SSP(2110)은 "ssp2.Cert.DS"를 이용하여 수신된 디지털 서명의 유효성을 검증할 수 있다.
또한 21040 단계에서, 도 21에 도시되어 있지는 않지만, 제1 SSP(2110)은 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair) 공개키 "ssp1.bundle.ePK.KA"와 비밀키 "ssp1.bundle.eSK.KA"를 을 생성할 수 있다. 이때, 키 쌍 "ssp1.bundle.ePK.KA 와 ssp1.bundle.eSK.KA"는 앞서 생성되었던 "ssp1.ePK.KA 와 ssp1.eSK.KA"와 동일한 값으로 설정될 수도 있다. 또는, 키 쌍 "ssp1.bundle.ePK.KA 와 ssp1.bundle.eSK.KA"는 앞서 사용되었던 "ssp1.Cert.KA에 포함되어 있는 공개키와 이에 대응되는 비밀키"와 동일한 값으로 설정될 수도 있다. 또한, 제1 SSP(2110)은 ssp1.bundle.eSK.KA와 ssp2.ePK.KA를 이용하여 세션 키 ShKey02를 생성할 수 있다. 만일 ssp1.bundle.eSK.KA를 위해 ssp1.eSK.KA 혹은' ssp1.Cert.Ka에 포함되어 있는 공개키에 대응되는 비밀키'가 재사용되었다면, 세션 키 ShKey02의 값 역시 이전에 생성되었던 ShKey01의 값으로 설정될 수 있다.
또한, 21040 단계에서 제1 SSP(2110)은 제2 단말(2150)으로 전송할 번들 및/또는 번들과 연관된 메타데이터를 구성할 수 있다. 이때, 제1 SSP(2110)은 수신된 "번들 이동 코드"를 이용하여 자신이 전송하고자 하는 번들을 식별할 수 있다. 또한, 구성될 번들에는 "ssp1.Cert.DS"가 포함될 수 있다. 또한, 구성될 번들에는 "ssp1.bundle.ePK.KA"가 더 포함될 수 있다. 또한, 구성될 번들은 해당 세션을 식별하는 트랜잭션 아이디(transaction ID)를 더 포함할 수 있다. 또한, 구성될 번들에는 전송될 번들과 연관된 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 선택적으로 더 포함될 수 있다. 다양한 실시예에 따르면, 21040 단계에서 구성되는 번들(또는, 번들과 연관된 메타데이터) 안에는 "번들 이동 설정"이 포함될 수 있다.
다양한 실시예에 따르면, 21040 단계에서 구성될 번들에는 ssp1.Cert.DS를 이용하여 생성된 디지털 서명 데이터가 추가될 수 있다. 즉, 상기에 명시된 번들의 구성 요소 일부 혹은 전체에 대하여 생성된 디지털 서명 데이터가 번들의 일부로서 추가될 수 있다. 또한, 구성될 번들의 일부 혹은 전체는 ShKey02를 이용해 암호화될 수 있다.
도 21을 참조하면, 21045 단계에서 제1 SSP(2110)은 제1 LBA(2120)을 거쳐 제2 LBA(2170)에게 21040 단계에서 생성했던(구성된) 번들을 전달할 수 있다. 이때, 전송되는 번들과 연관된 메타데이터가 선택적으로 더 전송될 수 있다. 또한, 전송되는 번들과 연관된 "번들 이동 설정"이 더 전송될 수 있다. 예를 들면, “번들 이동 설정”이 번들 또는 메타데이터에 포함되지 않고, 별도의 포맷(예컨대, 메시지)으로 전송될 수 있다.
도 22는 도 19에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 세부 절차를 도시하는 도면이다.
도 22는 번들의 기기 간 전송 내역이
- 선 고지(Pre-notification)될 필요가 없고
- 고지 내용의 암호화가 필요하거나 혹은 필요하지 않은
경우 적용되는 절차일 수 있다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 22의 예에서와 같이, 제1 단말(2200)은 제1 LBA(2220)과 제1 SSP(2210)을 포함하고, 제2 단말(2250)은 제2 LBA(2270)과 제2 SSP(2260)을 포함할 수 있다. 일 예로, 제1 단말(2200)은 제1 SSP(2210)가 장착되고 제1 SSP(2210)을 제어하기 위한 제1 LBA(2220)이 설치된 단말일 수 있고, 제2 단말(2250)은 제2 SSP(2260)가 장착되고 제2 SSP(2260)을 제어하기 위한 제2 LBA(2270)이 설치된 단말일 수 있다.
도 22를 참조하면, 22000 단계에서 다음의 절차들이 수행될 수 있다.
1. 번들 설치
도 22를 참조하면, 22000 단계에서 제2 LBA(2270)과 제2 SSP(2260)은 서로 협업하여 제2 단말(2250)에 번들을 설치할 수 있다. 이 과정에서 다음의 절차들이 함께 수행될 수 있다. 만일 메타데이터가 전송된 경우, 제2 LBA(2270) 혹은 제2 SSP(2260)은 메타데이터에 포함된 내용을 검증할 수 있다. 만일 "번들 이동 설정"이 전송되었다면, 제2 LBA(2270)은 상기 정보를 제2 SSP(2260)으로 전달할 수 있다. 만일 트랜잭션 아이디(transaction ID)가 전송되었다면, 제2 LBA(2270) 혹은 제2 SSP(2260)은 이 트랜잭션 아이디가 현재 세션에서 사용되었던 트랜잭션 아이디와 동일한지의 여부를 검사할 수 있다. 만일 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 전송되었다면, 제2 LBA(2270) 혹은 제2 SSP(2260)은 이 정보가 현재 수신하려는 번들의 정보와 일치하는지의 여부를 확인할 수 있다. 만일 ssp1.Cert.DS이 전송되었다면, 제2 SSP(2260)은 이 인증서의 유효성을 검증해 제1 SSP(2210)을 인증할 수 있다. 만일 전송 받은 데이터에 암호화된 데이터가 포함되어 있다면, 제2 SSP(2260)은 전송 받은 ssp1.bundle.ePK.KA 와 자신의 ssp2.eSK.KA를 이용하여 세션 키 ShKey02를 생성하고, 이 세션 키를 이용해 암호화된 데이터를 복호한 뒤 검증을 수행할 수 있다. 만일 수신된 데이터에 디지털 서명이 포함되어 있다면, 제2 SSP(2260)은 ssp1.Cer.DS를 검증한 뒤, 이 인증서를 이용해 디지털 서명의 유효성을 검증할 수 있다.
2. “등록 설정” 확인
또한, 도면에는 도시되지 않았지만, 제 2 LBA(2270) 및/또는 제 2 SSP(2260)는 해당 번들의 “등록 설정”을 이용해 '고지 필요 여부' 및/또는 '선 고지 필요 여부' 및/또는 '고지 내용의 암호화 필요 여부'를 확인할 수 있다. 이 과정은 22000 단계의 일부로써 22000 단계에서 이루어지는 다른 절차들과 순서에 상관 없이 독립적으로 이루어질 수 있다. 혹은 22000 단계 이후 22035 단계가 마무리되기 전, 판단이 필요한 순간에 수행될 수도 있다. 본 도면에서 후술할 절차는, “등록 설정”을 확인한 결과, 번들의 기기 간 전송 내역이 선 고지가 될 필요가 없을 때 적용되는 절차일 수 있다.
도 22를 참조하면, 22005 단계에서 제 2 SSP(2260)은 해당 번들의 상태를 "IN TRANSITION"으로 설정할 수 있다. "IN TRANSITION"은 번들이 성공적으로 설치되었지만 아직 사용이 불가한 상태 (또한, '본 도면에서 후술 될 추가 동작' 및/또는 '(본 개시에서는 설명되지 않았지만) 외부 서버의 요청'과 같은 추가 동작에 의해서만 사용 가능한 상태 (Disabled, Enable, Active 상태)로 변경될 수 있는 상태)를 의미한다.
도 22를 참조하면, 22010 단계에서 제 2 LBA(2270)은 제 2 SSP(2260)에게 "증명서"를 요청할 수 있다.
도 22를 참조하면, 22015 단계에서 제 2 SSP(2260)은 "증명서"를 생성할 수 있다. 도 22 에서 이 증명서는 finalizationRequest라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationRequest는 도 18의 1810에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationRequest는 도 18의 1830에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationRequest는 도 18의 1850에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- finalizationRequest는 도 18의 1870에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- finalizationRequest는 도 18의 1890에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 22를 참조하면, 22020 단계에서 제 2 SSP(2260)은 제 1 SSP(2210)에게 finalizationRequest를 전달할 수 있다. 예를 들어, 제 2 SSP(2260)은 제 1 SSP(2210)에게 다음과 같은 과정을 거쳐 finalizationRequest를 전달할 수 있다. 즉, 제 2 SSP(2260)은 제 2 LBA (2270) 에게 22010 단계의 응답으로 finalizationRequest를 전달하고, 제 2 LBA(2270)은 제 1 LBA(2220)을 거쳐 제 1 SSP(2210) 에게 finalizationRequest를 전달할 수 있다.
도 22를 참조하면, 22025 단계에서 제 1 SSP(2210)은 수신한 finalizationRequest를 검증할 수 있다. 이 검증 과정은, finalizationRequest에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationRequest에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자 인지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 명령어 정보가 번들의 상태를 “IN TRANSITION” 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 22025 단계에서 제 1 SSP(2210)는 검증을 마친 후 번들을 삭제할 수 있다.
또한, 22025 단계에서 제 1 SSP(2210)는 "증명서"를 생성할 수 있다. 도 22 에서 이 증명서는 finalizationResponse라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationResponse는 도 18의 1810에 해당 번들의 "번들 구분자"를 포함할 수 있다. 혹은, 이전 단계에서 수신된 finalizationRequest 의 일부 및/또는 전체 데이터를 포함할 수 있다.
- finalizationResponse는 도 18의 1830에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 도 18의 1850에 제 1 SSP가 번들을 삭제했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 도 18의 1870에 제 1 SSP가 번들을 삭제한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- finalizationResponse는 도 18의 1890에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 22를 참조하면, 22030 단계에서 제 1 SSP(2210)은 제 2 SSP(2260)에게 finalizationResponse를 전달할 수 있다. 예를 들어, 제 1 SSP(2210)은 제 1 LBA(2220)과 제 2 LBA(2270)을 거쳐 제 2 SSP(2260)에게 finalizationResponse를 전달할 수 있다.
도 22를 참조하면, 22035 단계에서 제 2 SSP(2260)은 수신한 finalizationResponse를 검증할 수 있다. 이 검증 과정은, finalizationResponse에 포함된 제 1 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 finalizationRequest의 데이터 일부 혹은 전체가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 명령어 정보가 번들을 삭제하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 22035 단계에서 제 2 SSP(2260)는 검증을 마친 후 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제 2 SSP(2260)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
또한, 22035 단계에서 제 2 SSP(2260)는 "증명서"를 생성할 수 있다. 도 22 에서 이 증명서는 spblAttestation 이라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- spblAttestation은 도 18의 1810에 해당 번들의 "번들 구분자"를 포함할 수 있다. 혹은, finalizationRequest 및/또는 finalizationResponse 의 일부 및/또는 전체 데이터를 포함할 수 있다.
- spblAttestation은 도 18의 1830에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- spblAttestation은 도 18의 1850에 제 2 SSP가 번들을 사용 가능한 상태 중 하나로 변경했음을 의미하는 정보를 포함할 수 있다.
- spblAttestation은 도 18의 1870에 제 2 SSP가 번들의 상태를 사용 가능한 상태 중 하나로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- spblAttestation은 도 18의 1890에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
또한, 22035 단계에서 제 2 SSP(2260)은 제2 SSP(2260)는 자신의 "선택된 SSP 정보(sspInforSelected)"를 생성할 수 있다. "선택된 SSP 정보"에는 기기 간 번들 전송 결과를 서버에 고지하기 위해 제공되어야 하는 제2 SSP의 정보가 포함될 수 있다.
이때, "선택된 SSP 정보"에는 인증서 협상 과정을 위한 정보(인증서 협상 정보)가 포함될 수 있다. 이 "인증서 협상 정보"는
- 제2 SSP(2260)가 서버를 검증하는 데 이용할 수 있는 인증서 정보들(spbmVerification)
- 서버가 제 1 SSP (2210)을 검증하는 데 이용할 수 있는 인증서 정보들 (SenderSpblVerification)
- 서버가 제 2 SSP (2260)을 검증하는 데 이용할 수 있는 인증서 정보들(ReceiverSpblVerification)
등의 정보를 선택적으로 포함할 수 있다. 또한, "인증서 협상 정보"는 제2 SSP(2260)가 지원하는 키 합의 알고리즘의 리스트를 선택적으로 더 포함할 수 있으며, 제2 SSP (2260)가 지원하는 암호화 알고리즘의 리스트를 선택적으로 더 포함할 수 있다.
또한 "선택된 SSP 정보"에는 제2 SSP(2260)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보 중 적어도 하나를 포함하는 SSP 버전 정보가 선택적으로 더 포함될 수 있다.
도 22를 참조하면, 22040 단계에서 제 2 SSP (2260)은 22035 단계에서 수행한 작업에 대한 결과 (예를 들어, 성공과 실패 여부)를 제 2 LBA(2270)에게 전송할 수 있다. 또한, 22035 단계에서 생성된 “선택된 SSP 정보”가 함께 전송될 수도 있다.
22035 단계에서 “선택된 SSP 정보”를 생성하는 과정과 22040 단계에서 “선택된 SSP 정보”를 전달하는 과정은 생략될 수 있다.
도 23은 도 22에서 제시된 절차 후, 번들의 전송 결과가 서버에 등록되는 절차를 도시하는 도면이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 23의 예에서와 같이, 제2 단말(2350)은 제2 LBA(2370)과 제2 SSP(2360)을 포함할 수 있다. 일 예로, 제2 단말(2350)은 제2 SSP(2360)가 장착되고 제2 SSP(2360)을 제어하기 위한 제2 LBA(2370)이 설치된 단말일 수 있다.
또한, 다양한 실시예에 따르면, 서버(2300)는 서비스 제공자에 의해 운영되는 서버일 수도 있고, 번들 관리 서버일 수도 있고, 서비스 제공자와 번들 관리 서버의 협업에 의해 운영되는 서버일 수도 있으며, 혹은 서비스 제공자 및/또는 번들 관리 서버와 연계되어 운영되는 임의의 서버일 수도 있다. 본 도면의 설명에서는 서버(2300)를 지칭하기 위해 서버의 가능한 예 중 하나인 SPBM이라는 용어를 사용하는 경우도 있지만, 앞서 기술하였듯 서버의 종류는 SPBM으로 국한되지 않는다.
도 23을 참조하면, 23000 단계에서 SPBM(2300)과 LBA(2370) 사이에 TLS(Transport Layer Security) 연결이 형성(established)될 수 있다. 본 도면에서는 23000 단계가 23005 내지 23015 단계 이전에 수행되는 것으로 기술되어 있지만, 23000 단계는 23020 단계가 수행되기 전 23005 내지 23015 단계와는 독립적으로 수행될 수 있다. 일례로, 23000 단계는 23015 단계와 23020 단계 사이에 수행될 수도 있다.
도 23을 참조하면, 23005 단계에서 제2 LBA(2370)은 제2 SSP 2(2360)에게 "선택된 SSP 정보 (SspInfoSelected)"를 요청할 수 있다. 이때, 23005 단계는 자동으로 수행될 수도 있고, 외부의 입력을 받은 후 수행될 수도 있다. 이 때, '외부의 입력'은 제2 단말(2350)이 제공하는 UI를 통해 사용자부터 주어질 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 제2 단말(2350)에게 주어질 수도 있다.
도 23을 참조하면, 23010 단계에서 제2 SSP(2360)는 자신의 "선택된 SSP 정보"를 생성할 수 있다. “선택된 SSP 정보”에 대한 설명은 도 22에 기술된 설명을 참조하기로 한다.
도 23을 참조하면, 23015 단계에서 제2 SSP(2360)는 제2 LBA(2370)에게 23010 단계에서 생성했던 “선택된 SSP 정보”를 전송할 수 있다.
23005 내지 23015 단계는 선택적으로 수행되지 않을 수 있다.
도 23을 참조하면, 23020 단계에서 제 2 LBA(2370)은 서버 (2300)에게 “선택된 SSP 정보”를 전송할 수 있다. 만일 제 2 LBA(2370)가, 도 22의 22035 내지 22040 단계를 통해 “선택된 SSP 정보”를 수신했거나, 혹은 도 23의 23005 내지 23015 단계를 통해 “선택된 SSP 정보”를 수신했다면, 제 2 LBA(2370)은 서버 (2300)에게 수신한 “선택된 SSP 정보”를 전송할 수 있다. 만일, 제 2 LBA(2370)가 “선택된 SSP 정보”를 수신하지 않았다면, 제 2 LBA(2370)는 “선택된 SSP 정보”를 생성하여 서버 (2300)에게 전송할 수 있다.
도 23을 참조하면, 23025 단계에서 서버(2300)는 수신된 "선택된 SSP 정보"를 확인하고 이 정보에 기반하여 자신을 인증할 수 있는 "서버 인증 정보(SPBM.Auth)"를 생성할 수 있다. 이 과정에 대한 보다 구체적인 절차는 다음과 같다.
서버(2300)는 수신된 "spbmVerification"을 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 키 합의용 인증서(spbm.Cert.KA)를 선택할 수 있다. 혹은, 서버(2300) 는 수신된 "제2 SSP(2360)가 지원하는 키 합의 알고리즘의 리스트"를 이용해 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair) 공개키 "spbm.ePK.KA"와 비밀키 "spbm.eSK.KA"를 을 생성한 뒤, 이 키 쌍 중 공개키(spbm.ePK.KA)를 선택할 수 있다. 또한, 서버(2300) 는 수신된 "spbmVerification"를 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 서명용 인증서(spbm.Cert.DS)를 더 선택할 수 있다.
또한, 서버(2300)는 수신된 "SenderSpblVerification"을 이용해 검증을 수행할 제1 SSP(2210)의 인증서 정보가 자신이 검증 가능한 것인지의 여부를 확인할 수 있다. 이 과정은 선택적으로 수행되지 않을 수 있다.
또한, 서버(2300)는 수신된 “ReceiverSpblVerification”을 이용해 검증을 수행할 제 2 SSP(2360)의 인증서 정보가 자신이 검증 가능한 것인지의 여부를 확인할 수 있다. 혹은, “ReceiverSpblVerification”을 이용해 자신이 검증할 수 있는 제 2 SSP(2360)의 인증서 정보를 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CiPkIdToBeUsed"로 설정할 수 있다.
또한, 서버(2300)는 수신된 "제2 SSP(2360)가 지원하는 암호화 알고리즘의 리스트"를 이용해 향후 사용될 암호화 알고리즘을 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CryptoToBeUsed"로 설정할 수 있다.
또한, 서버(2300)는 수신된 "제2 SSP(2360)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보"의 리스트를 확인하여 그 중 자신 역시 지원하는 표준 규격의 버전이 존재하는지를 확인할 수 있다.
"서버 인증 정보(SPBM.Auth)"는 상기에 설명된 "spbm.Cert.KA", "spbm.ePK.KA" "CiPkIdToBeUsed", "CryptoToBeUsed" 중 적어도 하나를 포함할 수 있다. 또한, "서버 인증 정보(SPBM.Auth)"는 상기에 설명된 "spbm.Cert.DS"를 선택적으로 더 포함할 수 있다.
이때, 상기에 언급한 "서버 인증 정보(SPBM.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 spbm.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 "서버 인증 정보"의 일부로서 추가될 수 있다.
도 23을 참조하면, 23030 단계에서 서버(2300)는 제2 LBA(2370)을 거쳐 제2 SSP(2360)에게 23025 단계에서 생성했던 "서버 인증 정보(SPBM.Auth)"를 전달할 수 있다.
도 23을 참조하면, 23035 단계에서 제2 SSP(2360)은 수신된 "서버 인증 정보(SPBM.Auth)"를 검증할 수 있다. 만일, 제2 SSP(2360)이 "spbm.Cert.KA"를 수신한 경우, 해당 인증서의 서명을 확인하여 인증서의 유효성을 확인할 수 있다. 또한, 제2 SSP(2360)이 "spbm.Cert.DS"를 수신한 경우, 해당 인증서의 서명을 확인하여 인증서의 유효성을 확인할 수 있다. 또한, 제2 SSP(2360)이 "spbm.ePK.KA"와 이에 대한 디지털 서명을 전송 받은 경우에는, spbm.Cert.DS 를 이용하여 디지털 서명을 확인해 수신된 공개키 spbm.ePK.KA 의 무결성을 확인할 수 있다. 또한, 제2 SSP(2360)은 "CiPkIdToBeUsed"을 수신했을 경우 이를 확인해 자신을 검증할 수 있는 적어도 하나 이상의 서명용 인증서(ssp2.Cert.DS)를 선택할 수 있다.
또한, 도면에는 도시되어 있지 않지만, 23035 단계에서 제2 SSP(2360)은 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair)으로 공개키 "ssp2.ePK.KA"와 비밀키 "ssp2.eSK.KA"를 생성한 뒤, 이 키 쌍 중 공개키(ssp2.ePK.KA)를 선택할 수 있다. 또한, 제2 SSP(2360)은 spbm.Cert.KA에 포함되어 있는 키 합의용 공개키나 spbm.ePK.KA 중 하나를 선택한 뒤, 이 값과 ssp2.eSK.KA를 이용하여 향후 서버와의 통신 중 암호화에 사용될 세션 키 ShKey03를 생성할 수 있다. ShKey03는 수신된 "CryptoToBeUsed"에 포함되어 있는 암호화 알고리즘용 세션 키여야 한다.
또한, 23035 단계에서 제2 SSP(2360)은 자신을 인증할 수 있는 "단말 인증 정보(Device.Auth)"를 생성할 수 있다. 이때, "단말 인증 정보(Device.Auth)"는 "ssp2.Cert.DS"를 포함할 수 있다. 또한 "단말 인증 정보(Device.Auth)"는 “ssp1.Cert.DS”를 선택적으로 더 포함할 수 있다. 또한, "단말 인증 정보(Device.Auth)"는 “ssp2.Cert.DS” 및/또는 “ssp1.Cert.DS” 와 연관된 인증서 체인 정보를 더 포함할 수 있다. 또한 "단말 인증 정보(Device.Auth)"는 spblAttestation의 일부 및/또는 전체를 포함할 수 있다. 또한 "단말 인증 정보(Device.Auth)"는 finalizationRequest의 일부 및/또는 전체를 포함할 수 있다. 또한 "단말 인증 정보(Device.Auth)"는 finalizationResponse의 일부 및/또는 전체를 포함할 수 있다. 또한, "단말 인증 정보(Device.Auth)"는 "ssp2.ePK.KA"를 더 포함할 수 있다.
이때, 상기에 언급한 "단말 인증 정보(Device.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp2.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 " 단말 인증 정보"의 일부로서 추가될 수 있다. 또한, “단말 인증 정보(Device.Auth)"의 일부 혹은 전체는 앞서 생성된 세션 키 ShKey03를 이용해 암호화될 수 있다.
도 23을 참조하면, 23040 단계에서 제2 SSP(2360)는 제2 LBA(2370)를 거쳐 서버(2300)에게 23035 단계에서 생성했던 "단말 인증 정보(Device.Auth)"를 전달할 수 있다.
도 23을 참조하면, 23045 단계에서 서버(2300)는 수신된 "단말 인증 정보(Device.Auth)"를 검증할 수 있다. 검증 과정의 구체적 절차는 다음과 같다. 서버(2300)는 수신된 "ssp1.Cert.DS" 및/또는 "ssp2.Cert.DS"의 서명을 검증하여 해당 인증서의 유효성을 검증할 수 있다. 또한, 서버(2300)는 수신한 spblAttestation 및/또는 finalizationRequest 및/또는 finalizationResponse의 서명을 검증할 수 있다. 또한, 서버(2300)는 수신한 spblAttestation 및/또는 finalizationRequest 및/또는 finalizationResponse의 내용을 검증할 수 있다. 또한 서버(2300)는 검증한 내용을 바탕으로 기기 간 전송이 된 번들의 내역을 업데이트할 수 있다. 일례로, 서버(2300)는 해당 번들과 제1 SSP(2210) 사이에 존재했던 매핑(mapping) 관계를 해당 번들과 제2 SSP(2360)의 매핑(mapping) 관계로 업데이트할 수 있다.
이 과정에서, 만일 "단말 인증 정보(Device.Auth)"에 암호화된 데이터가 포함되어 있을 경우, 서버(2300)는 전송 받은 ssp2.ePK.KA와 자신의 spbm.Cert.KA에 포함되어 있는 키 합의용 공개키에 대응되는 비밀키나 spbm.eSK.KA를 이용하여 세션 키 ShKey03를 생성하고, 이 세션 키를 이용하여 암호화된 데이터를 복호화한 뒤 검증 과정을 수행할 수 있다.
도 23을 참조하면, 23050 단계에서 서버(2300)는 23045 단계에서 수행한 작업에 대한 결과 (예를 들어, 성공과 실패 여부)를 제 2 LBA(2370)에게 전송할 수 있다.
도 24는 도 19에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다.
도 24는 번들의 기기 간 전송 내역이
- 선 고지(Pre-notification)될 필요가 없고
- 고지 내용의 암호화가 필요하지 않은 경우 적용되는 절차일 수 있다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 24의 예에서와 같이, 제1 단말(2400)은 제1 LBA(2420)과 제1 SSP(2410)을 포함하고, 제2 단말(2450)은 제2 LBA(2470)과 제2 SSP(2460)을 포함할 수 있다. 일 예로, 제1 단말(2400)은 제1 SSP(2410)가 장착되고 제1 SSP(2410)을 제어하기 위한 제1 LBA(2420)이 설치된 단말일 수 있고, 제2 단말(2450)은 제2 SSP(2460)가 장착되고 제2 SSP(2460)을 제어하기 위한 제2 LBA(2470)이 설치된 단말일 수 있다.
도 24를 참조하면, 24000 단계에서 다음의 절차들이 수행될 수 있다.
1. 번들 설치
도 24를 참조하면, 24000 단계에서 제2 LBA(2470)과 제2 SSP(2460)은 서로 협업하여 제2 단말(2450)에 번들을 설치할 수 있다. 이 과정에서 다음의 절차들이 함께 수행될 수 있다. 만일 메타데이터가 전송된 경우, 제2 LBA(2470) 혹은 제2 SSP(2460)은 메타데이터에 포함된 내용을 검증할 수 있다. 만일 "번들 이동 설정"이 전송되었다면, 제2 LBA(2470)은 이 정보를 제2 SSP(2460)으로 전달할 수 있다. 만일 트랜잭션 아이디(transaction ID)가 전송되었다면, 제2 LBA(2470) 혹은 제2 SSP(2460)은 이 트랜잭션 아이디가 현재 세션에서 사용되었던 트랜잭션 아이디와 동일한지의 여부를 검사할 수 있다. 만일 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 전송되었다면, 제2 LBA(2470) 혹은 제2 SSP(2460)은 이 정보가 현재 수신하려는 번들의 정보와 일치하는지의 여부를 확인할 수 있다. 만일 ssp1.Cert.DS이 전송되었다면, 제2 SSP(2460)은 이 인증서의 유효성을 검증해 제1 SSP(2410)을 인증할 수 있다. 만일 전송 받은 데이터에 암호화된 데이터가 포함되어 있다면, 제2 SSP(2460)은 전송 받은 ssp1.bundle.ePK.KA 와 자신의 ssp2.eSK.KA를 이용하여 세션 키 ShKey02를 생성하고, 이 세션 키를 이용해 암호화된 데이터를 복호한 뒤 검증을 수행할 수 있다. 만일 수신된 데이터에 디지털 서명이 포함되어 있다면, 제2 SSP(2460)은 ssp1.Cer.DS를 검증한 뒤, 이 인증서를 이용해 디지털 서명의 유효성을 검증할 수 있다.
2. “등록 설정” 확인
또한, 도면에는 도시되지 않았지만, 제 2 LBA(2470) 및/또는 제 2 SSP(2460)는 해당 번들의 “등록 설정”을 이용해 '고지 필요 여부' 및/또는 '선 고지 필요 여부' 및/또는 '고지 내용의 암호화 필요 여부'를 확인할 수 있다. 이 과정은 24000 단계의 일부로써 24000 단계에서 이루어지는 다른 절차들과 순서에 상관 없이 독립적으로 이루어질 수 있다. 혹은 24000 단계 이후 24035 단계가 마무리되기 전, 판단이 필요한 순간에 수행될 수도 있다. 본 도면에서 후술할 절차는, “등록 설정”을 확인한 결과, 번들의 기기 간 전송 내역이 선 고지가 될 필요가 없고 고지 내용이 암호화될 필요가 없을 때 적용되는 절차일 수 있다.
도 24을 참조하면, 24005 단계에서 제 2 SSP(2460)은 해당 번들의 상태를 "IN TRANSITION"으로 설정할 수 있다. "IN TRANSITION"은 번들이 성공적으로 설치되었지만 아직 사용이 불가한 상태 (또한, '본 도면에서 후술 될 추가 동작' 및/또는 '(본 개시에서는 설명되지 않았지만) 외부 서버의 요청'과 같은 추가 동작에 의해서만 사용 가능한 상태 (Disabled, Enable, Active 상태)로 변경될 수 있는 상태)를 의미한다.
도 24을 참조하면, 24010 단계에서 제 2 LBA(2470)은 제 2 SSP(2460)에게 "증명서"를 요청할 수 있다.
도 24을 참조하면, 24015 단계에서 제 2 SSP(2460)은 "증명서"를 생성할 수 있다. 도 24 에서 이 증명서는 finalizationRequest라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationRequest는 도 18의 1810에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationRequest는 도 18의 1830에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationRequest는 도 18의 1850에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- finalizationRequest는 도 18의 1870에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- finalizationRequest는 도 18의 1890에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 2를 참조하면, 24020 단계에서 제 2 SSP(2460)은 제 1 SSP(2410)에게 finalizationRequest를 전달할 수 있다. 예를 들어, 제 2 SSP(2460)은 제 1 SSP(2410)에게 다음과 같은 과정을 거쳐 finalizationRequest를 전달할 수 있다. 즉, 제 2 SSP(2460)은 제 2 LBA (2470) 에게 24010 단계의 응답으로 finalizationRequest를 전달하고, 제 2 LBA(2470)은 제 1 LBA(2420)을 거쳐 제 1 SSP(2410) 에게 finalizationRequest를 전달할 수 있다.
도 24를 참조하면, 24025 단계에서 제 1 SSP(2410)은 수신한 finalizationRequest를 검증할 수 있다. 이 검증 과정은, finalizationRequest에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationRequest에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자 인지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 명령어 정보가 번들의 상태를 “IN TRANSITION” 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 24025 단계에서 제 1 SSP(2410)는 검증을 마친 후 번들을 삭제할 수 있다.
또한, 24025 단계에서 제 1 SSP(2410)는 "증명서"를 생성할 수 있다. 도 24 에서 이 증명서는 finalizationResponse라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationResponse는 도 18의 1810에 해당 번들의 "번들 구분자"를 포함할 수 있다. 혹은, 이전 단계에서 수신된 finalizationRequest 의 일부 및/또는 전체 데이터를 포함할 수 있다.
- finalizationResponse는 도 18의 1830에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 도 18의 1850에 제 1 SSP가 번들을 삭제했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 도 18의 1870에 제 1 SSP가 번들을 삭제한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- finalizationResponse는 도 18의 1890에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 24을 참조하면, 24030 단계에서 제 1 SSP(2410)은 제 2 SSP(2460)에게 finalizationResponse를 전달할 수 있다. 예를 들어, 제 1 SSP(2410)은 제 1 LBA(2420)과 제 2 LBA(2470)을 거쳐 제 2 SSP(2460)에게 finalizationResponse를 전달할 수 있다.
도 24을 참조하면, 24035 단계에서 제 2 SSP(2460)은 수신한 finalizationResponse를 검증할 수 있다. 이 검증 과정은, finalizationResponse에 포함된 제 1 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 finalizationRequest의 데이터 일부 혹은 전체가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 명령어 정보가 번들을 삭제하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 24035 단계에서 제 2 SSP(2460)는 검증을 마친 후 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제 2 SSP(2460)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
또한, 24035 단계에서 제 2 SSP(2460)는 "증명서"를 생성할 수 있다. 도 24 에서 이 증명서는 spblAttestation 이라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- spblAttestation은 도 18의 1810에 해당 번들의 "번들 구분자"를 포함할 수 있다. 혹은, finalizationRequest 및/또는 finalizationResponse 의 일부 및/또는 전체 데이터를 포함할 수 있다.
- spblAttestation은 도 18의 1830에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- spblAttestation은 도 18의 1850에 제 2 SSP가 번들을 사용 가능한 상태 중 하나로 변경했음을 의미하는 정보를 포함할 수 있다.
- spblAttestation은 도 18의 1870에 제 2 SSP가 번들의 상태를 사용 가능한 상태 중 하나로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- spblAttestation은 도 18의 1890에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 24를 참조하면, 24040 단계에서 제 2 SSP (2460)은 24035 단계에서 생성한 spblAttestation을 전송할 수도 있다.
도 25는 도 24에서 제시된 절차 후, 번들의 전송 결과가 서버에 등록되는 절차를 도시하는 도면이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 25의 예에서와 같이, 제2 단말(2550)은 제2 LBA(2570)과 제2 SSP(2560)을 포함할 수 있다. 일 예로, 제2 단말(2550)은 제2 SSP(2560)가 장착되고 제2 SSP(2560)을 제어하기 위한 제2 LBA(2570)이 설치된 단말일 수 있다.
또한, 다양한 실시예에 따르면, 서버(2500)는 서비스 제공자에 의해 운영되는 서버일 수도 있고, 번들 관리 서버일 수도 있고, 서비스 제공자와 번들 관리 서버의 협업에 의해 운영되는 서버일 수도 있으며, 혹은 서비스 제공자 및/또는 번들 관리 서버와 연계되어 운영되는 임의의 서버일 수도 있다. 본 도면의 설명에서는 서버(2500)를 지칭하기 위해 서버의 가능한 예 중 하나인 SPBM이라는 용어를 사용하는 경우도 있지만, 앞서 기술하였듯 서버의 종류는 SPBM으로 국한되지 않는다.
도 25를 참조하면, 25000 단계에서 SPBM(2500)과 LBA(2570) 사이에 TLS(Transport Layer Security) 연결이 형성(established)될 수 있다.
도 25를 참조하면, 25005 단계에서 제 2 LBA(2570)은 서버 (2500)에게 spblAttestation 및/또는 finalizationRequest 및/또는 finalizationResponse의 일부 및/또는 전체를 전송할 수 있다. 이때, 제2 LBA(2570)은 서버(2500)에게 “선택된 SSP 정보”를 추가로 더 전송할 수 있다. “선택된 SSP 정보”에 대한 설명은 도 22의 설명을 참조하기로 한다. 또한, 제2 LBA(2570)은 서버(2500)에게 "ssp2.Cert.DS"를 선택적으로 더 전송할 수 있다. 또한 제2 LBA(2570)은 서버(2500)에게 “ssp1.Cert.DS”를 선택적으로 더 전송할 수 있다. 또한, 제2 LBA(2570)은 서버(2500)에게 “ssp2.Cert.DS” 및/또는 “ssp1.Cert.DS” 와 연관된 인증서 체인 정보를 더 포함할 수 있다. 상기의 정보들은 제2 LBA(2570) 스스로 구성하여 전송할 수도 있고, 본 도면에 도시되지는 않았지만 제2 LBA(2570)이 제2 SSP(2560)에게 해당 정보를 요청한 뒤 수신한 정보들을 전송할 수도 있고, 혹은 본 도면에 도시되지는 않았지만 제2 LBA(2570)이 제2 SSP(2560)에게 해당 정보의 일부를 요청한 뒤 수신한 정보와 자신이 보유한 정보를 조합하여 전송할 수도 있다.
도 25를 참조하면, 25010 단계에서 서버(2500)는 25005 단계에서 수신한 정보들을 검증할 수 있다. 검증 과정의 구체적 절차는 다음과 같다. 서버(2500)는 수신된 "ssp1.Cert.DS" 및/또는 "ssp2.Cert.DS"의 서명을 검증하여 해당 인증서의 유효성을 검증할 수 있다. 또한, 서버(2500)는 수신한 spblAttestation 및/또는 finalizationRequest 및/또는 finalizationResponse의 서명을 검증할 수 있다. 또한, 서버(2700)는 수신한 spblAttestation 및/또는 finalizationRequest 및/또는 finalizationResponse의 내용을 검증할 수 있다. 또한 서버(2500)는 검증한 내용을 바탕으로 기기 간 전송이 된 번들의 내역을 업데이트할 수 있다. 일례로, 서버(2500)는 해당 번들과 제1 SSP(2410) 사이에 존재했던 매핑(mapping) 관계를 해당 번들과 제2 SSP(2560)의 매핑(mapping) 관계로 업데이트할 수 있다.
도 25를 참조하면, 25015 단계에서 서버(2500)는 제2 LBA(2570)에게 25010 단계에서 수행한 검증 작업의 결과를 전송할 수 있다. 예를 들면, 서버(2500)는 제2 LBA(2570)에게 검증의 성공 혹은 실패 여부를 전송할 수 있다.
도 26은 도 19에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차를 도시하는 도면이다.
도 26은 번들의 기기 간 전송 내역이
- 선 고지(Pre-notification)될 필요가 있고
- 고지 내용의 암호화가 필요하거나 혹은 필요하지 않은
경우 적용되는 절차일 수 있다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 26의 예에서와 같이, 제1 단말(2600)은 제1 LBA(2620)과 제1 SSP(2610)을 포함하고, 제2 단말(2650)은 제2 LBA(2670)과 제2 SSP(2660)을 포함할 수 있다. 일 예로, 제1 단말(2600)은 제1 SSP(2610)가 장착되고 제1 SSP(2610)을 제어하기 위한 제1 LBA(2620)이 설치된 단말일 수 있고, 제2 단말(2650)은 제2 SSP(2660)가 장착되고 제2 SSP(2660)을 제어하기 위한 제2 LBA(2670)이 설치된 단말일 수 있다.
도 26을 참고하면 26000 단계에서 다음의 절차들이 수행될 수 있다.
1. 번들 설치
도 26을 참조하면, 26000 단계에서 제2 LBA(2670)과 제2 SSP(2660)은 서로 협업하여 제2 단말(2650)에 번들을 설치할 수 있다. 이 과정에서 다음의 절차들이 함께 수행될 수 있다. 만일 메타데이터가 전송된 경우, 제2 LBA(2670) 혹은 제2 SSP(2660)은 메타데이터에 포함된 내용을 검증할 수 있다. 만일 "번들 이동 설정"이 전송되었다면, 제2 LBA(2670)은 이 정보를 제2 SSP(2660)으로 전달할 수 있다. 만일 트랜잭션 아이디(transaction ID)가 전송되었다면, 제2 LBA(2670) 혹은 제2 SSP(2660)은 이 트랜잭션 아이디가 현재 세션에서 사용되었던 트랜잭션 아이디와 동일한지의 여부를 검사할 수 있다. 만일 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 전송되었다면, 제2 LBA(2670) 혹은 제2 SSP(2660)은 이 정보가 현재 수신하려는 번들의 정보와 일치하는지의 여부를 확인할 수 있다. 만일 ssp1.Cert.DS이 전송되었다면, 제2 SSP(2660)은 이 인증서의 유효성을 검증해 제1 SSP(2610)을 인증할 수 있다. 만일 전송 받은 데이터에 암호화된 데이터가 포함되어 있다면, 제2 SSP(2660)은 전송 받은 ssp1.bundle.ePK.KA 와 자신의 ssp2.eSK.KA를 이용하여 세션 키 ShKey02를 생성하고, 이 세션 키를 이용해 암호화된 데이터를 복호한 뒤 검증을 수행할 수 있다. 만일 수신된 데이터에 디지털 서명이 포함되어 있다면, 제2 SSP(2660)은 ssp1.Cer.DS를 검증한 뒤, 이 인증서를 이용해 디지털 서명의 유효성을 검증할 수 있다.
2. 선 등록 필요 여부 확인
또한, 도면에는 도시되지 않았지만, 제 2 LBA(2670) 및/또는 제 2 SSP(2660)는 해당 번들의 “등록 설정”을 이용해 '고지 필요 여부' 및/또는 '선 고지 필요 여부' 및/또는 '고지 내용의 암호화 필요 여부'를 확인할 수 있다. 이 과정은 26000 단계의 일부로써 26000 단계에서 이루어지는 다른 절차들과 순서에 상관 없이 독립적으로 이루어질 수 있다. 혹은 26000 단계 이후 26035 단계가 마무리되기 전, 판단이 필요한 순간에 수행될 수도 있다. 본 도면에서 후술할 절차는, “등록 설정”을 확인한 결과, 번들의 기기 간 전송 내역이 선 고지가 될 필요가 있을 경우 적용되는 절차일 수 있다.
도 26을 참조하면, 26005 단계에서 제 2 SSP(2660)은 해당 번들의 상태를 "IN TRANSITION"으로 설정할 수 있다. "IN TRANSITION"은 번들이 성공적으로 설치되었지만 아직 사용이 불가한 상태 (또한, '본 도면에서 후술 될 추가 동작과 도 27에서 설명할 추가 동작' 및/또는 '(본 개시에서는 설명되지 않았지만) 외부 서버의 요청'과 같은 추가 동작에 의해서만 사용 가능한 상태 (Disabled, Enable, Active 상태)로 변경될 수 있는 상태)를 의미한다.
도 26을 참조하면, 26010 단계에서 제 2 LBA(2670)은 제 2 SSP(2660)에게 "증명서"를 요청할 수 있다.
도 26을 참조하면, 26015 단계에서 제 2 SSP(2660)은 "증명서"를 생성할 수 있다. 도 26 에서 이 증명서는 finalizationRequest라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationRequest는 도 18의 1810에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationRequest는 도 18의 1830에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationRequest는 도 18의 1850에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- finalizationRequest는 도 18의 1870에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- finalizationRequest는 도 18의 1890에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 26을 참조하면, 26020 단계에서 제 2 SSP(2660)은 제 1 SSP(2610)에게 finalizationRequest를 전달할 수 있다. 예를 들어, 제 2 SSP(2660)은 제 1 SSP(2610)에게 다음과 같은 과정을 거쳐 finalizationRequest를 전달할 수 있다. 즉, 제 2 SSP(2660)은 제 2 LBA (2670) 에게 26010 단계의 응답으로 finalizationRequest를 전달하고, 제 2 LBA는 제 1 LBA(2620)을 거쳐 제 1 SSP 에게 finalizationRequest를 전달할 수 있다.
도 26을 참조하면, 26025 단계에서 제 1 SSP(2610)은 수신한 finalizationRequest를 검증할 수 있다. 이 검증 과정은, finalizationRequest에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationRequest에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자 인지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 명령어 정보가 번들의 상태를 “IN TRANSITION” 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 26025 단계에서 제 1 SSP(2610)는 검증을 마친 후 번들을 삭제할 수 있다.
또한, 26025 단계에서 제 1 SSP(2610)는 "증명서"를 생성할 수 있다. 도 26 에서 이 증명서는 finalizationResponse라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationResponse는 도 18의 1810에 해당 번들의 "번들 구분자"를 포함할 수 있다. 혹은, 이전 단계에서 수신된 finalizationRequest 의 일부 및/또는 전체 데이터를 포함할 수 있다.
- finalizationResponse는 도 18의 1830에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 도 18의 1850에 제 1 SSP가 번들을 삭제했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 도 18의 1870에 제 1 SSP가 번들을 삭제한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- finalizationResponse는 도 18의 1890에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 26을 참조하면, 26030 단계에서 제 1 SSP(2610)은 제 2 SSP(2660)에게 finalizationResponse를 전달할 수 있다. 예를 들어, 제 1 SSP(2610)은 제 1 LBA(2620)과 제 2 LBA(2670)을 거쳐 제 2 SSP(2660)에게 finalizationResponse를 전달할 수 있다.
도 26을 참조하면, 26035 단계에서 제 2 SSP(2660)은 수신한 finalizationResponse를 검증할 수 있다. 이 검증 과정은, finalizationResponse에 포함된 제 1 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 finalizationRequest의 데이터 일보 혹은 전체가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 명령어 정보가 번들을 삭제하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 26035 단계에서 제 2 SSP(2660)은 자신의 "선택된 SSP 정보(sspInforSelected)"를 생성할 수 있다. "선택된 SSP 정보"에는 기기 간 번들 전송 결과를 서버에 고지하기 위해 제공되어야 하는 제2 SSP의 정보가 포함될 수 있다.
이때, "선택된 SSP 정보"에는 인증서 협상 과정을 위한 정보(인증서 협상 정보)가 포함될 수 있다. 이 "인증서 협상 정보"는
- 제2 SSP(2660)가 서버를 검증하는 데 이용할 수 있는 인증서 정보들(spbmVerification)
- 서버가 제 1 SSP (2610)을 검증하는 데 이용할 수 있는 인증서 정보들 (SenderSpblVerification)
- 서버가 제 2 SSP (2660)을 검증하는 데 이용할 수 있는 인증서 정보들(ReceiverSpblVerification)
등의 정보를 선택적으로 포함할 수 있다. 또한, "인증서 협상 정보"는 제2 SSP(2660)가 지원하는 키 합의 알고리즘의 리스트를 선택적으로 더 포함할 수 있으며, 제2 SSP (2660)가 지원하는 암호화 알고리즘의 리스트를 선택적으로 더 포함할 수 있다.
또한 "선택된 SSP 정보"에는 제2 SSP(2660)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보 중 적어도 하나를 포함하는 SSP 버전 정보가 선택적으로 더 포함될 수 있다.
도 26을 참조하면, 26040 단계에서 제 2 SSP (2660)은 26035 단계에서 수행한 작업에 대한 결과 (예를 들어, 성공과 실패 여부)를 제 2 LBA(2670)에게 전송할 수 있다. 또한, 26035 단계에서 생성된 “선택된 SSP 정보”가 함께 전송될 수도 있다.
26035 과정에서 “선택된 SSP 정보”를 생성하는 과정과 26040 단계에서 “선택된 SSP 정보”를 전달하는 과정은 생략될 수 있다.
도 27은 도 26에서 제시된 절차 후, 번들의 전송 결과가 서버에 등록되는 절차를 도시하는 도면이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 27의 예에서와 같이, 제2 단말(2750)은 제2 LBA(2770)과 제2 SSP(2760)을 포함할 수 있다. 일 예로, 제2 단말(2750)은 제2 SSP(2760)가 장착되고 제2 SSP(2760)을 제어하기 위한 제2 LBA(2770)이 설치된 단말일 수 있다.
또한, 다양한 실시예에 따르면, 서버(2700)는 서비스 제공자에 의해 운영되는 서버일 수도 있고, 번들 관리 서버일 수도 있고, 서비스 제공자와 번들 관리 서버의 협업에 의해 운영되는 서버일 수도 있으며, 혹은 서비스 제공자 및/또는 번들 관리 서버와 연계되어 운영되는 임의의 서버일 수도 있다. 본 도면의 설명에서는 서버(2700)를 지칭하기 위해 서버의 가능한 예 중 하나인 SPBM이라는 용어를 사용하는 경우도 있지만, 앞서 기술하였듯 서버의 종류는 SPBM으로 국한되지 않는다.
도 27을 참조하면, 27000 단계에서 SPBM(2700)과 LBA(2770) 사이에 TLS(Transport Layer Security) 연결이 형성(established)될 수 있다. 본 도면에서는 27000 단계가 27005 내지 27015 단계 이전에 수행되는 것으로 기술되어 있지만, 27000 단계는 27020 단계가 수행되기 전 27005 내지 27015 단계와는 독립적으로 수행될 수 있다. 일례로, 27000 단계는 27015 단계와 27020 단계 사이에 수행될 수도 있다.
도 27을 참조하면, 27005 단계에서 제2 LBA(2770)은 제2 SSP 2(2760)에게 "선택된 SSP 정보 (SspInfoSelected)"를 요청할 수 있다. 이때, 27005 단계는 자동으로 수행될 수도 있고, 외부의 입력을 받은 후 수행될 수도 있다. 이 때, '외부의 입력'은 제2 단말(2750)이 제공하는 UI를 통해 사용자부터 주어질 수도 있고, 원격 서버로부터 푸쉬 입력을 통해 제2 단말(2750)에게 주어질 수도 있다.
도 27을 참조하면, 27010 단계에서 제2 SSP(2760)는 자신의 "선택된 SSP 정보"를 생성할 수 있다. “선택된 SSP 정보”에 대한 설명은 도 26에 기술된 설명을 참조하기로 한다.
도 27을 참조하면, 27015 단계에서 제2 SSP(2760)는 제2 LBA(2770)에게 27010 단계에서 생성했던 “선택된 SSP 정보”를 전송할 수 있다.
27005 내지 27015 단계는 경우에 따라 생략될 수 있다.
도 27을 참조하면, 27020 단계에서 제 2 LBA(2770)은 서버 (2700)에게 “선택된 SSP 정보”를 전송할 수 있다. 만일 제 2 LBA(2770)가 도 26의 26035 내지 26040 단계를 통해 “선택된 SSP 정보”를 수신했거나, 혹은 도 27의 27005 내지 27015 단계를 통해 “선택된 SSP 정보”를 수신했다면, 제 2 LBA(2770)은 서버 (2700)에게 수신한 “선택된 SSP 정보”를 전송할 수 있다. 만일, 제 2 LBA(2770)가 “선택된 SSP 정보”를 수신하지 않았다면, 제 2 LBA(2770)는 “선택된 SSP 정보”를 생성하여 서버 (2700)에게 전송할 수 있다.
도 27을 참조하면, 27025 단계에서 서버(2700)는 수신된 "선택된 SSP 정보"를 확인하고 이 정보에 기반하여 자신을 인증할 수 있는 "서버 인증 정보(SPBM.Auth)"를 생성할 수 있다. 이 과정에 대한 보다 구체적인 절차는 다음과 같다.
서버(2700)는 수신된 "spbmVerification"을 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 키 합의용 인증서(spbm.Cert.KA)를 선택할 수 있다. 혹은, 서버(2700)는 수신된 "제2 SSP(2760)가 지원하는 키 합의 알고리즘의 리스트"를 이용해 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair) 공개키 "spbm.ePK.KA"와 비밀키 "spbm.eSK.KA"를 을 생성한 뒤, 이 키 쌍 중 공개키(spbm.ePK.KA)를 선택할 수 있다. 또한, 서버(2700)는 수신된 "spbmVerification"를 이용해 자신을 검증할 수 있는 인증서 정보를 확인하고 적어도 하나 이상의 서명용 인증서(spbm.Cert.DS)를 더 선택할 수 있다.
또한, 서버(2700)는 수신된 "SenderSpblVerification"을 이용해 검증을 수행할 제1 SSP(2610)의 인증서 정보가 자신이 검증 가능한 것인지의 여부를 확인할 수 있다.
또한, 서버(2700)는 수신된 “ReceiverSpblVerification”을 이용해 검증을 수행할 제 2 SSP(2760)의 인증서 정보가 자신이 검증 가능한 것인지의 여부를 확인할 수 있다. 혹은, “ReceiverSpblVerification”을 이용해 자신이 검증할 수 있는 제 2 SSP(2760)의 인증서 정보를 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CiPkIdToBeUsed"로 설정할 수 있다.
또한, 서버(2700)는 수신된 "제2 SSP(2760)가 지원하는 암호화 알고리즘의 리스트"를 이용해 향후 사용될 암호화 알고리즘을 적어도 하나 이상 선택한 뒤 이에 해당하는 정보를 "CryptoToBeUsed"로 설정할 수 있다.
또한, 서버(2700)는 수신된 "제2 SSP(2760)이 포함하는 프라이머리 플랫폼 및 로더가 지원하는 표준 규격의 버전 정보"의 리스트를 확인하여 그 중 자신 역시 지원하는 표준 규격의 버전이 존재하는지를 확인할 수 있다.
"서버 인증 정보(SPBM.Auth)"는 상기에 설명된 "spbm.Cert.KA", "spbm.ePK.KA", "spbm.Cert.DS", "CiPkIdToBeUsed", "CryptoToBeUsed" 중 적어도 하나를 포함할 수 있다.
이때, 상기에 언급한 "서버 인증 정보(SPBM.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 spbm.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 "서버 인증 정보"의 일부로서 추가될 수 있다.
도 27을 참조하면, 27030 단계에서 서버(2700)는 제2 LBA(2770)을 거쳐 제2 SSP(2760)에게 27025 단계에서 생성했던 "서버 인증 정보(SPBM.Auth)"를 전달할 수 있다.
도 27을 참조하면, 27035 단계에서 제2 SSP(2760)은 수신된 "서버 인증 정보(SPBM.Auth)"를 검증할 수 있다. 만일, 제2 SSP(2760)이 "spbm.Cert.KA"를 수신한 경우, 해당 인증서의 서명을 확인하여 인증서의 유효성을 확인할 수 있다. 또한, 제2 SSP(2760)이 "spbm.Cert.DS"를 수신한 경우, 해당 인증서의 서명을 확인하여 인증서의 유효성을 확인할 수 있다. 또한, 제2 SSP(2760)이 "spbm.ePK.KA"와 이에 대한 디지털 서명을 전송 받은 경우에는, spbm.Cert.DS를 이용하여 디지털 서명을 확인해 수신된 공개키 spbm.ePK.KA 의 무결성을 확인할 수 있다. 또한, 제2 SSP(2760)은 "CiPkIdToBeUsed"을 수신했을 경우 이를 확인해 자신을 검증할 수 있는 적어도 하나 이상의 서명용 인증서(ssp2.Cert.DS)를 선택할 수 있다.
또한, 도면에는 도시되어 있지 않지만, 27035 단계에서 제2 SSP(2760)은 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair)으로 공개키 "ssp2.ePK.KA"와 비밀키 "ssp2.eSK.KA"를 생성한 뒤, 이 키 쌍 중 공개키(ssp2.ePK.KA)를 선택할 수 있다. 또한, 제2 SSP(2760)은 spbm.Cert.KA에 포함되어 있는 키 합의용 공개키나 spbm.ePK.KA 중 하나를 선택한 뒤, 이 값과 ssp2.eSK.KA를 이용하여 향후 서버와의 통신 중 암호화에 사용될 세션 키 ShKey03를 생성할 수 있다. ShKey03는 수신된 "CryptoToBeUsed"에 포함되어 있는 암호화 알고리즘용 세션 키여야 한다.
또한, 27035 단계에서 제2 SSP(2760)은 자신을 인증할 수 있는 "단말 인증 정보(Device.Auth)"를 생성할 수 있다. 이때, "단말 인증 정보(Device.Auth)"는 "ssp2.Cert.DS"를 포함할 수 있다. 또한, "단말 인증 정보(Device.Auth)"는 "ssp2.ePK.KA"를 더 포함할 수 있다. 또한 "단말 인증 정보(Device.Auth)"는 “ssp1.Cert.DS”를 선택적으로 더 포함할 수 있다. 또한 "단말 인증 정보(Device.Auth)"는 finalizationRequest의 일부 및/또는 전체를 포함할 수 있다. 또한 "단말 인증 정보(Device.Auth)"는 finalizationResponse의 일부 및/또는 전체를 포함할 수 있다
이때, 상기에 언급한 "단말 인증 정보(Device.Auth)"의 일부 혹은 전체는 정보의 무결성을 보장하기 위하여 ssp2.Cert.DS를 이용해 검증 가능하도록 디지털 서명이 될 수 있으며, 이 디지털 서명 데이터는 " 단말 인증 정보"의 일부로서 추가될 수 있다. 또한, “단말 인증 정보(Device.Auth)"의 일부 혹은 전체는 앞서 생성된 세션 키 ShKey03를 이용해 암호화될 수 있다.
도 27을 참조하면, 27040 단계에서 제2 SSP(2760)는 제2 LBA(2770)를 거쳐 서버(2700)에게 27035 단계에서 생성했던 "단말 인증 정보(Device.Auth)"를 전달할 수 있다.
도 27을 참조하면, 27045 단계에서 서버(2700)는 수신된 "단말 인증 정보(Device.Auth)"를 검증할 수 있다. 검증 과정의 구체적 절차는 다음과 같다. 서버(2700)는 수신된 "ssp1.Cert.DS" 및/또는 "ssp2.Cert.DS"의 서명을 검증하여 해당 인증서의 유효성을 검증할 수 있다. 또한, 서버(2700)는 수신한 finalizationRequest 및/또는 finalizationResponse의 서명을 검증할 수 있다. 또한, 서버(2700)는 수신한 finalizationRequest 및/또는 finalizationResponse의 내용을 검증할 수 있다. 또한 서버(2700)는 검증한 내용을 바탕으로 기기 간 전송이 된 번들의 내역을 업데이트할 수 있다. 일례로, 서버(2700)는 해당 번들과 제1 SSP(2610) 사이에 존재했던 매핑(mapping) 관계를 해당 번들과 제2 SSP(2760)의 매핑(mapping) 관계로 업데이트할 수 있다.
이 과정에서, 만일 "단말 인증 정보(Device.Auth)"에 암호화된 데이터가 포함되어 있을 경우, 서버(2700)는 전송 받은 ssp2.ePK.KA와 자신의 spbm.Cert.KA에 포함되어 있는 키 합의용 공개키에 대응되는 비밀키나 spbm.eSK.KA를 이용하여 세션 키 ShKey03를 생성하고, 이 세션 키를 이용하여 암호화된 데이터를 복호화한 뒤 검증 과정을 수행할 수 있다.
또한, 27045 단계에서 서버(2700)는 "증명서"를 생성할 수 있다. 도 27 에서 이 증명서는 spbmAttestation 이라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- spbmAttestation은 도 18의 1810에 해당 번들의 "번들 구분자"를 포함할 수 있다. 혹은, 이전 단계에서 수신된 finalizationRequest 및/또는 finalizationResponse의 일부 및/또는 전체 데이터를 포함할 수 있다.
- spbmAttestation은 도 18의 1830에 서버의 식별자 (예컨대, 서비스 제공자의 식별자 및/또는 번들 관리 서버의 식별자 및/또는 서버의 주소)를 포함할 수 있다.
- spbmAttestation은 도 18의 1850에 서버가 번들의 이동 내역을 확인했음을 의미하는 정보를 포함할 수 있다.
- spbmAttestation은 도 18의 1870에 서버가 번들의 이동 내역을 확인한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- spbmAttestation은 도 18의 1890에 서버의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 서버의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
또한 27045 단계에서, 도 27에 도시되어 있지는 않지만, 서버(2700)는 키 합의에 사용될 비대칭 암호화용 키 쌍(key pair) 공개키 "spbm.attestation.ePK.KA"와 비밀키 "spbm.attestation.eSK.KA"를 을 생성할 수 있다. 이때, 키 쌍 "spbm.attestation.ePK.KA 와 spbm.attestation.eSK.KA"는 앞서 생성되었던 "spbm.ePK.KA 와 spbm.eSK.KA"와 동일한 값으로 설정될 수도 있다. 또는, 키 쌍 "spbm.attestation.ePK.KA 와 spbm.attestation.eSK.KA"는 앞서 사용되었던 "spbm.Cert.KA에 포함되어 있는 공개키와 이에 대응되는 비밀키"와 동일한 값으로 설정될 수도 있다. 또한, 서버(2700)은 spbm.attestation.eSK.KA와 ssp2.ePK.KA를 이용하여 세션 키 ShKey04를 생성할 수 있다. 만일 spbm.attstation.eSK.KA를 위해 spbm.eSK.KA 혹은' spbm.Cert.Ka에 포함되어 있는 공개키에 대응되는 비밀키'가 재사용되었다면, 세션 키 ShKey04의 값 역시 이전에 생성되었던 ShKey03의 값으로 설정될 수 있다.
또한 27045 단계에서, 도 27에 도시되어 있지는 않지만, 서버(2700)는 “증명서 검증 자료”를 구성할 수 있다. “증명서 검증 자료”에는 "spbm.Cert.DS"가 포함될 수 있다. 또한, "spbm.attestation.ePK.KA" 및/또는 "spbm.attestation.ePK.KA"에 대한 서버의 전자 서명값이 더 포함될 수 있다.
다양한 실시예에 따르면, 27045 단계에서 생성된 “증명서”와 “증명서 검증 자료”의 일부 및/또는 전체는 ShKey04를 이용해 암호화될 수 있다.
도 27을 참조하면, 27050 단계에서 서버(2700)는 제2 LBA(2770)을 거쳐 제2 SSP(2760)에게 27045 단계에서 생성된 “spbmAttestation”와 “증명서 검증 자료”를 전송할 수 있다.
도 27을 참조하면 27055 단계에서 제2 SSP(2760)는 수신한 “spbmAttestaion” 및/또는 “증명서 검증 자료”를 검증할 수 있다. 만일 전송 받은 데이터에 암호화된 데이터가 포함되어 있다면, 제2 SSP(2760)은 전송 받은 spbm.attestation.ePK.KA 와 자신의 ssp2.eSK.KA를 이용하여 세션 키 ShKey04를 생성하고, 이 세션 키를 이용해 암호화된 데이터를 복호한 뒤 검증을 수행할 수 있다. 만일 수신된 데이터에 디지털 서명이 포함되어 있다면, 제2 SSP(2760)은 spbm.Cert.DS를 검증한 뒤, 이 인증서를 이용해 디지털 서명의 유효성을 검증할 수 있다.
또한, 27055 단계에서 제 2 SSP(2760)는 검증을 마친 후 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제 2 SSP(2760)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
도 27을 참조하면 27060 단계에서 제2 SSP(2760)은 27060 단계의 수행 결과를 제2 LBA(2770)에게 전달할 수 있다. 일례로, 제2 SSP(2760)은 27060 단계의 검증 성공 혹은 실패 결과를 제2 LBA(2770)에게 전달할 수 있다.
도 28은 본 개시의 실시 예에 따른 단말의 구성을 도시하는 도면이다.
도 28 에서 도시된 바와 같이, 단말은 송수신부(Transceiver)(2810) 및 적어도 하나의 프로세서(2820)를 포함할 수 있다. 또한, 단말은 SSP(2830)를 더 포함할 수 있다. 예를 들면, SSP(2830)는 단말에 삽입될 수 있고, 단말에 내장될 수도 있다. 상기 적어도 하나 이상의 프로세서(2820)는 '제어부'로 명명할 수도 있다. 다만, 단말의 구성은 도 28에 제한되지 않으며, 도 28에 도시된 구성 요소들보다 더 많은 구성 요소를 포함하거나, 더 적은 구성 요소를 포함할 수도 있다. 일부 실시예에 따르면, 송수신부(2810), 적어도 하나의 프로세서(2820) 및 메모리(미도시)는 하나의 칩(Chip) 형태로 구현될 수 있다. 또한, SSP(2830)가 내장되는 경우, SSP(2830)를 포함하여, 하나의 칩 형태로 구현될 수 있다.
다양한 실시예에 따르면, 송수신부(2810)는 다른 단말의 송수신부 혹은 외부 서버와 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다. 송수신부(2810)는 송신되는 신호의 주파수를 상승 변환(up converting) 및 증폭하는 RF 송신기와, 수신되는 신호를 저 잡음 증폭하고 주파수를 하강 변환(down converting)하는 RF 수신기 등으로 구성될 수 있다. 다만, 이는 송수신부(2810)의 일 실시예일뿐이며, 송수신부(2810)의 구성요소가 RF 송신기 및 RF 수신기에 한정되는 것은 아니다. 또한, 송수신부(2810)는 무선 채널을 통해 신호를 수신하여 적어도 하나의 프로세서(2820)로 출력하고, 적어도 하나의 프로세서(2820)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다.
다양한 실시예에 따르면, 송수신부(2810)는 다른 단말의 송수신부 혹은 외부 서버로부터 다른 단말에 포함된 SSP의 정보, 다른 단말을 인증할 수 있는 인증 정보, 서버를 인증할 수 있는 인증 정보, 자신을 인증할 수 있는 인증 정보, 번들 이동 코드, 번들 이동 설정, 번들, 도 22 내지 도 27에서 기술된 다양한 증명서 등을 송신하거나 수신할 수 있다.
한편, 적어도 하나의 프로세서(2820)는 단말을 전반적으로 제어하기 위한 구성요소이다. 적어도 하나의 프로세서(2820)는 전술한 바와 같은 본 개시의 다양한 실시 예에 따라, 단말의 전반적인 동작을 제어할 수 있다.
한편, SSP(2830)는 번들을 설치하고 제어하기 위한 프로세서 또는 컨트롤러를 포함하거나, 어플리케이션이 설치되어 있을 수 있다.
다양한 실시예에 따르면, SSP(2830) 내의 적어도 하나의 프로세서 또는 컨트롤러는 번들 이동 설정을 확인하여 특정 번들의 전송 여부를 결정할 수 있다. 또한, 번들 이동 설정을 확인하여 해당 번들의 기기 간 번들 이동 결과를 서버에 등록해야 하는지, 등록이 필요하다면 선 고지가 필요한지의 여부를 판단할 수 있다.
또한, 다양한 실시예에 따르면 SSP 내의 적어도 하나 이상의 프로세서 또는 컨트롤러는 번들 이동 코드를 생성하여 특정 번들의 전송 과정을 제어할 수 있다.
또한, 다양한 실시예에 따르면 SSP 내의 적어도 하나 이상의 프로세서 또는 컨트롤러는 자신의 SSP 정보를 생성할 수 있고, 외부로부터 전송 받은 다른 SSP의 SSP 정보를 확인하고 검증할 수 있다.
또한, 다양한 실시예에 따르면 SSP 내의 적어도 하나 이상의 프로세서 또는 컨트롤러는 자신을 검증할 수 있는 인증 정보를 생성할 수 있고, 외부로부터 전송 받은 다른 SSP의 인증 정보를 검증할 수도 있다.
또한, 다양한 실시예에 따르면 SSP(2830)는 번들을 생성할 수 있고, 단독 혹은 하나 이상의 프로세서 (2820)와 협력하여 번들을 설치할 수 있다. 또한, SSP(2830)는 번들을 관리할 수 있다.
또한, 다양한 실시예에 따르면 SSP(2830)은 도 22 내지 도 27에서 기술된 다양한 형태의 증명서를 생성할 수 있고, 수신된 증명서를 검증할 수 있다.
또한, 다양한 실시예에 따르면 SSP(2830)은 도 22 내지 도 27기술된 것처럼 수신된 증명서의 내용을 기반으로 하여 번들의 상태를 변경할 수 있다.
또한, 다양한 실시예에 따르면, SSP(2830)는 프로세서(2820)의 제어에 따라 동작할 수도 있다. 또는 SSP(2830)는 번들을 설치하고 제어하기 위한 프로세서 또는 컨트롤러를 포함하거나, 어플리케이션이 설치되어 있을 수 있다. 어플리케이션의 일부 또는 전부는 SSP(2830) 또는 메모리(미도시)에 설치되어 있을 수도 있다.
한편, 단말은 메모리(미도시)를 더 포함할 수 있으며, 단말의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(Flash Memory Type), 하드 디스크 타입(Hard Disk Type), 멀티미디어 카드 마이크로 타입(Multimedia Card Micro Type), 카드 타입의 메모리(예를 들면, SD 또는 XD 메모리 등), 자기 메모리, 자기 디스크, 광디스크, 램(Random Access Memory, RAM), SRAM(Static Random Access Memory), 롬(Read-Only Memory, ROM), PROM(Programmable Read-Only Memory), EEPROM(Electrically Erasable Programmable Read-Only Memory) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서(2820)는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.
도 29는 본 개시의 실시 예에 따른 서버의 구성을 도시하는 도면이다. 이때, 서버는 서비스 제공자에 의해 운영되는 서버일 수도 있고, 번들 관리 서버일 수도 있고, 서비스 제공자와 번들 관리 서버의 협업에 의해 운영되는 서버일 수도 있으며, 혹은 서비스 제공자 및/또는 번들 관리 서버와 연계되어 운영되는 임의의 서버일 수도 있다. 본 도면의 설명에서는 서버를 지칭하기 위해 서버의 가능한 예 중 하나인 번들 관리 서버라는 용어를 사용하지만, 앞서 기술하였듯 서버의 종류는 번들 관리 서버로 국한되지 않는다.
일부 실시 예에 따르면, 번들 관리 서버는 송수신부(Transceiver)(2910) 및 적어도 하나 이상의 프로세서(2920)를 포함할 수 있다. 다만, 번들 관리 서버의 구성은 도 29에 제한되지 않으며, 도 29에 도시된 구성 요소들보다 더 많은 구성 요소를 포함하거나, 더 적은 구성 요소를 포함할 수도 있다. 일부 실시예에 따르면, 송수신부(2910), 적어도 하나의 프로세서(2920) 및 메모리(미도시)는 하나의 칩(Chip) 형태로 구현될 수 있다.
일부 실시예에 따르면, 송수신부(2910)는 단말과 본 개시의 다양한 실시 예에 따른 신호, 정보, 데이터 등을 송신 및 수신할 수 있다. 송수신부(2910)는 송신되는 신호의 주파수를 상승 변환 및 증폭하는 RF 송신기와, 수신되는 신호를 저 잡음 증폭하고 주파수를 하강 변환하는 RF 수신기 등으로 구성될 수 있다. 다만, 이는 송수신부(2910)의 일 실시 예일 뿐이며, 송수신부(2910)의 구성요소가 RF 송신기 및 RF 수신기에 한정되는 것은 아니다. 또한, 송수신부(2910)는 무선 채널을 통해 신호를 수신하여 적어도 하나의 프로세서(2920)로 출력하고, 적어도 하나의 프로세서(2920)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다.
한편, 적어도 하나 이상의 프로세서(2920)는 번들 관리 서버를 전반적으로 제어하기 위한 구성요소이다. 프로세서(2920)는 전술한 바와 같은 본 개시의 다양한 실시 예에 따라, 번들 관리 서버의 전반적인 동작을 제어할 수 있다. 상기 적어도 하나 이상의 프로세서(2920)는 제어부로 명명할 수 있다.
한편, 번들 관리 서버는 메모리(미도시)를 더 포함할 수 있으며, 번들 관리 서버의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 또한, 메모리는 플래시 메모리 타입(Flash Memory Type), 하드 디스크 타입(Hard Disk Type), 멀티미디어 카드 마이크로 타입(Multimedia Card Micro Type), 카드 타입의 메모리(예를 들면, SD 또는 XD 메모리 등), 자기 메모리, 자기 디스크, 광디스크, 램(Random Access Memory, RAM), SRAM(Static Random Access Memory), 롬(Read-Only Memory, ROM), PROM(Programmable Read-Only Memory), EEPROM(Electrically Erasable Programmable Read-Only Memory) 중 적어도 하나의 저장매체를 포함할 수 있다. 또한, 프로세서(2920)는 메모리에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.
도 30은 도 19에서 제시된 절차 중 번들의 전송이 마무리되는 절차에 대한 또 다른 세부 절차 및 번들의 전송 결과가 서버에 등록되는 절차를 도시하는 도면이다.
다양한 실시예에 따르면, 단말은 적어도 하나의 LBA 및 적어도 하나의 SSP를 포함할 수 있다. 예를 들면, 도 30의 예에서와 같이, 제1 단말(3000)은 제1 LBA(3020)과 제1 SSP(3010)을 포함하고, 제2 단말(3050)은 제2 LBA(3070)과 제2 SSP(3060)을 포함할 수 있다. 일 예로, 제1 단말(3000)은 제1 SSP(3010)가 장착되고 제1 SSP(3010)을 제어하기 위한 제1 LBA(3020)이 설치된 단말일 수 있고, 제2 단말(3050)은 제2 SSP(3060)가 장착되고 제2 SSP(3060)을 제어하기 위한 제2 LBA(3070)이 설치된 단말일 수 있다.
도 30을 참조하면, 30000 단계에서 다음의 절차들이 수행될 수 있다.
1. 번들 설치
도 30을 참조하면, 30000 단계에서 제2 LBA(3070)과 제2 SSP(3060)은 서로 협업하여 제2 단말(3050)에 번들을 설치할 수 있다. 이 과정에서 다음의 절차들이 함께 수행될 수 있다. 만일 메타데이터가 전송된 경우, 제2 LBA(3070) 혹은 제2 SSP(3060)은 메타데이터에 포함된 내용을 검증할 수 있다. 만일 "번들 이동 설정"이 전송되었다면, 제2 LBA(3070)은 상기 정보를 제2 SSP(3060)으로 전달할 수 있다. 만일 트랜잭션 아이디(transaction ID)가 전송되었다면, 제2 LBA(3070) 혹은 제2 SSP(3060)은 이 트랜잭션 아이디가 현재 세션에서 사용되었던 트랜잭션 아이디와 동일한지의 여부를 검사할 수 있다. 만일 번들 식별자(SPB ID), 번들 패밀리 식별자(SPB Family ID), 번들 패밀리 관리자 식별자(SPB Family Custodian Object ID) 중 적어도 하나가 전송되었다면, 제2 LBA(3070) 혹은 제2 SSP(3060)은 이 정보가 현재 수신하려는 번들의 정보와 일치하는지의 여부를 확인할 수 있다. 만일 ssp1.Cert.DS이 전송되었다면, 제2 SSP(3060)은 이 인증서의 유효성을 검증해 제1 SSP(3010)을 인증할 수 있다. 만일 전송 받은 데이터에 암호화된 데이터가 포함되어 있다면, 제2 SSP(3060)은 전송 받은 ssp1.bundle.ePK.KA 와 자신의 ssp2.eSK.KA를 이용하여 세션 키 ShKey02를 생성하고, 이 세션 키를 이용해 암호화된 데이터를 복호한 뒤 검증을 수행할 수 있다. 만일 수신된 데이터에 디지털 서명이 포함되어 있다면, 제2 SSP(3060)은 ssp1.Cer.DS를 검증한 뒤, 이 인증서를 이용해 디지털 서명의 유효성을 검증할 수 있다.
2. “등록 설정” 확인
또한, 도면에는 도시되지 않았지만, 제 2 LBA(3070) 및/또는 제 2 SSP(3060)는 해당 번들의 “등록 설정”을 이용해 '고지 필요 여부' 및/또는 '선 고지 필요 여부' 및/또는 '고지 내용의 암호화 필요 여부'를 확인할 수 있다. 이 과정은 30000 단계의 일부로써 30000 단계에서 이루어지는 다른 절차들과 순서에 상관 없이 독립적으로 이루어질 수 있다. 혹은 30000 단계 이후 30040 혹은 30050 에서 고지가 이루어지기 전, “등록 설정”을 확인해 판단이 필요한 순간에 수행될 수도 있다.
도 30을 참조하면, 30005 단계에서 제 2 SSP(3060)은 해당 번들의 상태를 "IN TRANSITION"으로 설정할 수 있다. "IN TRANSITION"은 번들이 성공적으로 설치되어 있지만 사용이 불가한 상태 (또한, '제 1 단말(3000)의 요청' 및/또는 '외부 서버의 요청'과 같은 동작에 의해서만 사용 가능한 상태 (Disabled, Enable, Active 상태)로 변경될 수 있는 상태)를 의미할 수 있다.
도 30을 참조하면, 30010 단계에서 제 2 LBA(3070)은 제 2 SSP(3060)에게 "증명서"를 요청할 수 있다.
도 30을 참조하면, 30015 단계에서 제 2 SSP(3060)은 "증명서"를 생성할 수 있다. 도 30 에서 이 증명서는 finalizationRequest라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationRequest는 도 18의 510에 해당 번들의 "번들 구분자"를 포함할 수 있다.
- finalizationRequest는 도 18의 530에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationRequest는 도 18의 1850에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- finalizationRequest는 도 18의 1870에 제 2 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- finalizationRequest는 도 18의 1890에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 22를 참조하면, 30020 단계에서 제 2 SSP(3060)은 제 1 SSP(3010)에게 finalizationRequest를 전달할 수 있다. 예를 들어, 제 2 SSP(3060)은 제 1 SSP(3010)에게 다음과 같은 과정을 거쳐 finalizationRequest를 전달할 수 있다. 즉, 제 2 SSP(3060)은 제 2 LBA (3070) 에게 30010 단계의 응답으로 finalizationRequest를 전달하고, 제 2 LBA(3070)은 제 1 LBA(3020)을 거쳐 제 1 SSP(3010) 에게 finalizationRequest를 전달할 수 있다.
도 30을 참조하면, 30025 단계에서 제 1 SSP(3010)은 수신한 finalizationRequest를 검증할 수 있다. 이 검증 과정은, finalizationRequest에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationRequest에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자 인지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationRequest에 포함된 명령어 정보가 번들의 상태를 “IN TRANSITION” 상태로 변경하는 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 30025 단계에서 제 1 SSP(3010)는 검증을 마친 후 해당 번들의 상태를 "IN TRANSITION"으로 설정할 수 있다. "IN TRANSITION"은 번들이 성공적으로 설치되어 있지만 사용이 불가한 상태 (또한, '제 2 단말(3050)의 요청' 및/또는 '외부 서버의 요청'과 같은 추가 동작에 의해서만 사용 가능한 상태 (Disabled, Enable, Active 상태)로 변경될 수 있는 상태)를 의미할 수 있다.
또한, 30025 단계에서 제 1 SSP(3010)는 "증명서"를 생성할 수 있다. 도 30 에서 이 증명서는 finalizationResponse라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- finalizationResponse는 도 18의 510에 해당 번들의 "번들 구분자"를 포함할 수 있다. 혹은, 이전 단계에서 수신된 finalizationRequest 의 일부 및/또는 전체 데이터를 포함할 수 있다.
- finalizationResponse는 도 18의 530에 제 1 SSP의 "SSP 식별자"를 포함할 수 있다.
- finalizationResponse는 도 18의 1850에 제 1 SSP가 번들의 상태를 “IN TRANSITION” 상태로 설정했음을 의미하는 정보를 포함할 수 있다.
- finalizationResponse는 도 18의 1870에 제 1 SSP가 번들을 상태를 “IN TRANSITION” 상태로 설정한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- finalizationResponse는 도 18의 1890에 제 1 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 1 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 30을 참조하면, 30030 단계에서 제 1 SSP(3010)은 제 2 SSP(3060)에게 finalizationResponse를 전달할 수 있다. 예를 들어, 제 1 SSP(3010)은 제 1 LBA(3020)과 제 2 LBA(3070)을 거쳐 제 2 SSP(3060)에게 finalizationResponse를 전달할 수 있다.
도 30을 참조하면, 30035 단계에서 제 2 SSP(3060)은 수신한 finalizationResponse를 검증할 수 있다. 이 검증 과정은, finalizationResponse에 포함된 제 1 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 선택적으로 더 포함할 수 있다. 또한, 이 검증 과정은, finalizationResponse에 포함된 finalizationRequest의 데이터 일부 혹은 전체가 자신이 전송했던 정보와 일치하는지 여부를 검사하는 과정을 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 "SSP 식별자"를 확인하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 finalizationResponse에 포함된 명령어 정보가 번들의 상태를 “IN TRANSITION”으로 설정하는 것인지 확인하는 과정을 더 포함할 수 있다.
도 30을 참조하면, 30040 단계에서 선 고지(Pre-notification) 절차가 수행될 수 있다. 이 절차는 “등록 설정”에 선 고지가 필요하다고 설정되어 있을 경우 적용되는 절차일 수 있다. 만일 선 고지 절차가 수행된다면 이 절차는 아래와 같을 수 있다.
우선 제 2 SSP(3060)가 sspInfoSelected를 생성하고 이 정보를 제 2 LBA(3070)으로 전송할 수 있다. 이 과정은 필요에 따라 생략될 수도 있다. 이 때, sspInfoSelected에 대한 설명은 도 26의 설명을 참조하기로 한다. 이후 도 27에 기술된 절차 중 27055 단계의 “번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경하는 절차” 이전까지의 과정이 수행될 수 있다.
도 30을 참조하면, 30045 단계에서 제 2 SSP(3060)는 번들의 상태를 사용 가능한 상태 중 하나(Disabled, Enable, Active 중 하나)로 변경할 수 있다. 예를 들어, 도면에 도시된 것처럼, 제 2 SSP(3060)는 번들의 상태를 Disabled 상태로 변환할 수 있다.
또한, 30045 단계에서 제 2 SSP(3060)는 "증명서"를 생성할 수 있다. 도 30 에서 이 증명서는 spblAttestation 이라 불릴 수 있다. 이 증명서의 구조는 도 18에 개시된 구조를 따를 수 있다.
이때, 가능한 증명서 구성의 한 가지 예는 다음과 같다.
- spblAttestation은 도 18의 510에 해당 번들의 "번들 구분자"를 포함할 수 있다. 혹은, 'finalizationRequest 및/또는 finalizationResponse 및/또는 spbmAttestaion' 의 일부 및/또는 전체 데이터를 포함할 수 있다.
- spblAttestation은 도 18의 530에 제 2 SSP의 "SSP 식별자"를 포함할 수 있다.
- spblAttestation은 도 18의 1850에 제 2 SSP가 번들을 사용 가능한 상태 중 하나로 변경했음을 의미하는 정보를 포함할 수 있다.
- spblAttestation은 도 18의 1870에 제 2 SSP가 번들의 상태를 사용 가능한 상태 중 하나로 변경한 시간 혹은 증명서를 만든 시간을 선택적으로 포함할 수 있다. 혹은 후술할 전자 서명에 사용된 서명용 인증서의 정보와 그와 관련된 인증서 체인의 정보들을 포함할 수 있다.
- spblAttestation은 도 18의 1890에 제 2 SSP의 서명 정보를 포함할 수 있다. 이 서명은 앞서 기술한 정보에 대해 제 2 SSP의 서명용 인증서로 전자 서명을 한 서명 정보일 수 있다.
도 30을 참조하면, 30050 단계에서 후 고지(Post-notification) 절차가 수행될 수 있다. 이 절차는 “등록 설정”에 선 고지가 필요하지 않다고 설정되어 있을 경우 적용되는 절차일 수 있다. 만일 후 고지 절차가 수행된다면 이 절차는 아래와 같을 수 있다.
a. “등록 설정”에 고지 내용의 암호화가 필요하다고 설정되어 있는 경우
우선 제 2 SSP(3060)가 sspInfoSelected를 생성하고 이 정보를 제 2 LBA(3070)으로 전송할 수 있다. 이 과정은 필요에 따라 생략될 수도 있다. 이 때, sspInfoSelected에 대한 설명은 도 22의 설명을 참조하기로 한다. 이후 도 23에 기술된 절차가 수행될 수 있다
b. “등록 설정”에 고지 내용의 암호화가 필요하지 않다고 설정되어 있는 경우
우선 제 2 SSP(3060)가 spblAttestation을 제 2 LBA (3070)에게 전송할 수 있다. 이후 도 25에 기술된 절차가 수행될 수 있다.
도 30을 참조하면, 30055 단계에서 제 2 SSP (3060)은 제 2 LBA (3070)과 제 1 LBA (3020)을 거쳐 제 1 SSP(3010)에게 spblAttestation을 전송할 수 있다.
도 30을 참조하면, 30060 단계에서 제 1 SSP(3010)은 수신한 spblAttestation 을 검증할 수 있다. 이 검증 과정은, spblAttestation에 포함된 제 2 SSP의 서명의 유효성을 검사하는 단계를 포함할 수 있다. 또한, 이 검증 과정은, spblAttestation에 포함된 "번들 구분자"가 해당 번들의 번들 구분자와 일치하는지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 spblAttestation에 포함된 "SSP 식별자"가 제 2 SSP의 올바른 식별자 인지 여부를 검사하는 과정을 더 포함할 수 있다. 또한, 이 검증 과정은 spblAttestation에 포함된 명령어 정보가 번들의 상태를 사용 가능한 상태 중 하나로 설정한 것인지를 확인하는 과정을 더 포함할 수 있다.
또한, 30060 단계에서 제 1 SSP(3010)는 번들을 삭제할 수 있다.
30045 단계에서 spblAttestation을 생성하는 절차 및/또는 30055 단계 및/또는 30060 단계는 필요에 따라 생략될 수 있다.
30040 또는 30050 단계에 기술된 고지 과정이 완료되지 않은 경우 (예를 들어, 서버로 고지를 보냈으나 이에 대한 응답을 받지 못한 경우) 제 2 단말은 반복해서 고지를 서버로 재전송할 수 있다. 재전송 과정은 기 설정된 재전송 최대 횟수에 따라 이 최대값을 만족할 때까지 이루어질 수도 있고, 혹은 서버에서 응답이 올 때까지 반복해서 이루어질 수도 있다.
“등록 설정”에 따라 선 고지가 필요하지만 30040 과정이 정상적으로 수행되지 않아 제 1 단말(3000)과 제 2 단말(3050) 양 기기에서 번들이 사용 불가능해진 경우, 도 29에 설명된 서버의 요청에 의해 제 1 단말(3000) 및/혹은 제 2 단말(3050)에 설치된 번들의 상태가 “IN TRANSITION”으로부터 사용 가능한 상태 중 하나 (예컨대, Disabled 상태)로 변경될 수 있다.
상술한 본 개시의 구체적인 실시 예들에서, 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.
본 개시의 다양한 실시 예들 및 이에 사용된 용어들은 본 개시에 기재된 기술을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 및/또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함할 수 있다. 본 개시에서, "A 또는 B", "A 및/또는 B 중 적어도 하나", "A, B 또는 C" 또는 "A, B 및/또는 C 중 적어도 하나" 등의 표현은 함께 나열된 항목들의 모든 가능한 조합을 포함할 수 있다. "제1", "제2", "첫째" 또는 "둘째" 등의 표현들은 해당 구성요소들을, 순서 또는 중요도에 상관없이 수식할 수 있고, 한 구성요소를 다른 구성요소와 구분하기 위해 사용될 뿐 해당 구성요소들을 한정하지 않는다. 어떤(예: 제1) 구성요소가 다른(예: 제2) 구성요소에 "(기능적으로 또는 통신적으로) 연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로 연결되거나, 다른 구성요소(예: 제3 구성요소)를 통하여 연결될 수 있다.
본 개시에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구성된 유닛을 포함하며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로 등의 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 모듈은 ASIC(application-specific integrated circuit)으로 구성될 수 있다.
본 개시의 다양한 실시 예들은 기기(machine)(예: 컴퓨터)로 읽을 수 있는 저장 매체(machine-readable storage media)(예: 내장 메모리 또는 외장 메모리)에 저장된 명령어를 포함하는 소프트웨어(예: 프로그램)로 구현될 수 있다. 기기는, 저장 매체로부터 저장된 명령어를 호출하고, 호출된 명령어에 따라 동작이 가능한 장치로서, 다양한 실시 예들에 따른 단말을 포함할 수 있다. 상기 명령이 프로세서에 의해 실행될 경우, 프로세서가 직접, 또는 상기 프로세서의 제어 하에 다른 구성요소들을 이용하여 상기 명령에 해당하는 기능을 수행할 수 있다. 명령은 컴파일러 또는 인터프리터에 의해 생성 또는 실행되는 코드를 포함할 수 있다.
기기로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, '비일시적'은 저장매체가 신호(signal)를 포함하지 않으며 실재(tangible)한다는 것을 의미할 뿐 데이터가 저장매체에 반영구적 또는 임시적으로 저장됨을 구분하지 않는다.
본 개시에 개시된 다양한 실시 예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory (CD-ROM))의 형태로, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 온라인으로 배포될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다. 다양한 실시 예들에 따른 구성 요소(예: 모듈 또는 프로그램) 각각은 단수 또는 복수의 개체로 구성될 수 있으며, 전술한 해당 서브 구성 요소들 중 일부 서브 구성 요소가 생략되거나, 또는 다른 서브 구성 요소가 다양한 실시 예에 더 포함될 수 있다. 대체적으로 또는 추가적으로, 일부 구성 요소들(예: 모듈 또는 프로그램)은 하나의 개체로 통합되어, 통합되기 이전의 각각의 해당 구성 요소에 의해 수행되는 기능을 동일 또는 유사하게 수행할 수 있다. 다양한 실시 예들에 따른, 모듈, 프로그램 또는 다른 구성 요소에 의해 수행되는 동작들은 순차적, 병렬적, 반복적 또는 휴리스틱하게 실행되거나, 적어도 일부 동작이 다른 순서로 실행되거나, 생략되거나, 또는 다른 동작이 추가될 수 있다.

Claims (15)

  1. 제1 단말의 동작 방법에 있어서,
    제2 단말로, 번들을 전송하는 단계;
    상기 제2 단말로부터, 제2 단말의 번들 상태 정보를 포함하여 생성된 제1 증명서를 수신하는 단계;
    상기 수신된 제1 증명서를 검증하는 단계;
    상기 제1 증명서를 검증한 후, 제1 단말의 번들 상태 정보를 포함하는 제2 증명서를 생성하는 단계; 및
    상기 제2 단말로 상기 제2 증명서를 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
  2. 제1 항에 있어서,
    상기 제1 단말의 번들 상태 정보는 상기 제1 단말의 번들 상태가 DELETE, IN TRANSITION, SUSPENSION 중 적어도 하나로 설정되는 것을 포함하고,
    상기 제1 단말의 번들 상태가 IN TRANSITION 로 설정된 경우, 상기 제2 단말로부터 제2 단말의 번들 상태 변경에 대한 정보를 포함하여 생성된 제3 증명서를 수신하는 단계;
    상기 수신된 제3 증명서를 검증하는 단계; 및
    상기 제3 증명서를 검증한 후, 상기 제1 단말의 번들을 삭제(DELETE)하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  3. 제1 항에 있어서,
    상기 제2 단말에 의해, 상기 제1 증명서 및 상기 제2 증명서의 검증 결과에 대한 정보를 포함하는 제4 증명서가 생성되고,
    상기 제4 증명서가 서버로 전송되고, 및
    상기 서버에 의해, 상기 제4 증명서는 검증되는 것을 특징으로 하는 방법.
  4. 제1 항에 있어서,
    서버에 의해, 상기 서버와의 인증 결과를 포함하는 제5 증명서가 생성되고,
    상기 제5 증명서는 상기 제2 단말로 전송되고, 및
    상기 제2 단말에 의해, 상기 제5 증명서는 검증되는 것을 특징으로 하는 방법.
  5. 제2 단말의 동작 방법에 있어서,
    제1 단말로부터, 번들을 수신하는 단계;
    상기 번들을 설치하는 단계;
    제2 단말의 번들 상태 정보를 포함하는 제1 증명서를 생성하는 단계;
    상기 제1 단말로, 상기 제1 증명서를 전송하는 단계;
    상기 제1 단말로부터, 제1 단말의 번들 상태 정보를 포함하여 생성된 제2 증명서를 수신하는 단계;
    상기 수신된 제2 증명서를 검증하는 단계; 및
    상기 제2 증명서를 검증한 후, 제2 단말의 번들 상태 설정 정보를 변경하는 단계를 포함하는 것을 특징으로 하는 방법.
  6. 제5 항에 있어서,
    상기 제2 단말의 번들 상태 설정 정보를 변경하는 단계는 상기 제2 단말의 번들 상태를 활성화(enable), 구동 상태(Active) 및 비활성화(Disabled) 중 적어도 하나로 변경하는 단계이고,
    상기 제1 단말의 번들 상태 정보는 상기 제1 단말의 번들 상태가 DELETE, IN TRANSITION, SUSPENSION 중 적어도 하나로 설정되고,
    상기 제1 단말의 번들 상태가 IN TRANSITION 로 설정된 경우, 제2 단말의 번들 상태 변경에 대한 정보를 포함하는 제3 증명서를 생성하는 단계; 및
    상기 제1 단말로, 상기 제3 증명서를 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  7. 제5 항에 있어서,
    상기 제1 증명서 및 상기 제2 증명서의 검증 결과에 대한 정보를 포함하는 제4 증명서를 생성하는 단계; 및
    서버로, 상기 제4 증명서를 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  8. 제5 항에 있어서,
    서버로부터, 상기 서버와의 인증 결과를 포함하여 생성된 제5 증명서를 수신하는 단계;
    상기 수신된 제5 증명서를 검증하는 단계; 및
    상기 제5 증명서를 검증한 후, 제2 단말의 번들 상태 설정 정보를 변경하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  9. 제1 단말에 있어서,
    적어도 하나의 신호를 송수신을 할 수 있는 송수신부; 및
    상기 송수신부와 결합된 제어부를 포함하고,
    상기 제어부는 :
    제2 단말로, 번들을 전송하고,
    상기 제2 단말로부터, 제2 단말의 번들 상태 정보를 포함하여 생성된 제1 증명서를 수신하고,
    상기 수신된 제1 증명서를 검증하고,
    상기 제1 증명서를 검증한 후, 제1 단말의 번들 상태 정보를 포함하는 제2 증명서를 생성하고, 그리고
    상기 제2 단말로 상기 제2 증명서를 전송하도록 구성되는 것을 특징으로 하는 제1 단말.
  10. 제9 항에 있어서,
    상기 제어부는 :
    상기 제1 단말의 번들 상태가 IN TRANSITION 로 설정된 경우, 상기 제2 단말로부터 제2 단말의 번들 상태 변경에 대한 정보를 포함하여 생성된 제3 증명서를 수신하고,
    상기 수신된 제3 증명서를 검증하고, 그리고
    상기 제3 증명서를 검증한 후, 상기 제1 단말의 번들을 삭제(DELETE)하도록 더 구성되고,
    상기 제1 단말의 번들 상태 정보는 상기 제1 단말의 번들 상태가 DELETE, IN TRANSITION, SUSPENSION 중 적어도 하나로 설정되는 것을 포함하는 것을 특징으로 하는 제1 단말.
  11. 제9 항에 있어서,
    상기 제2 단말에 의해, 상기 제1 증명서 및 상기 제2 증명서의 검증 결과에 대한 정보를 포함하는 제4 증명서가 생성되고,
    상기 제4 증명서가 서버로 전송되고, 및
    상기 서버에 의해, 상기 제4 증명서는 검증되는 것을 특징으로 하는 제1 단말.
  12. 제9 항에 있어서,
    서버에 의해, 상기 서버와의 인증 결과를 포함하는 제5 증명서가 생성되고,
    상기 제5 증명서는 상기 제2 단말로 전송되고, 및
    상기 제2 단말에 의해, 상기 제5 증명서는 검증되는 것을 특징으로 하는 제1 단말.
  13. 제2 단말에 있어서,
    적어도 하나의 신호를 송수신을 할 수 있는 송수신부; 및
    상기 송수신부와 결합된 제어부를 포함하고,
    상기 제어부는 :
    제1 단말로부터, 번들을 수신하고,
    상기 번들을 설치하고,
    제2 단말의 번들 상태 정보를 포함하는 제1 증명서를 생성하고,
    상기 제1 단말로, 상기 제1 증명서를 전송하고,
    상기 제1 단말로부터, 제1 단말의 번들 상태 정보를 포함하여 생성된 제2 증명서를 수신하고,
    상기 수신된 제2 증명서를 검증하고, 그리고
    상기 제2 증명서를 검증한 후, 제2 단말의 번들 상태 설정 정보를 변경하도록 구성되는 것을 특징으로 하는 제2 단말.
  14. 제13 항에 있어서, 상기 제어부는 :
    상기 제2 단말의 번들 상태를 활성화(enable), 구동 상태(Active) 및 비활성화(Disabled) 중 적어도 하나로 변경하도록 구성되고,
    상기 제1 단말의 번들 상태가 IN TRANSITION 로 설정된 경우, 제2 단말의 번들 상태 변경에 대한 정보를 포함하는 제3 증명서를 생성하고, 그리고
    상기 제1 단말로 상기 제3 증명서를 전송하도록 더 구성되고,
    상기 제1 단말의 번들 상태 정보는 상기 제1 단말의 번들 상태가 DELETE, IN TRANSITION, SUSPENSION 중 적어도 하나로 설정되는 것을 특징으로 하는 제2 단말.
  15. 제13 항에 있어서, 상기 제어부는 :
    상기 제1 증명서 및 상기 제2 증명서의 검증 결과에 대한 정보를 포함하는 제4 증명서를 생성하고, 그리고
    서버로, 상기 제4 증명서를 전송하도록 더 구성되는 것을 특징으로 하는 제2 단말.
PCT/KR2020/012728 2019-09-20 2020-09-21 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치 WO2021054808A1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202080080987.6A CN114731505A (zh) 2019-09-20 2020-09-21 用于在装置之间的包传输后设置包的状态的方法和设备
US17/762,047 US20220385670A1 (en) 2019-09-20 2020-09-21 Method and device for setting state of bundle after transfer of bundle between apparatuses
JP2022517517A JP2022549182A (ja) 2019-09-20 2020-09-21 機器の間のバンドル移動後のバンドルの状態を設定する方法及び装置
EP20865704.9A EP4017047A4 (en) 2019-09-20 2020-09-21 METHOD AND DEVICE FOR ADJUSTING THE STATE OF A BEAM AFTER BEAM TRANSFER BETWEEN APPARATUS

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
KR20190116222 2019-09-20
KR10-2019-0116222 2019-09-20
KR10-2019-0140219 2019-11-05
KR20190140219 2019-11-05
KR10-2019-0150329 2019-11-21
KR20190150329 2019-11-21
KR20190150466 2019-11-21
KR10-2019-0150466 2019-11-21
KR10-2020-0120292 2020-09-18
KR1020200120292A KR20210034522A (ko) 2019-09-20 2020-09-18 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2021054808A1 true WO2021054808A1 (ko) 2021-03-25

Family

ID=74883499

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/012728 WO2021054808A1 (ko) 2019-09-20 2020-09-21 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치

Country Status (5)

Country Link
US (1) US20220385670A1 (ko)
EP (1) EP4017047A4 (ko)
JP (1) JP2022549182A (ko)
CN (1) CN114731505A (ko)
WO (1) WO2021054808A1 (ko)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140086950A (ko) * 2011-09-28 2014-07-08 주식회사 케이티 프로파일 관리 방법, 내장 ｕｉｃｃ 및 내장 ｕｉｃｃ 탑재 기기
KR20160032603A (ko) * 2014-09-16 2016-03-24 삼성전자주식회사 네트워크 서비스를 제공하는 방법과 전자 장치
KR20190027488A (ko) * 2017-09-07 2019-03-15 삼성전자주식회사 무선 통신 시스템에서 디바이스들의 프로파일 이동을 지원하는 방법 및 장치

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2999319B1 (fr) * 2012-12-10 2015-01-09 Oberthur Technologies Procede et systeme de gestion d'un element securise integre ese
KR102193619B1 (ko) * 2013-07-01 2020-12-21 삼성전자주식회사 전자 디바이스에서 어플리케이션의 상태정보를 업데이트하는 방법, 관리하는 방법 및 그 전자 디바이스
KR102293683B1 (ko) * 2017-02-13 2021-08-26 삼성전자 주식회사 eSIM 접근 제어 방법 및 장치

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140086950A (ko) * 2011-09-28 2014-07-08 주식회사 케이티 프로파일 관리 방법, 내장 ｕｉｃｃ 및 내장 ｕｉｃｃ 탑재 기기
KR20160032603A (ko) * 2014-09-16 2016-03-24 삼성전자주식회사 네트워크 서비스를 제공하는 방법과 전자 장치
KR20190027488A (ko) * 2017-09-07 2019-03-15 삼성전자주식회사 무선 통신 시스템에서 디바이스들의 프로파일 이동을 지원하는 방법 및 장치

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Approved minutes 12th meeting ad hoc multistakeholder group on Mobile Contactless SEPA Cards Interoperability Implementation Guidelines (MCP IIGs) 23 February 2018", APPROVED MINUTES 12TH MEETING AD HOC MULTISTAKEHOLDER GROUP ON MOBILE CONTACTLESS SEPA CARDS INTEROPERABILITY IMPLEMENTATION GUIDELINES (MCP IIGS) 23 FEBRUARY 2018, vol. MSG MCP 008-2018, no. V1.0, 23 May 2018 (2018-05-23), pages 1 - 10, XP009526969 *
ANONYMOUS: "Smart Cards; Smart Secure Platform (SSP); Requirements Specification", 3GPP DRAFT; SCP(19)000090_DRAFT_TS_103_465_V15_0_0, vol. SA WG3, no. V15_0_0, 23 April 2019 (2019-04-23), pages 1 - 50, XP051721330 *
See also references of EP4017047A4 *

Also Published As

Publication number Publication date
US20220385670A1 (en) 2022-12-01
CN114731505A (zh) 2022-07-08
EP4017047A4 (en) 2022-10-19
JP2022549182A (ja) 2022-11-24
EP4017047A1 (en) 2022-06-22

Similar Documents

Publication Publication Date Title
WO2017039320A1 (ko) 통신 시스템에서 프로파일 다운로드 방법 및 장치
WO2019050325A1 (en) METHOD AND APPARATUS FOR SUPPORTING PROFILE TRANSFER BETWEEN DEVICES IN A WIRELESS COMMUNICATION SYSTEM
WO2020171672A1 (en) Method for interoperating between bundle download process and esim profile download process by ssp terminal
WO2016178548A1 (ko) 프로파일 제공 방법 및 장치
WO2018135919A1 (en) Apparatus and method for providing and managing security information in communication system
WO2016163796A1 (en) Method and apparatus for downloading a profile in a wireless communication system
WO2020080909A1 (en) Method and apparatus for handling remote profile management exception
WO2022045789A1 (en) Method and apparatus for recovering profile in case of device change failure
WO2015061992A1 (zh) 一种密钥配置方法、系统和装置
WO2019107977A1 (en) Method and electronic device for providing communication service
WO2020013677A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
EP3520363A1 (en) Apparatus and method for providing and managing security information in communication system
WO2020204269A1 (ko) 엣지 컴퓨팅 서비스를 위한 방법 및 그의 전자 장치
WO2021066569A1 (en) Method and apparatus for reinstalling sim profile in wireless communication system
WO2019107876A1 (en) Method and apparatus for managing event in communication system
WO2021002696A1 (en) Method for transferring subscription and electronic device for supporting the same
EP3854115A1 (en) Method and apparatus for handling remote profile management exception
WO2020226466A1 (en) Method and apparatus for managing and verifying certificate
WO2020171475A1 (ko) 무선 통신 시스템의 기기변경 방법 및 장치
WO2022139373A1 (en) Method and apparatus to manage authentication and subscription information in wireless communication system
WO2020184995A1 (ko) Euicc 단말을 변경하는 방법 및 장치
WO2021054808A1 (ko) 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치
WO2021201644A1 (en) Method and apparatus for managing event for smart secure platform
WO2021054780A1 (ko) 기기 간 번들 또는 프로파일 이동 시 기기 간 상호 인증 방법 및 장치
WO2022030960A1 (en) Apparatus and methods for linkage of or profile transfer between devices

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20865704

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022517517

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020865704

Country of ref document: EP

Effective date: 20220316