WO2024034949A1 - 무선 통신 시스템에서, 프로파일을 프로비저닝하기 위한 방법 및 장치 - Google Patents

무선 통신 시스템에서, 프로파일을 프로비저닝하기 위한 방법 및 장치 Download PDF

Info

Publication number
WO2024034949A1
WO2024034949A1 PCT/KR2023/011123 KR2023011123W WO2024034949A1 WO 2024034949 A1 WO2024034949 A1 WO 2024034949A1 KR 2023011123 W KR2023011123 W KR 2023011123W WO 2024034949 A1 WO2024034949 A1 WO 2024034949A1
Authority
WO
WIPO (PCT)
Prior art keywords
profile
euicc
server
terminal
bpp
Prior art date
Application number
PCT/KR2023/011123
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 KR1020220160219A external-priority patent/KR20240022967A/ko
Priority claimed from KR1020230038787A external-priority patent/KR20240022974A/ko
Priority claimed from KR1020230073672A external-priority patent/KR20240022979A/ko
Priority claimed from KR1020230093155A external-priority patent/KR20240022985A/ko
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Publication of WO2024034949A1 publication Critical patent/WO2024034949A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • 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/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • 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
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data

Definitions

  • This disclosure relates to a method and apparatus for provisioning a profile in a wireless communication system.
  • the present disclosure relates to a method and apparatus for provisioning a plurality of profiles to a terminal in a wireless communication system.
  • 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and includes sub-6 GHz ('Sub 6GHz') bands such as 3.5 gigahertz (3.5 GHz) as well as millimeter wave (mm) bands such as 28 GHz and 39 GHz. It is also possible to implement it in the ultra-high frequency band ('Above 6GHz') called Wave.
  • 'Sub 6GHz' sub-6 GHz
  • mm millimeter wave
  • Wave ultra-high frequency band
  • 6G mobile communication technology which is called the system of Beyond 5G
  • Terra is working to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low delay time that is reduced to one-tenth. Implementation in Terahertz bands (e.g., 95 GHz to 3 THz) is being considered.
  • ultra-wideband services enhanced Mobile BroadBand, eMBB
  • ultra-reliable low-latency communications URLLC
  • massive machine-type communications mMTC
  • numerology support multiple subcarrier interval operation, etc.
  • dynamic operation of slot format initial access technology to support multi-beam transmission and broadband
  • definition and operation of BWP Band-Width Part
  • New channel coding methods such as LDPC (Low Density Parity Check) codes for data transmission and Polar Code for highly reliable transmission of control information
  • L2 pre-processing L2 pre-processing
  • dedicated services specialized for specific services. Standardization of network slicing, etc., which provides networks, has been carried out.
  • V2X Vehicle-to-Everything
  • NR-U New Radio Unlicensed
  • UE Power Saving NR terminal low power consumption technology
  • NTN Non-Terrestrial Network
  • IAB provides a node for expanding the network service area by integrating intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, and wireless backhaul links and access links.
  • Intelligent factories Intelligent Internet of Things, IIoT
  • Mobility Enhancement including Conditional Handover and DAPS (Dual Active Protocol Stack) handover
  • 2-step Random Access (2-step RACH for simplification of random access procedures)
  • Standardization in the field of wireless interface architecture/protocol for technologies such as NR is also in progress
  • 5G baseline for incorporating Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technology Standardization in the field of system architecture/services for architecture (e.g., Service based Architecture, Service based Interface) and Mobile Edge Computing (MEC), which provides services based on the location of the terminal, is also in progress.
  • NFV Network Functions Virtualization
  • SDN Software-Defined Networking
  • FD-MIMO full dimensional MIMO
  • array antennas to ensure coverage in the terahertz band of 6G mobile communication technology.
  • multi-antenna transmission technology such as Large Scale Antenna, metamaterial-based lens and antenna to improve coverage of terahertz band signals, high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum), RIS ( In addition to Reconfigurable Intelligent Surface technology, Full Duplex technology, satellite, and AI (Artificial Intelligence) to improve the frequency efficiency of 6G mobile communication technology and system network are utilized from the design stage and end-to-end.
  • the present disclosure seeks to provide a method and device for installing a large number of profiles in a terminal in a wireless communication system.
  • a method performed by a terminal equipped with an embedded universal integrated circuit card (eUICC) in a wireless communication system includes a bound profile package (BPP) for installing a profile from a factory IT server and the BPP.
  • BPP bound profile package
  • the present disclosure can provide a method and device that can effectively install profiles in a wireless communication system.
  • Figure 1 is a diagram showing the relationship between components for provisioning a profile according to an embodiment of the present disclosure.
  • Figure 2 is a diagram for explaining the operation of provisioning a large number of profiles according to an embodiment of the present disclosure.
  • FIG. 3 is a diagram illustrating an operation of preparing a profile to provision a large number of profiles according to an embodiment of the present disclosure.
  • FIG. 4 is a diagram illustrating the operation of installing the profile in FIG. 2 from Factory IT to the eUICC according to an embodiment of the present disclosure.
  • FIG. 5 is a diagram illustrating the operation of installing the profile in FIG. 2 from Factory IT to the eUICC according to an embodiment of the present disclosure.
  • FIG. 6 is a diagram illustrating the operation of installing the profile in FIG. 2 from Factory IT to the eUICC according to an embodiment of the present disclosure.
  • Figure 7 is a block diagram showing the structures of a profile server, Factory IT, and a terminal in a wireless communication system according to an embodiment of the present disclosure.
  • Figure 8 is a block diagram showing the structure of Factory IT in a wireless communication system according to an embodiment of the present disclosure.
  • the base station is the entity that performs resource allocation for the terminal and may be at least one of gNode B, eNode B, Node B, BS (Base Station), wireless access unit, base station controller, or node on the network.
  • a terminal may include a user equipment (UE), a mobile station (MS), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing communication functions.
  • UE user equipment
  • MS mobile station
  • UL uplink
  • UL refers to a wireless transmission path of a signal transmitted from a terminal to a base station.
  • LTE or LTE-A system may be described below as an example, embodiments of the present disclosure can also be applied to other communication systems with similar technical background or channel types.
  • 5G new radio, NR
  • 5G hereinafter refers to existing LTE, LTE-A, and It may be a concept that includes other similar services.
  • this disclosure may be applied to other communication systems through some modifications without significantly departing from the scope of the present disclosure at the discretion of a person with skilled technical knowledge. At this time, it will be understood that each block of the processing flow diagram diagrams and combinations of the flow diagram diagrams can be performed by computer program instructions.
  • These computer program instructions can be mounted on a processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment, so that the instructions performed through the processor of the computer or other programmable data processing equipment are described in the flow chart block(s). It creates the means to perform functions.
  • These computer program instructions may 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 manner, so that the computer-usable or computer-readable memory It is also possible to produce manufactured items containing instruction means that perform the functions described in the flowchart block(s).
  • Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to create a process that is executed by the computer, thereby generating a process that is executed by the computer or other programmable data processing equipment. Instructions that perform processing equipment may also provide steps for executing the functions described in the flow diagram block(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s).
  • the functions mentioned in the blocks it is possible for the functions mentioned in the blocks to occur out of order. For example, it is possible for two blocks shown in succession to be performed substantially simultaneously, or it is possible for the blocks to be performed in reverse order depending on the corresponding function.
  • the term ' ⁇ unit' used in this embodiment refers to software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and ' ⁇ unit' performs certain roles. can do.
  • ' ⁇ part' is not limited to software or hardware.
  • the ' ⁇ part' may be configured to reside in an addressable storage medium and may be configured to reproduce on one or more processors. Therefore, as an example, ' ⁇ part' 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, circuitry, data, databases, data structures, tables, arrays, and variables.
  • the functions provided within the components and 'parts' may be combined into a smaller number of components and 'parts' or may be further separated into additional components and 'parts'. Additionally, components and 'parts' may be implemented to regenerate one or more CPUs within a device or a secure multimedia card. Additionally, in an embodiment, ' ⁇ part' may include one or more processors.
  • this disclosure uses terms and names defined in the 5GS and NR standards, which are standards defined by the 3rd Generation Partnership Project (3GPP) organization among currently existing communication standards.
  • 3GPP 3rd Generation Partnership Project
  • the present disclosure is not limited by the above terms and names, and may be equally applied to wireless communication networks complying with other standards.
  • the present disclosure can be applied to 3GPP 5GS/NR (5th generation mobile communication standard).
  • a universal integrated circuit card is a smart card used by inserting into a terminal, for example, a mobile communication terminal, and is also called a UICC card.
  • the UICC may include an access control module for accessing the network of a mobile communication provider. Examples of these access control modules include the Universal Subscriber Identity Module (USIM), Subscriber Identity Module (SIM), and Internet Protocol (IP) Multimedia Service Identity Module (ISIM). Includes etc.
  • USIM Universal Subscriber Identity Module
  • SIM Subscriber Identity Module
  • IP Internet Protocol Multimedia Service Identity Module
  • a UICC that includes USIM is usually called a USIM card.
  • a UICC containing a SIM module is commonly called a SIM card.
  • SIM card may be used in the general sense including a UICC card, USIM card, UICC including ISIM, etc.
  • USIM card UICC including ISIM
  • general UICC card the term SIM card may be used in the general sense including a UICC card, USIM card, UICC including ISIM, etc.
  • its technical application can be equally applied to a USIM card, ISIM card, or general UICC card.
  • the SIM card stores the personal information of the mobile communication subscriber and enables safe use of mobile communication by performing subscriber authentication and generating a traffic security key when connecting to the mobile communication network.
  • SIM cards are generally manufactured as a dedicated card for a specific mobile communication service provider at the request of a specific mobile communication service provider when manufacturing the SIM card, and include authentication information for network access of the service provider, for example, USIM (Universal Subscriber Identity Module) application, IMSI (International Mobile Subscriber Identity), K value, OPc value, etc. are preloaded on the card before shipping. Accordingly, the manufactured SIM card is delivered by the relevant mobile communication service provider and provided to the subscriber, and when necessary, management such as installation, modification, and deletion of applications within the UICC is performed using technologies such as OTA (Over The Air). can do.
  • USIM Universal Subscriber Identity Module
  • IMSI International Mobile Subscriber Identity
  • K value International Mobile Subscriber Identity
  • OPc value OPc value
  • Subscribers can use the network and application services of the mobile communication service provider by inserting the UICC card into the mobile communication terminal they own. Also, when replacing a mobile communication terminal, the subscriber can insert the UICC card from the existing mobile communication terminal to a new mobile communication terminal and use the authentication information, mobile communication phone number, personal phone book, etc. stored in the UICC card as is in the new mobile communication terminal. do.
  • SIM cards have inconveniences for mobile communication terminal users to receive services from other mobile communication companies.
  • Mobile communication terminal users have the inconvenience of having to physically obtain a SIM card to receive services from mobile communication providers.
  • Roaming services solve some of the inconvenience, but there are also problems with high fees and the inability to receive service if there is no contract between telecommunication companies.
  • the user can download the SIM module of the mobile communication service he or she wants to use to the UICC card at any time.
  • This UICC card can also download and install a plurality of SIM modules and select and use only at least one SIM module among them.
  • These UICC cards may or may not be fixed to the terminal.
  • a UICC that is fixed and used in a terminal is usually referred to as an eUICC, but in this disclosure, a UICC card that can remotely download and select a SIM module can be collectively referred to as an eUICC.
  • the UICC cards that can be selected by downloading the SIM module remotely can be collectively used as eUICC.
  • the downloaded SIM module information is collectively referred to as profile. Examples of profiles include the provisioning profile, which is a profile whose use is limited only to connectivity for initial setup, the operational profile, which is a profile with no such use restrictions, and the test profile, which is limited to testing purposes, etc. It can be further divided according to use.
  • Remote Profile Provisioning standards which are eSIM standardization standards defined by GSMA, include SGP.21/22, a Remote SIM Provisioning standard for consumer devices, SGP.31/32, a Remote SIM Provisioning standard for IoT devices, and SGP.31/32, a Remote SIM Provisioning standard for IoT devices.
  • the terminal is connected to the profile download server over a network in real time, and multiple messages are exchanged between the terminal and the profile server, and mutual authentication (Common Mutual Authentication) is performed during this process. It is defined as the process of downloading the profile after going through it.
  • the terminal cannot assume that the network is always connected to the profile download server at the time of downloading the profile. Therefore, to solve this problem, the provisioning profile, a profile with limited use, was introduced in SGP.21/22 to provide connectivity only for initial setup to the terminal. Accordingly, terminal manufacturers may ship eUICCs equipped with a provisioning profile.
  • a manufacturer may ship the eUICC preloaded with the operational profile of the communication service provider that does not have the above usage restrictions.
  • the eUICC manufacturer's factory usually supplies the eUICC with the profile pre-loaded to the terminal manufacturer.
  • the terminal manufacturer separates the hardware and stocks it. There is a problem that it requires management (SKU: Stock Keeping Unit), so it cannot be activated.
  • the function for provisioning a profile at the factory is referred to as the IFPP (In Factory Profile Provisioning) function, and when entering a state supporting the function, it may be entered into IFPP mode or indicated as IFPP state.
  • IFPP Factory Profile Provisioning
  • "f" can be added to the end of each Entity's name to indicate that it is operating in that mode.
  • a specific entity such as a terminal, LPA, eUICC, profile server, factory IT, SP (Service Provider) server, and EUM (eUICC Manufacturer) server may be an entity that further supports IFPP mode, or may support only that function. It can be an Entity.
  • SM-DP+ one of the profile servers, supports the consumer-oriented Remote SIM Provisioning function defined in SGP.21/22, but it may be a server that additionally supports some of the IFPP functions defined in SGP.41/42. there is.
  • SM-DP+ a profile server, may be a profile server that supports only the IFPP function.
  • a profile server operating in the IFPP state may be interchangeably referred to in the present invention as, for example, profile server f.
  • the UICC Universal Integrated Circuit Card
  • the UICC is a smart card used by inserting into a mobile communication terminal. It stores personal information such as network access authentication information, phone book, and SMS of mobile communication subscribers, and is used for GSM, WCDMA, LTE, 5G, etc. It may refer to a chip that enables safe use of mobile communication by performing subscriber authentication and generating a traffic security key when accessing the same mobile communication system.
  • the UICC is equipped with communication applications such as SIM (Subscriber Identification Module), USIM (Universal SIM), and ISIM (IP Multimedia SIM) depending on the type of mobile communication network the subscriber connects to, and also includes electronic wallets, ticketing, electronic passports, etc. It can provide high-level security functions for mounting various applications.
  • SIM Subscriber Identification Module
  • USIM Universal SIM
  • ISIM IP Multimedia SIM
  • eUICC embedded UICC
  • eUICC embedded UICC
  • eUICC is not limited to a security module built into the terminal, and includes a removable security module that can be inserted and removed from the terminal.
  • eUICC is a programmable SIM card that can generally be downloaded and installed from a server that stores a profile using OTA (Over The Air) technology.
  • eUICC can be named UICC that allows profile download and installation.
  • the method of downloading and installing a profile on an eUICC using OTA technology can also be applied to a removable UICC that can be inserted and removed from a terminal, as described above.
  • an embodiment of the present disclosure can be applied to a removable UICC that can be installed by downloading a profile using OTA technology.
  • the eUICC unique identification number (eUICC ID) may be referred to as EID.
  • UICC referred to in this disclosure may be used interchangeably with SIM, and the term eUICC may be used interchangeably with eSIM.
  • a profile may mean packaging an application, file system, authentication key value, etc. stored in the UICC in software form. Additionally, the profile can be named as access information. Additionally, in the present disclosure, USIM profile may have the same meaning as profile or may mean packaging the information included in the USIM application within the profile in software form.
  • a profile package (Profile Package) or an encrypted profile package (Bound Profile Package (BPP)) may be used interchangeably with a profile or as a term representing a data object of a specific profile, and may be used as a term to represent a data object of a specific profile, and a profile TLV or profile package TLV ( Profile Package TLV).
  • the profile identifier may be referred to as an Integrated Circuit Card Identifier (ICCID), which represents a unique identification number of the profile.
  • ICCID Integrated Circuit Card Identifier
  • PPP Protected Profile Package
  • PPP TLV Protected Profile Package TLV
  • BPP Bound Profile Package
  • BPP TLV Bound Profile Package TLV
  • the profile package TLV may be a data set that expresses information constituting the profile in TLV (Tag, Length, Value) format.
  • the profile server generates a profile, encrypts the created profile, generates a profile remote management command, provides a function to encrypt the created profile remote management command, provides an IFPP mode, or provides a plurality of terminals.
  • terminal' or 'device' used in this disclosure refers to mobile station (MS), user equipment (UE), mobile equipment (ME), user terminal (UT), wireless terminal, and access.
  • Various embodiments of the terminal include a cellular phone, a smart phone with a wireless communication function, a personal digital assistant (PDA) with a wireless communication function, a wireless modem, a portable computer with a wireless communication function, and a digital camera with a wireless communication function.
  • PDA personal digital assistant
  • the terminal may include devices, gaming devices with wireless communication functions, music storage and playback home appliances with wireless communication functions, Internet home appliances capable of wireless Internet access and browsing, as well as portable units or terminals that integrate combinations of such functions.
  • the terminal may include an M2M (Machine to Machine) terminal, an MTC (Machine Type Communication) terminal/device, and an IoT terminal/device depending on the performance characteristics it supports.
  • M2M Machine to Machine
  • MTC Machine Type Communication
  • IoT terminal/device depending on the performance characteristics it supports.
  • a terminal may be referred to as an electronic device or simply a device.
  • the terminal 120 that provides the function of installing a profile with an eUICC may be referred to as an eSIM terminal.
  • EUM is an eUICC Manufacturer, which refers to a manufacturer that produces eUICC and personalizes and provides eUICC, and the information delivered by EUM is transmitted on and offline through the EUM server or channels between separate components. You can. Additionally, EUM may refer to an EUM server or a role performed by EUM.
  • the terminal or device may include software or applications installed within the terminal or device to control the UICC or eUICC.
  • the software or application may be, for example, an application such as Local Profile Assistant (LPA), SIM Manager, or IoT Profile Assistant (IPA).
  • LPA Local Profile Assistant
  • IPA IoT Profile Assistant
  • the software or functions may be provided in an integrated manner.
  • LPA and IPA may be provided as one integrated app.
  • software or applications installed in a terminal or device to control a UICC or eUICC may be collectively referred to as LPA.
  • an Application Protocol Data Unit may be a message format or message exchanged between a terminal or a controller within a device and the eUICC.
  • APDU is a pair of Command and Response, and APDU Command and APDU Response are defined in ETSI 102.221 with reference to ISO 7816.
  • the APDU Command consists of CLA (Class of Instruction), INS (Instruction), P1 (Instruction Parameter 1), P2 (Instruction Parameter 2) as the APDU header, and Lc (Number of bytes in the command) as the body.
  • the application message transmitted from the LPA or terminal may be transmitted to the eUICC in the form of an APDU, and the information transmitted at this time may be transmitted as included in the data of the APDU.
  • AKA may represent Authentication and Key Agreement and may represent an authentication algorithm for accessing 3GPP and 3GPP2 networks.
  • K is an encryption key value stored in the eUICC used in the AKA authentication algorithm, and in this disclosure, OPc is a parameter value that can be stored in the eUICC used in the AKA authentication algorithm.
  • NAA is a network access application (Network Access Application) application, and may be an application such as USIM or ISIM that is stored in the UICC and is used to access the network.
  • NAA may be a network access module.
  • end user, user, subscriber, service subscriber, and user may be used interchangeably to refer to the user of the corresponding terminal.
  • Factory IT is a device responsible for provisioning specific data or settings to the terminal in the manufacturing process and may refer to a module that includes a function to download a profile to the terminal and obtains profiles from the profile server. It may also include additional functions for saving.
  • Factory IT can be used interchangeably with factory IT equipment, factory IT server, factory provisioning equipment, and factory server, and although expressed as a server hereinafter, Factory IT in the present invention includes one or more modules, for example, a server that stores data and settings or It can function as a terminal that injects data into the eSIM terminal.
  • OEM may be used interchangeably with terminal manufacturer and manufacturer.
  • Service Provider may be used interchangeably with a communication service provider, MNO, mobile network operator, operator, telecommunication company, and SP server.
  • the Service Provider may be the Service Provider's server or the role performed by the Service Provider. It can mean.
  • the server vendor refers to a vendor that operates a profile server and may refer to a role performed by the profile server vendor.
  • an encryption key is used to encompass all encryption and decryption keys.
  • an encryption key may include a secret key used to encrypt data (the terms secret key or private key are used interchangeably) or a public key to decrypt it, and the public key may be shared in the form of a certificate. .
  • a one-time encryption key, a one-time public key, or a private key may refer to an encryption key required for key agreement, where one-time is interpreted to mean a key used for one profile installation. It can be. As described later in this disclosure, the key can be discarded when the profile installation is successful, stored in the eUICC before the final successful installation, and can be interpreted with reference to the GSMA SGP.22 definition.
  • the present disclosure seeks to provide a method and device that allows an eSIM terminal to be released while maintaining the same hardware SKU by inserting a profile without separating the hardware SKU from a terminal including an eUICC.
  • the present disclosure requires rapid profile injection into a large number of terminals, so it is necessary to perform a process of exchanging messages in multiple round trips, including real-time network connection and mutual authentication procedures between the profile server and individual terminals. Since this is difficult, the goal is to overcome this problem and provide a method and device that can quickly download and install profiles on a large number of terminals. To this end, it may be necessary for the profile server and the eSIM terminal to distinguish between profile downloads in a normal situation and profile downloads in an environment where a large number of profiles are injected into a terminal at a factory.
  • a method may be needed to provision profile(s) from Factory IT equipment to the terminal without considering the real-time connection between the profile server and the terminal, especially the "non-real-time" between the profile server (e.g. SM-DP+) and eUICC.
  • a method of delivering, verifying, and installing the profile encryption key may be needed that takes this into account.
  • a method that takes into account the environment of provisioning profiles in large quantities at the factory is needed, and in particular, a method and device that provides for transmitting information of a large amount of profile(s) between entities in the process of ordering and preparing profiles is needed. You can.
  • a terminal manufacturer can pre-install and ship a large number of profiles on an eSIM terminal without a real-time connection to a profile server, and efficiently manage inventory by installing profiles without separating H/W SKUs. can do.
  • the user can directly access the network by purchasing a terminal with the profile already installed, thereby eliminating the inconvenience of the user having to visit a Wi-Fi or mobile communication network to download the profile. Convenience can be increased.
  • a communication service provider can provide a terminal to a user with a Provisioning Profile for downloading the company's profile or an operational profile for immediately using the company's network service installed, making it convenient for the user to use eSIM. Sex can be reconsidered.
  • FIG. 1 is a diagram showing the relationship between components for provisioning a profile according to embodiments of the present disclosure.
  • a profile server/server vendor (hereinafter may be referred to as a profile server or server vendor) 100 creates a profile, stores the created profile, encrypts the created profile, or sends a remote profile.
  • Generates management commands includes a function to encrypt the created profile remote management command, supports the function of transmitting the created profile to an eSIM terminal or another profile storage server, or a profile for IFPP It may represent at least one of a server supporting a function of creating a profile, storing a profile created for IFPP, or encrypting a profile created for IFPP.
  • Remote Profile Management may collectively refer to a series of procedures in which profile installation, activation, deactivation, deletion, and other functions are performed by commands transmitted from the profile server 100 to the terminal 120.
  • RPM may be requested by a communication service provider, service provider, or terminal owner, and a command may be generated by the profile server 100.
  • the profile server/server vendor 100 receives a profile order request from the SP (Service Provider)/SP server (hereinafter referred to as SP or SP server) 150 and determines whether the request is for profile creation for IFPP.
  • profile order information received from the Factory IT Server/OEM (hereinafter referred to as Factory IT, Factory Server, or OEM) 110 or the SP/SP Server 150 and the ordered EID information.
  • the SP/SP server 150 receives the profile order request received from the Factory IT server/OEM 110, determines whether it is an order request for profiles for IFPP, and sends the profile server/SP server 150 to the SP/SP server 150.
  • the profile server 100 can provide one or more BPP (Bound Profile Package) to Factory IT 110.
  • the terminal 120 may include an eUICC 140 and a communication modem (not shown).
  • the communication modem may be equipped with one or more baseband processors (hereinafter referred to as baseband) for wireless communication.
  • the terminal 120 can receive the BPP(s) created for IFPP from Factory IT 110 and provide the function of installing the BPP(s) to the eUICC 140.
  • the terminal 120 may transmit the BPP to the eUICC 140 through the LPA 130 operating as LPAf, or may transmit the BPP to the eUICC 140 without going through the LPA 130.
  • An example of a method for transmitting a message about the installation and encryption key information of the BPP delivered to the eUICC (140) using the LPA (130) operating as LPAf is included in one or more messages starting with ES10x and transmitted. This may be the way to go.
  • LPA 130
  • embodiments of this will be described later with reference to FIGS. 4 to 6.
  • Factory IT 110 may receive and store BPPs from a plurality of profile servers 100.
  • the LPA 130 may support the IFPP function with eUICC control software or application.
  • the LPA 130 may be implemented as a logical function of the terminal 120 or the eUICC 140.
  • LPA (130) operating as LPAf can receive additional authentication information for authenticating the profile and profile server (100) from Factory IT (110) and provide it to eUICC (140), and install the profile from eUICC (140). It may also play the role of obtaining results and delivering them to Factory IT (110).
  • the eUICC (140) configures the profile at the factory through one or more ES10x messages received from the LPA (130) operating as LPAf or a profile installation message received through Factory IT (110) or an application or software for factory settings of the terminal. You can determine that it is a request for installation and decide to enter IFPP mode. If the eUICC 140 does not support the IFPP function, the eUICC 140 may return an error and end IFPP processing.
  • the eUICC (140) acquires the profile and profile server (100) authentication information from the terminal (120), decrypts the profile with the corresponding information, processes the installation, and transfers the installed result to the component that transmitted the request, that is, the terminal.
  • a reply may be sent to a specific application or to the LPA 130 operating as the terminal's LPAf.
  • the eUICC 140 may verify the profile server 100 that encrypted the profile or perform authentication of the profile server 100 that transmitted the message through signature verification of the component that signed the received message.
  • the eUICC 140 contains certificates required by the security domains of the eUICC 140, for example, a certificate issuer's root public key for verifying the SM-DP+ certificate of the profile server 100. Key), ECASD (Embedded UICC Controlling Authority Security Domain), which is a space for storing the eUICC manufacturer's keyset, etc., and an eSIM operating platform. Additionally, some of the functions of LPA may be implemented.
  • Factory IT server 110 is a factory IT server and may be a server responsible for provisioning profiles to terminals at the factory.
  • Factory IT server 110 obtains certain information about the corresponding eUICCs 140, including a one-time encryption key, from the EUM/EUM server (hereinafter, may be referred to as EUM or EUM server) 160, or a profile server.
  • EUM or EUM server may be referred to as EUM or EUM server
  • Factory IT server/OEM (110) requests BPP(S) for injection at the factory from the profile server/server vendor (100) and installs it on the eUICC (140) from the profile server/server vendor (100) as a result of the request.
  • Obtain signed data from the BPP and profile server 100 store the received BPPs and signed data in the Factory IT server 110, or map to the EID of the target terminal to install the profile among the received or stored BPPs. You can perform at least one of selecting a BPP and forwarding the BPP to a terminal mapped during the factory setup process.
  • Some of the information exchanged between the Factory IT server 110 and the profile server 100, SP server 150, and EUM 160 is through online and offline channels other than sending and receiving messages through the inter-server interface (e.g., email transmission, etc.). In other forms, it may be shared between entities performing the relevant role (i.e., terminal manufacturer, profile server operation vendor, service provider, eUICC manufacturer).
  • EUM (eUICC Manufacturer) 160 is an eUICC manufacturer that injects key information for credentials for eUICC authentication into the eUICC 140 and provides personalized eUICCs 140 to the terminal manufacturer, or EUM (eUICC)
  • the Manufacturer/EUM server 160 may provide certain information about the corresponding eUICCs 140, including a one-time encryption key, to the OEM/Factory IT server 110.
  • certain information about the corresponding eUICCs 140, including the one-time encryption key is stored in the profile server by the eUICC Manufacturer (EUM)/EUM server 160 at the request of the OEM 110. / May be transmitted to the server vendor (100).
  • SP (Service Provider) 150 is a business operator that provides network services using profiles as described above, and the SP/SP server 150 provides profile(s) for the IFPP function to the profile server/server vendor 100. You can create and prepare profiles ordered from the profile server 100 by placing an order.
  • order information is information exchanged between the profile server/server vendor (100), Factory IT server/OEM (110), EUM/EUM server (160), and SP/SP server (150). It can be delivered in other forms, such as through interface linking between Entity servers or by email.
  • Figure 2 is a diagram for explaining the operation of provisioning a large number of profiles according to an embodiment of the present disclosure.
  • a terminal manufacturer may preload the eUICC with profiles at the factory before shipping the device.
  • profiles may be provisioned to one or more terminals, especially a large number of terminals.
  • This step can be divided into a step of preparing profiles and delivering them to Factory IT/OEM (215) (step 227), and a step of installing them in N different eUICCs (225) in Factory IT (step 270).
  • Detailed information exchanged in each step of FIG. 2 and embodiments thereof will be described in detail in FIGS. 3 to 6 described later.
  • profiles for IFPP can be prepared and delivered to Factory IT/OEM.
  • a terminal manufacturer wishing to manufacture a terminal equipped with an eUICC can order M eUICCs through the EUM/EUM server 200, and the EUM 200 provides predetermined information including encryption key information for the M ordered eUICCs. These can be provided to Factory IT/OEM (215) (step 230). Predetermined information, including the corresponding encryption key information, may be encrypted and transmitted with the private key of the EUM or the private key of each eUICC, as described later in FIG. 3.
  • the EUM/EUM server 200 When the EUM/EUM server 200 receives an order for IFPP profiles, it can provide the Factory IT/OEM 215 including eUICC encryption key information required for BPP decryption for each eUICC. Factory IT/OEM 215, which has received this, may store encryption key information for the M ordered eUICCs in the Factory IT server 215 (step 235).
  • the Factory IT/OEM 215 may decide to load the profile on some N or all eUICCs of the M eUICCs ordered from the EUM 200. This may be in response to a request for preloading the profile from the SP (Service Provider)/SP server 205.
  • SP Service Provider
  • the Factory IT/OEM (215) provides the SP/SP server (205) with at least the number of Profile(s) and the list of EID(s) so that it can prepare a profile linked to the EID in advance.
  • One piece of information can be delivered to the SP/SP server 205 (step 240).
  • the SP/SP server 205 may order a profile from the profile server/server vendor 210 (step 245). If the SP/SP server 205 has an EID list by performing step 240 or obtained an EID list at a previous specific point, the SP/SP server 205 includes the EID information when ordering a profile and sends it to the profile server. /You can request it from the server vendor (210).
  • Factory IT/OEM 215 provides the EID list to the SP/SP server 205 in step 240 at a specific point in time before the profile server/server vendor 210 generates the BPP in step 260. This may occur, and the SP/SP server 205 that receives this may provide the EID list to the profile server/server vendor 210 before step 260.
  • Factory IT/OEM 215 may directly transmit the EID to the profile server/server vendor 210 before step 260 without going through the SP/SP server 205 (i.e., without going through step 240).
  • the SP/SP server 205, profile server/server vendor 210, and Factory IT/OEM 215 may share information that can specify the order (step 250).
  • Information that can specify the order may be shared as identification information provided by the SP/SP server 205 or the profile server/server vendor 210 to the Factory IT/OEM 215.
  • the identification information may be at least one of information such as a Batch ID, an order ID, an ordered profile list or EID list, information about the start and end numbers of the profile list or EID lists, a factory serial number, or information about a producer identification number. You can.
  • Factory IT/OEM profiles the key information corresponding to the eUICCs of the target terminals as N, which is the number of terminals on which the SP (Service Provider) (205) will load the profile, among the key information of the eUICCs acquired in step 230. It can be delivered to the server/server vendor 210 (step 255). Key information corresponding to the eUICC of target terminals may be part or all of the key information received in step 230 described above.
  • the profile server/server vendor 210 collects the profile order information received in step 245, the link information of the profile-EID received in step 240, the mutually shared order information in step 250, and the target eUICCs for installing the profile received in step 255.
  • step 260 After generating an encrypted profile package in the profile server 210 by combining the information collected in at least one step of collecting encryption key information (step 260), information about the generated profile packages and eUICC binding is stored. Can be provided (step 265) to Factory IT/OEM (215).
  • the profile server 210 can transmit the created encrypted profile packages and each BPP encryption key information to Factory IT/manufacturer 215 in one or more messages, and some or all of the data transmitted in the message is signed data. may be provided.
  • Step 270 the operation of Factory IT 215 to install profiles for IFPP in the eUICC can be explained. This step can be performed for N eUICCs.
  • Factory IT/OEM 215 can inject a profile into the terminal before shipping it from the factory.
  • a series of encryption key information required for profile decryption in BPP and eUICC can be obtained and stored in Factory IT/OEM (215).
  • the corresponding set of encryption key information may include the eUICC's one-time public key (hereinafter referred to as otPK.eUICC.KA).
  • a series of encryption key information required for profile decryption in BPP and eUICC can be transmitted to Factory IT 215 from the factory to individual terminals 220 through a wired or wireless network inside the factory.
  • BPP and a series of encryption key information may be included in one or more messages and transmitted to the terminal 220.
  • otPK.eUICC.KA may be included and transmitted, otPK.eUICC.KA may be included in signed data from the profile server and received by the terminal 220. As an example, it may be received included in data signed as one of the following: Of course, it is not limited to the examples below.
  • -SK.DPauth.SIG The profile server's secret key that the profile server uses to authenticate the profile server.
  • SK.DPpb.SIG may be the secret key of the profile server used by the profile server for profile binding or the secret key of the profile server used by the profile server for IFPP purposes.
  • xx indicating the purpose may be indicated with specific information indicating that xx is the IFPP purpose.
  • the terminal 220 can receive BPP(s) from Factory IT 215 and provide the function of injecting BPP(s) into the eUICC 225 in IFPP mode.
  • the terminal 220 may operate in Factory Provisioning mode at the time of receiving the BPP, or the terminal 220 may recognize that it must enter IFPP at the time of receiving the BPP and initiate operation.
  • the terminal 220 may enter the corresponding mode through an event input to a factory employee's terminal, a setting value, or recognition of a specific VPN (Virtual Private Network). Meanwhile, entering IFPP mode through UI or setting values may be provided as a UI that is restricted so that it is not displayed to the user in a general environment.
  • the terminal 220 may transmit the BPP to the eUICC 225.
  • the BPP may be transmitted to the eUICC 225 through LPAf (not shown) or may be transmitted to the eUICC 225 without passing through LPAf (not shown). There are (275 levels).
  • a message delivered to the eUICC using LPAf may be transmitted and included in one or more messages of ES10x.
  • LPAf LPAf
  • the message received by the eUICC 225 from the terminal 220 may include information that allows the eUICC 225 to recognize that it is an operation for IFPP.
  • the eUICC 225 may determine and enter the profile installation operation for IFPP based on the message received from the terminal 220.
  • Information that can recognize an operation for IFPP is a new function defined for IFPP or existing SGP.21/22 to SGP.
  • the IFPP identifier parameter may be added to the ES10x message defined in 31/32, or it may be factory-shipped identification information that is not included for profile provisioning in a general environment (for Consumer, or M2M, or IoT) after the terminal is shipped. For example, it may be one of the values such as factory serial number, batch ID, or producer identification information. Of course, it is not limited to this.
  • the terminal 220 can receive data containing otpk.eUICC.KA from the profile server, and the data containing otpk.eUICC.KA can be received as included in data signed as one of the following: there is.
  • the data containing otpk.eUICC.KA can be received as included in data signed as one of the following: there is.
  • it is not limited to the examples below.
  • the terminal 220 may transmit the signed data to the eUICC 225 again through LPAf or without passing through LPAf.
  • the eUICC 225 verifies the signature of the profile server 210 for the data received by the eUICC 225 and generates a session key using the one-time secret key (otSK.EUICC.KA) of the eUICC stored in advance.
  • the installation can be processed by decrypting the BPP. (280 steps)
  • the eUICC (225) can transmit the profile installation result to the terminal without going through LPAf or LPAf and reply to the Factory IT server (215) from the terminal. (285 steps)
  • Factory IT (215) can reply the profile installation results back to the profile server/server vendor (210).
  • Factory IT/OEM 215 may individually reply profile installation results to the profile server/server vendor 210, or collect the profile installation results and provide them to the profile server/server vendor 210 in batches at a specific point in time. You may. Additionally, the profile server/server vendor 210 or Factory IT/OEM 215 may selectively provide profile installation result(s) to the SP/SP server 205.
  • FIG. 3 is a diagram illustrating an operation of preparing a profile to provision a large number of profiles according to an embodiment of the present disclosure.
  • FIG. 3 is a diagram specifically illustrating the procedure for step 227 of FIG. 2.
  • Figure 3 is an example of preparing a BPP in Factory IT/OEM before performing the procedures of Figures 4 to 6, and is limited to the procedures of Figure 3 before performing the procedures of Figures 4 to 6. It is not necessary to obtain BPP.
  • Factory IT/OEM 315 that wishes to mount an eUICC can order eUICCs from the EUM/EUM server 300, and the EUM 300 is otSK/PK used in the eUICC.
  • the secret of otPK.EUICC.KA, [eUICC Info], [EID], eUICC or EUM is stored for each eUICC.
  • Data containing otPK.EUICC.KA signed with the key (indicated as Signed (otOK.EUICC.KA, [eUICC Info]) in step 330 of FIG.
  • eUICC Signature eUICC's certificate
  • It can be transmitted including at least one of the certificate chain, EID, or PK.EUICC.SIG.
  • Information transmitted from the EMU 300 to the Factory IT/OEM 315 may be transmitted as EUM signed data or as unsigned data. If the data is transmitted as EUM signed data, it may be possible to transmit the EUM's signature value (eumSignature) and the EUM certificate or EUM's public key (PK.EUM.SIG). In addition, among the transmitted information, it may be possible for information commonly applied to the order of the eUICCs (e.g., eUICC Info) to be transmitted without duplication for each eUICC.
  • EUM's signature value eumSignature
  • EUM's public key PK.EUM.SIG
  • otPK.EUICC.KA may be signed and transmitted with the EUM's private key. If otPK.EUICC.KA is signed and transmitted with the EUM's private key, it may be transmitted without including the eUICC's signature value and/or the eUICC-specific certificate.
  • Transmitted information can be delivered through an interface linked to Factory IT (315) in the profile server or through other online/offline methods.
  • Each transmitted information may represent the following: Of course, it is not limited to the examples below.
  • eUICC s one-time public key, used to create a session key between the profile server and eUICC.
  • Data including otPK.EUICC.KA Data including otPK.EUICC.KA signed with the secret key of eUICC, displayed as euiccSignature in the example of the data format below.
  • - CERT.EUICC.SIG and certificate chain refers to the eUICC certificate and the chain of certificates for eUICC certificate verification.
  • - CERT.EUICC.SIG contains the EID, which is the unique identification number of the eUICC, and the public key (PK.EUICC.SIG) to decrypt the eUICC signature. It is also used to prove that the eUICC has been authenticated by the EUM.
  • the parent certificate chain of CERT.EUICC.SIG may include CERT.EUM.SIG, a certificate containing the EUM public key.
  • eUICC Info Information about eUICC Capability, which may or may not include an indication of the capability indicating whether it is an eUICC that supports IFPP. If a specific order has the same eUICC Capability, eUICC Info may be transmitted for each order rather than for each eUICC.
  • - PK.EUICC.SIG The public key of the eUICC to decrypt the eUICC signature. It can be transmitted as a value included in CERT.EUICC.SIG or as a separate parameter when transmitted without being included in CERT.EUICC.SIG. .
  • An example of the transmitted data format may be the format in Table 1 as follows.
  • Factory IT/OEM (315) which has received the information, stores and retains the information, and at a certain point in time, Factory IT/OEM (315) stores N eUICCs, which are part of the M eUICCs ordered from EUM (300), or all eUICCs.
  • the SP may decide to load the profile, or the SP may request Factory IT/OEM 315 to load the profiles in advance on the terminals 320 that will be shipped.
  • Factory IT/OEM 315 is an optional procedure and includes at least one of the number of profiles and information on EID(s) so that it can prepare a profile linked to the EID in advance to the SP/SP server 305. It can be delivered to the SP/SP server (305). (333 steps)
  • SP/SP server 305 may order a profile from profile server/server vendor 310. (335 steps)
  • the profile order message may be defined as a new function or in a form that further includes IFPP order identification information in the ES2+ order interface between Service Provider and profile server defined in the existing GSMA RSP.
  • Information included in the order message may include at least one of the following. Of course, the information is not limited to the following. Batch ID is an ID to identify a group's profile order, so it can be replaced with other terms such as Profile Order ID or Bundle Order ID.
  • IFPP indication as an IFPP order identifier, or Batch ID may be transmitted as one of the values of Profile Type data of the ES2+ order interface.
  • the profile server 310 may be a profile server that supports only IFPP, or may be a profile server that supports IFPP as one of the functions of the profile server.
  • the profile server 310 supports SGP.21/22 (standard for profile provisioning to consumer terminals such as smartphones) or SGP.31/32 (standard for profile provisioning to IoT specialized terminals) defined by GSMA.
  • the profile server may be a server that additionally supports functions for profile provisioning in the factory.
  • the profile server 310 which has received the profile download order, determines whether there is IFPP judgment information using a new function defined as IFPPOrder or a new parameter of the existing ES2+.DownloadOrder, and can recognize and manage the order as a profile preparation for IFPP. there is.
  • the profile server 310 can process the profile by changing the status to the allocation stage (allocated), and if the EID is received together in step 335, the EID You can also prepare by connecting with ICCID and changing the status of the profile to Linked.
  • the SP/SP server 305 or profile server/server vendor 310 may share information that can specify the order with Factory IT/OEM 315. (340 steps)
  • the SP/SP server 305 or the profile server/server vendor 310 may be information that allows the Factory IT/manufacturer 315 to recognize whether the order is for the same order. That is, the profile server 310 may receive a profile download request later. (Step 345) When the profile server 310 receives a profile download request, it must be able to map it to the profiles previously requested and prepared from the SP. To this end, order information between the SP-Factory IT-profile server must be shared. You can share it. As an example, order information that can be shared includes Batch ID, address of the server that stores the profile, identification information of the service provider who requested profile creation, information such as the start and end numbers of the ordered profile list or EID list, or the ordered profile list. , EID list, or Factory IT identification number.
  • Factory IT/OEM 315 may wish to inject a profile into the terminal before shipping it from the factory. To this end, Factory IT/OEM 315 may request a BPP prepared for IFPP from the profile server 310.
  • the way to indicate that this is an IFPP request from Factory IT (315) to the profile server (310) is to send a message to a new function indicating that it is a BPP request for IFPP, ES9+.
  • Profile server 310 in at least one of the following cases: transmitting an IFPP identification indication to the function, or transmitting a parameter required only for the IFPP (for example, at least one of otPK.eUICC.KA, Batch ID, or SP ID) can be judged.
  • a parameter required only for the IFPP for example, at least one of otPK.eUICC.KA, Batch ID, or SP ID
  • the aforementioned ES9+ An example of a function is ES9+. It may be a message such as GetBoundProfilePackage.
  • the Factory IT/OEM selects the SP (Service Provider) (305) from the key information of the eUICCs obtained in step 330.
  • Key information including otPK.EUICC.KA corresponding to the eUICC of the target terminals may be transmitted to the profile server/server vendor 310 as many as the number of terminals on which the profile will be loaded.
  • eUICC info may be optionally included and transmitted as device info or eUICC capability information.
  • the profile server/server vendor 310 When the profile server/server vendor 310 receives a message that can determine that it is a BPP request for IFPP from Factory IT 315 and receives key information for otPK.eUICC.KA, the profile server/server vendor ( 310) determines that the BPP for IFPP is ready, and the profile server 310 may perform the step of creating a BPP for IFPP. (Step 350) The profile server 310 may enter the process of creating a BPP, an encrypted profile package, in IFPP mode.
  • the profile server 310 determines whether to create a BPP for IFPP, information that can recognize this is included in the message received from Factory IT 315 (for example, a new function defined for IFPP, an existing ES9+ message, This may be the case when receiving a new IFPP indication that can be recognized as a profile download request, or information including at least one of new parameters (encryption key information, etc.). If the profile server/server vendor 310 determines that a BPP for the IFPP must be created, the profile server 310 may generate the BPP for the IFPP by including one or more of the following procedures. Of course, it is not limited to the examples below.
  • the profile server 310 may optionally check whether the profile type received from the SP through the ES2+ order interface is suitable for installation on the target terminal/EID.
  • the profile order received in step 335 is optionally checked, particularly whether the profile type specified in the order can be installed. can do. Accordingly, the profile server 310 may or may not verify qualifications, including whether the EID/terminal is capable of installing a profile for IFPP.
  • CERT.EUICC.SIG may verify the CERT.EUICC.SIG received in step 345 with the EUM's certificate.
  • CERT.EUICC.SIG may contain an EID, which may consist of a sequence of numbers containing one of the EINs in the EUM certificate.
  • the profile server checks whether the EID included in CERT.EUICC.SIG matches one of the values of the allowed EINs (EUM identification IDs) included in CERT.EUM.SIG, the EUM certificate, and determines whether CERT.EUICC.SIG is a legitimate eUICC. Recognition can be verified.
  • the profile server 310 can decrypt the private key of eUICC used to sign data including otPK.EUICC.KA using the public key of eUICC included in CERT.EUICC.SIG. According to an embodiment of the present disclosure, if the data including otPK.EUICC.KA received in step 345 has been signed and received with the private key of the EUM, the profile server has the public key of the EUM included in CERT.EUM.SIG Decryption can be performed.
  • the profile server 310 can use otSK.DP.KA and otPK.EUICC.KA to create a shared secret value to be used in a specific profile transmission session.
  • the profile server 310 can create it.
  • the eUICC (325) is designed to send the Server Challenge value that the profile server (310) sends to the eUICC (325) as is during the mutual authentication procedure between the profile server (310) and the eUICC (325).
  • the profile server/server vendor 310 sends one or more messages to Factory IT/OEM 315 containing the BPP and a series of information required for BPP installation. It can be transmitted through (Step 355) If Factory IT (315) has registered the Push service in the profile server (310) at the time of requesting the BPP, the corresponding BPP and a series of information required for BPP installation are sent to the profile server (310) in step 350. ) may transmit it by including it in a push message at the point when it is prepared, or the profile server 310 may notify the profile is prepared through a push message, and Factory IT 315 may proceed with the procedure of accessing the profile server 310 to obtain it. .
  • the profile server/server vendor 310 can transmit a series of encryption key information lists of the profile server required for BPP verification in the BPP created by Factory IT/OEM 315 and the mapped eUICC through one or more messages.
  • Corresponding encryption key information for example, the public key of the profile server (eg, PK.DPxx.SIG), may be delivered included in the certificate or may be delivered without being included in the certificate.
  • the information transmitted from the profile server/server vendor 310 may include order identification information, such as Service Provider ID, Batch ID, or Order ID.
  • ESbpp.BulkProfileResponse [SP ID], ([Batch ID], (BPP including otPK.DP.KA, [CERT.EUICC.SIG], [CERT. [DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EIUCC.KA])
  • ESbpp.GetBoundProfilePackageforIfpp response (batchOrderId, ([EID], BPP including otPK.DP.KA, CERT.DPpb.SIG, eUICC Signature, [otPK.EUICC .KA])X N, Device Info, eUICC Info, SM-DPf Certificate Chains).
  • otPK.EUICC.KA may be included and transmitted, and if it is included and transmitted, it may be transmitted as signed information.
  • otPK.EUICC.KA may be transmitted as one of the ES8+ included in the BPP, or may be transmitted as not included in the BPP.
  • the information delivered in step 355 may consist of one message or more than one message and may be delivered to Factory IT/OEM 315 and stored in Factory IT 315.
  • Factory IT (315) can map and store the received BPP, the EID mapped for each BPP, and the encryption key information for downloading and installing the BPP to the corresponding EID, and then perform profile provisioning.
  • Factory IT (315) transmits the BPP to the terminal (320) and encryption key information for downloading and installing the BPP in the corresponding EID
  • the terminal (320) transmits the BPP and the BPP to the eUICC (325).
  • the eUICC 325 may be performed by transmitting encryption key information for download and installation, including the procedure of verifying the delivered BPP and the encryption key for installing it and installing the profile.
  • the BPP installation procedure from the terminal 320 to the eUICC 325 may be transmitted to the eUICC 325 through LPAf (not shown) or may be transmitted to the eUICC 325 without going through LPAf.
  • LPAf not shown
  • a message delivered to the eUICC using LPAf it can be transmitted as part of one or more messages in ES10x.
  • the transmission method in the terminal may be one of the following methods. Of course, the method is not limited to the following.
  • FIG. 4 is a diagram illustrating the operation of installing the profile in FIG. 2 from Factory IT to the eUICC according to an embodiment of the present disclosure.
  • the procedures for preparing the profiles of FIGS. 4 to 6 may be performed through the preparation procedure of FIG. 3 or the preparation procedure described later in FIG. 2, but are not limited thereto. That is, even if it is not performed according to the method of FIGS. 2 and 3, if the profile server generates and prepares the BPP and encryption key, the subsequent profile installation procedure may be processed as shown in FIGS. 4 and 6.
  • Figure 4 describes a method of recycling and processing the three-step procedure of SGP.22 described above by performing all of the authentication procedure between the server and eUICC, the preliminary information sharing procedure for Profile installation, and the BPP installation procedure. do.
  • Factory IT 415 can obtain and store key information related to the BPP mapped to N bundles of eUICCs. Factory IT 415 can transmit key information related to the BPP to the terminal 420 that is mapped in the process of provisioning setting values to the terminal at a specific time before shipping the terminal from the factory. (Step 435) Factory IT (415) can check the terminal ID and/or EID during processing to provision a profile at the factory, select the encryption key information related to the BPP mapped thereto, and send it to the corresponding terminal (420). It can be transmitted or a request message from the terminal can be received and transmitted as a reply message.
  • the information transmitted to the terminal 420 in step 435 is BPP (including otPK.DP.KA) and encryption key information, such as [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], and [otPK.EUICC.KA. ], [dpSignature1], or dpSignature2.
  • BPP including otPK.DP.KA
  • encryption key information such as [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], and [otPK.EUICC.KA. ], [dpSignature1], or dpSignature2.
  • PK.DPpb.SIG is a public key required to verify the signature value used to authenticate the profile server.
  • - otPK.DP.KA Can be used to create a shared secret value that eUICC uses for profile download and transmission sessions with the profile server.
  • - ServerChallenge Included in the data for profile server authentication, it may be provided in the form of data signed with the profile server's secret key (SK.DPauth.SIG) used for profile server authentication.
  • SK.DPauth.SIG secret key
  • otPK.EUICC.KA Can be included in the data for profile server authentication, or transmitted as data for profile binding, and is data signed by the profile server including the relevant information (for example, dpSignature1 or dpSignature2 may be transmitted (included in one of). otPK.EUICC.KA may not be transmitted.
  • - dpSignature1 Can indicate data signed with the profile server's private key (SK.DPauth.SIG) corresponding to the public key included in CERT.DPauth.SIG.
  • - dpSignature2 Can indicate data signed with the profile server's private key (SK.DPpb.SIG) corresponding to the public key included in CERT.DPpb.SIG.
  • the terminal 420 enters the IFPP mode (step 440) when a function for downloading a profile for IFPP is received, or the terminal 420 settings at the time of profile provisioning enter the state of factory provisioning/setting, etc. Alternatively, it may be at least one of the following cases where the user enters a menu selection for profile provisioning in a factory environment.
  • the terminal 420 If the terminal 420 is already set to provisioning/provisioning settings of a profile at the factory, the terminal must already perform the profile download procedure in IFPP mode before receiving a new function for downloading the profile for IFPP. You may be able to recognize this and immediately enter the corresponding mode. For example, when entering LPA in factory settings, profile setting mode can be automatically entered with IFPP.
  • entering the IFPP mode is a new function, for example, ESfac.prepareFactoryDownload (including BPP (including otPK.DP.KA), [CERT.DPauth.SIG], CERT received by the terminal 420 in step 435 It can be set before receiving functions such as .DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], [dpSignature1], dpSignature2). [CERT.DPauth.SIG], If there are more certificate chains in CERT.DPpb.SIG, additional certificate chains may be included and transmitted.
  • step 435 additional certificate chain information is further included and transmitted in step 435, and then the additional certificate chain information may be included in at least one of step 445, step 460, or step 475 and transmitted to the eUICC 525.
  • the terminal 420 and the eUICC 425 which have received a message requesting to perform the download procedure of the profile for IFPP, recycle the profile installation process after terminal shipment defined in the existing SGP.22 to install the profile. It can be done.
  • eUICC and the profile server generate a random value and verify the signed value of the delivered random value to perform mutual authentication. For example, eUICC generates an eUICC Challenge value as a random value and transmits data including this to the profile server.
  • eUICC When the profile server signs the eUICC Challenge with the profile server's secret key and then replies to eUICC, eUICC receives the profile server's secret key.
  • the profile server can be authenticated by determining whether the eUICC Challenge value included in the data transmitted by the profile server is the same as the value previously generated and sent by the eUICC. Likewise, the profile server also generates a Server Challenge value and transmits it to eUICC. When eUICC signs and replies with data including that value, the value signed with eUICC's private key is verified with eUICC's public key and eUICC transmits the value. The eUICC can be authenticated by determining whether the Server Challenge value included in the data is the same as the value previously generated and sent by the profile server.
  • the eUICC Challenge value and Server Challenge value for mutual authentication between the profile server 410 and the eUICC 425 cannot be created and delivered in real time, so the values are delivered as pre-generated information. It can be.
  • the eUICC Challenge that the profile server replies to the eUICC may be a random value pre-generated by the eUICC obtained by the profile server in the profile ordering/creation step of FIGS. 2 and 3. For example, this may be the otPK.EUICC.KA value.
  • the eUICC returns the eUICC's signature data, including the Server Challenge, to the profile server and the profile server verifies the data.
  • the profile server may not be able to perform eUICC authentication.
  • the eUICC 425 authenticates the profile server 410
  • the profile server 410 may not authenticate the eUICC 425 during the process of performing a profile download.
  • the profile server does not authenticate during the process of performing profile download, and the profile server 410 sends otPK.EUICC signed and delivered by eUICC in the previous profile preparation step (e.g., step 350 of FIG. 3).
  • the eUICC 425 can be authenticated in advance by verifying the KA and then generating the BPP.
  • the profile server 410 optionally includes the Server Challenge value that the profile server 410 transmits to the eUICC 425 in the existing ES10x procedure in the data signed by the server. It can be provided to Factory IT (415). Factory IT (415), which has received data signed by the server for the Server Challenge value transmitted from the profile server 410 to the eUICC (425), transmits the corresponding information to the terminal 420, causing the terminal 420 to eUICC ( 425). The Server Challenge may be created and provided when the profile server 410 receives or prior to receiving the BPP creation request.
  • the LPAf (not shown) of the terminal 420 may enter IFPP and transmit data including the eUICC Challenge as server authentication information to the eUICC 425.
  • the data may be transmitted in the form of data signed by the server. (Step 445) As an example, it may be a message such as ES10b.AuthenticateServer (Data1(Including otPK.EUICC.KA), dpSignature1, CERT.DPauth.SIG).
  • dpSignature1 may be a value obtained by signing Data1 with the secret key of the profile server 410.
  • the eUICC 425 that received the message can verify the profile server 410 (step 450), and otPK.EUICC.KA can be used to verify the signature of the eUICC Challenge and profile server.
  • a verification procedure for authenticating the profile server 410 in the eUICC 425 may be performed including one of the following procedures. Of course, the procedure is not limited to the following.
  • - eUICC 425 verifies the signature of the profile server: the value decrypted dpSignature1 with the public key (e.g., PK.DP.SIG) included or not included in the certificate of the received profile server and Data1 (Including otPK) Verify whether it has the same value by comparing it with the value of .EUICC.KA).
  • the public key e.g., PK.DP.SIG
  • Data1 Including otPK
  • Certificate chain verification Verification by whether the CERT.DPauth.SIG certification chain and the eUICC's certification chain are in the same certification chain.
  • the eUICC 425 can verify the certificate and signature of the profile server 410 and return the results to the LPAf of the terminal 420. (Step 455) If the eUICC 425 fails to verify the certificate and signature of the profile server 410, it returns an error message to the terminal 420 (Step 455), and the terminal 420 returns the error message. may terminate the profile installation operation and return the error result to Factory IT (415). (485 steps)
  • the LPAf of the terminal 420 confirms that the authentication process of the profile server 410 is successfully performed through the message returned in step 455, the LPAf of the terminal 420 sends the preparation information required for profile download to the eUICC 425. I can send it to you. (460 steps)
  • steps 445 to 455 described above may be performed selectively. For example, you can proceed from step 440 to step 460 and process subsequent steps without performing the authentication procedure using CERT.DPauth.SIG. This may be the case when the message received in step 435 is received without CERT.DPauth.SIG.
  • CERT.DPauth.SIG can be used for profile server authentication as well as profile binding.
  • the eUICC 425 may determine step 445 as the RSP session creation time and operate. Previously, the eUICC (425), which did not perform steps 445 to 455, may operate by determining the time when the message is received in step 465 as the time of RSP session creation. In this case, if the eUICC (425) had an RSP session already created before receiving the message, the eUICC (425) deletes the previously created RSP session and deletes the previously created RSP session (since the profile installation has not been completed). ) You can save the last unused otPK.EUICC.KA and otSK.EUICC.KA without deleting them, and then start a new RSP session.
  • the message transmitted in step 460 described above may be a message containing at least one of Data2 including otPK.EUICC.KA, dpSignature2, which is a value that signs the corresponding data, or CERT.DPpb.SIG.
  • ES10b It may be defined as a new function for IFPP, such as PrepareDownload for IFPP.
  • otPK.EUICC.KA may also be transmitted as a value corresponding to bppeUICCOtpk of data 2.
  • the eUICC 425 that has received the message may perform a verification procedure to prepare for profile download (step 465).
  • the operation of the eUICC 425 may be performed including at least one or more of the following procedures.
  • the procedure is not limited to the following.
  • - Verify the signature of the profile server Compare the decrypted value of dpSignature2 with the value of Data2 (Including otPK.EUICC.KA) using the public key of the profile server extracted from CERT.DPpb.SIG to check whether it has the same value.
  • the eUICC 425 When the eUICC 425 completes the above-described procedures, including signature verification, it can transmit the result to the LPAf of the terminal 420. (Step 470) If otPK.EUICC.KA is transmitted as the value of bppeUICCOtpk in the received Data2, the eUICC 425 operating in IFPP mode transmits a new otPK/SK.EUICC if there is no received otPK.EUICC.KA. It may not create a KA pair and return an error. If information about user interaction is required for the data included in the received Data2 (for example, when the Flag for Confirmation Code input is set), the eUICC 425 generates an error when operating in IFPP mode.
  • step 470 described above after receiving a normal response message for the result, the LPAf of the terminal 420 may transmit otPK.DP.KA and BPP to the eUICC 425, and otPK.DP.KA may be sent to the BPP. It can be transmitted as embedded data. Meanwhile, as described later, even if an error such as a certificate error is returned in step 470 as a result of performing step 465, the terminal 420 terminates the profile installation operation without performing steps 475 and 480 and reports the error result. You can also reply to Factory IT (415). (485 steps)
  • the LPAf of the terminal 420 may divide the BPP into one or more APDUs and transmit them to the eUICC 425.
  • the included and transmitted BPP may be encrypted with a session key and transmitted, and otPK.DP.KA may be transmitted together with the transmitted BPP or included in a package.
  • An example of a message transmitted from LPAf to eUICC is ES10b. It may be a function such as LoadBoundProfilePackage, and the data of ES8+ functions transmitted from the profile server may be included and transmitted as the data of the message.
  • the eUICC 425 may receive a series of messages for BPP installation received through step 475, and one of these messages may include otPK.DP.KA.
  • otPK.DP.KA When otPK.DP.KA is transmitted as part of data signed by the profile server, the eUICC 425 uses the profile server's public key (or a certificate containing the public key) to verify the signed data together or in the previous step. You can receive it and use it. This could be, for example, the PK.DPpb.SIG obtained earlier (or CERT.DPpb.SIG with the certificate containing the corresponding public key).
  • the eUICC 425 can attach CERT.DPpb.SIG to the RSP session in step 465. If the eUICC (425) attaches CERT.DPpb.SIG to the RSP session in step 465, the eUICC (425) omits the certificate chain verification for CERT.DPpb.SIG in step 475 and uses CERT.DPpb.SIG for signature verification. SIG can be used.
  • the eUICC (425) receives otPK.DP.KA or verifies the received data with additional otPK.DP.KA to extract otPK.DP.KA, and the eUICC (425) attaches to the corresponding RSP session. You can complete the profile installation by combining it with the saved otSK.EUICC.KA to create a shared secret to create a session key for profile installation.
  • otPK.EUICC.KA is included in the data and is not received, but the signature value of the profile server is calculated to include the corresponding otPK.EUICC.KA, and the calculated A signature value may be received.
  • the profile server may generate a signature value including otPK.EUICC.KA while performing the profile creation procedure as previously described in FIGS. 2 and 3 in step 430.
  • the eUICC 425 verifies the signature of the profile server for the data received in one of steps 445, 460, or 475.
  • the process it may be possible to generate a signature by additionally including the stored otPK.EUICC.KA when calculating the profile server's signature, and then verify the profile server whose signature value is equal to the received signature value.
  • the saved otPK.EUICC.KA to be used can be judged as otPK.EUICC.KA corresponding to otSK.EUICC.KA attached to the RSP Session or otPK.EUICC.KA attached to the RSP Session. This may be equally applied to step 545, step 550, or step 575 of FIG. 5, and step 645 or step 650 of FIG. 6, even if not further described in the drawings below.
  • the eUICC (425) returns the profile installation result (480) to the LPAf of the terminal (420) (step 480), and the terminal can reply the processing result to Factory IT (485).
  • Factory IT/OEM 415 may return the processing result returned in step 485 to the profile server/server vendor 410.
  • the results returned in step 490 include at least the EID used (or eUICC certificate containing the EID), otPK.EUICC.KA, processing result, and transaction ID received in steps 445 to 460 and step 475.
  • a reply may be sent containing one piece of information, and if the information is transmitted in batches, it may be delivered in the form of a list of processing results from multiple terminals.
  • the profile server 410 which has received the processing result in step 490, may check the BPP processing result and process usage value deletion/status update. Meanwhile, although not shown in this drawing, the SP/SP server 405 may receive the processing results for profile installation through Factory IT/OEM 415 or through the profile server/server vendor 410. . Meanwhile, in the case where verification fails in other drawings of the present invention, including FIG. 4, the eUICC transmits the error to the terminal's LPAf, or, if it does not go through the terminal's LPAf, to the entity in the terminal that initiated the procedure and installs it. It should be noted that the procedure can be terminated.
  • the message transmitted and received in step 460 of FIG. 4 may have the form shown in Table 2 below.
  • eUICCOtpk may not be provided in step 460 depending on the settings between the terminal manufacturer and the eUICC manufacturer.
  • FIG. 5 is a diagram illustrating the operation of installing the profile in FIG. 2 from Factory IT to the eUICC according to an embodiment of the present disclosure.
  • FIG. 5 describes the operation of provisioning a profile by performing the authentication procedure between the server and the eUICC and the BPP installation procedure, excluding steps 460 to 470 of the preliminary information sharing procedure for Profile installation in FIG. 4 described above.
  • Factory IT 515 can obtain and store key information related to the BPP mapped to N bundles of eUICCs. Factory IT 515 can transmit key information related to the BPP to the terminal 520 that is mapped in the process of provisioning setting values to the terminal at a specific time before shipping the terminal from the factory. (Step 535) Factory IT (515) can check the terminal ID and/or EID during processing for provisioning a profile at the factory, selects encryption key information related to the BPP mapped thereto, and sends the corresponding terminal (520). It can be transmitted to or a request message from the terminal can be received and transmitted as a reply message.
  • the information delivered to the terminal 520 in step 535 is BPP (including otPK.DP.KA) and encryption key information such as [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], and [otPK.EUICC.KA. ], [dpSignature1], or dpSignature2.
  • BPP including otPK.DP.KA
  • encryption key information such as [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], and [otPK.EUICC.KA. ], [dpSignature1], or dpSignature2.
  • PK.DPauth.SIG Profile server certificate used to authenticate the profile server itself.
  • the profile server may include PK.DPauth.SIG, which is a public key required to verify the signature value used to authenticate the profile server.
  • - otPK.DP.KA Can be used to create a shared secret value that eUICC uses for profile download and transmission sessions with the profile server.
  • Profile server authentication Authenticate Server
  • profile server authentication data can be provided as a value signed with the profile server's secret key (SK.DPauth.SIG) used for profile server authentication. You can.
  • - otPK.EUICC.KA Can be included in the data for profile server authentication, or transmitted as data for profile binding, and is data signed by the profile server including the corresponding information (e.g. dpSignature1 or It may also be transmitted (included in one of dpSignature2).
  • - dpSignature1 Can indicate data signed with the profile server's private key (SK.DPauth.SIG) corresponding to the public key included in CERT.DPauth.SIG.
  • - dpSignature2 Can indicate data signed with the profile server's private key (SK.DPpb.SIG) corresponding to the public key included in CERT.DPpb.SIG.
  • the terminal 520 enters the IFPP mode (step 540) when a function for downloading a profile for IFPP is received or the terminal 520 settings at the time of profile provisioning enter the state of factory provisioning/setting, etc. Alternatively, it may be at least one of the following cases where the user enters a menu selection for profile provisioning in a factory environment.
  • the terminal 520 If the terminal 520 is already set to provisioning/provisioning settings of a profile at the factory, the terminal must already perform the profile download procedure in IFPP mode before receiving a new function for downloading the profile for IFPP. It may be possible to recognize this and immediately enter the corresponding mode. For example, when entering LPA in factory settings, profile setting mode can be automatically entered with IFPP.
  • entering the IFPP mode is a new function, for example, ESfac.prepareFactoryDownload (including BPP (including otPK.DP.KA), [CERT.DPauth.SIG], CERT received by the terminal 520 in step 535 It can be set before receiving a function such as .DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], [dpSignature1], or dpSignature2).
  • the information received in step 535 includes an additional certificate to authenticate [CERT.DPauth.SIG] and CERT.DPpb.SIG. Chain information may be further included, and may then be transmitted to the eUICC 525 in at least one of step 545 or step 575.
  • the terminal 520 and the eUICC 525 which have received a message requesting to perform the download procedure of the profile for IFPP, recycle the profile installation process after terminal shipment defined in the existing SGP.22 to install the profile. It can be done.
  • a mutual authentication process must be performed during the profile installation process.
  • eUICC and the profile server generate a random value and verify the signed value of the delivered random value to perform mutual authentication.
  • the eUICC generates an eUICC Challenge value as a random value and transmits data including this to the profile server.
  • the profile server signs the eUICC Challenge with the secret key of the profile server and then replies to the eUICC
  • the eUICC is sent to the profile server.
  • the profile server can be authenticated by determining whether the eUICC Challenge value included in the data transmitted by the profile server is the same as the value previously generated and sent by the eUICC.
  • the profile server also generates a Server Challenge value and transmits it to eUICC.
  • eUICC When eUICC signs and replies with data including that value, the value signed with eUICC's private key is verified with eUICC's public key and eUICC transmits the value.
  • the eUICC can be authenticated by determining whether the Server Challenge value included in the data is the same as the value previously generated and sent by the profile server.
  • the eUICC Challenge value and Server Challenge value for mutual authentication between the profile server 510 and the eUICC 525 cannot be created and delivered in real time, so the values are delivered as pre-generated information. It can be.
  • the eUICC Challenge that the profile server replies to the eUICC may be a random value pre-generated by the eUICC obtained by the profile server in the profile ordering/creation step of FIGS. 2 and 3. For example, this may be the otPK.EUICC.KA value.
  • the eUICC returns the eUICC's signature data, including the Server Challenge, to the profile server, and the profile server verifies the data.
  • the profile server may not be able to perform eUICC authentication.
  • the eUICC 525 may not authenticate the eUICC 525 during the process of performing a profile download.
  • the profile server does not authenticate during the process of performing profile download, and the profile server 510 sends otPK.EUICC signed and delivered by eUICC in the previous profile preparation step (e.g., step 350 of FIG. 3).
  • the eUICC 525 may be authenticated in advance by verifying the KA and then generating a BPP.
  • the profile server 510 includes the Server Challenge value that the profile server 510 transmits to the eUICC 525 in the existing ES10x procedure in the data signed by the server.
  • Factory IT can transmit the relevant information to the terminal, allowing the terminal to forward it to the eUICC.
  • the Server Challenge may be created and provided when the profile server 510 receives a BPP creation request or before.
  • the LPAf (not shown) of the terminal 520 can enter IFPP and transmit data including the eUICC Challenge as server authentication information to the eUICC 525.
  • the data may be transmitted in the form of data signed by the server. (545 steps)
  • the eUICC 525 may determine step 545 as the RSP session creation time and operate. When the eUICC 525 determines step 545 as the time to create an RSP session, if there was an RSP session already created before the eUICC 525 received the message, the eUICC 425 deletes the previously created RSP session and You can save the previously unused otPK.EUICC.KA and otSK.EUICC.KA from the previous RSP session without deleting them (since the profile installation has not been completed), and then start a new RSP session.
  • An example of the message transmitted in step 545 may be a message such as ES10b.AuthenticateServer (Data1(Including otPK.EUICC.KA), dpSignature1, CERT.DPauth.SIG).
  • dpSignature1 is a value obtained by signing Data1 with the secret key of the profile server 510.
  • the eUICC 525 that received the message can verify the profile server 510 (step 550), and otPK.EUICC.KA can be used to verify the signature of the eUICC Challenge and the profile server.
  • a verification procedure for authenticating the profile server 510 in the eUICC 525 may be performed including one of the following procedures. Of course, the procedure is not limited to the following.
  • Certificate chain verification Verification by whether the CERT.DPauth.SIG certification chain and the eUICC's certification chain are in the same certification chain.
  • - eUICC 525 verifies the signature of the profile server: The value decrypted from dpSignature1 with the public key of the received profile server is compared with the value of Data1 (Including otPK.EUICC.KA) to determine whether it has the same value. verification.
  • the eUICC 525 can verify the certificate and signature of the profile server 510 and return the results to the LPAf of the terminal 520. (Step 555) If the eUICC 525 fails to verify the certificate and signature of the profile server 510, it returns an error message to the terminal 520 (step 555), and the terminal 520 returns the error message (step 555). may terminate the profile installation operation and return the error result to Factory IT (515). (585 steps)
  • the LPAf of the terminal 520 may transmit otPK.DP.KA and BPP to the eUICC 525 after receiving a normal response message through the reply message in step 555, and the LPAf of the terminal 520 may transmit the BPP to 1. It can be divided into more than one APDU and transmitted to the eUICC (525).
  • the BPP included and transmitted may be encrypted with a session key and transmitted, and otPK.DP.KA may be transmitted together with or included in the BPP.
  • An example of a message transmitted from the LPAf of the terminal 520 to the eUICC 525 is ES10b.
  • the eUICC 525 may receive a series of messages for BPP installation received through step 575, and one of these messages may include otPK.DP.KA. When otPK.DP.KA is transmitted as included in data signed by the profile server 510, the eUICC 525 can receive and use the public key for verifying the signed data together or in the previous step.
  • CERT.DPpb.SIG including PK.DPpb.SIG may be transmitted together in step 575 or transmitted in step 545, and in this case, the eUICC 525 sends CERT to the RSP session created in step 545.
  • .DPpb.SIG can be attached and used for signature verification using the attached CERT.DPpb.SIG in step 575.
  • the eUICC 525 receives otPK.DP.KA or verifies the received signed data (dpSignature2) with the public key included in CERT.DPpb.SIG to extract otPK.DP.KA, eUICC ( 525) You can create a shared secret by combining it with otSK.EUICC.KA saved, create a session key for installing the profile, and complete the profile installation.
  • the otSK.EUICC.KA to be used can be mapped to otSK.EUICC.KA attached to the relevant RSP session or otPK.EUICC.KA attached to the RSP session.
  • the eUICC 525 returns the profile installation result to the LPAf of the terminal 520 (step 580), and the terminal 520 can reply the processing result to Factory IT/OEM.
  • Factory IT/OEM 515 may return the processing result returned in step 585 to the profile server/server vendor 510.
  • the result returned in step 590 includes at least one of the following information: the used EID (or eUICC certificate containing the EID), otPK.EUICC.KA, processing result, and transaction ID previously received in step 545 or 575. It can be responded to, and in cases where the information is transmitted in batches, it can also be transmitted in the form of a list of processing results from multiple terminals.
  • the profile server 510 which has received the processing result in step 590, may check the BPP processing result and process usage value deletion/status update. Meanwhile, although not shown in this drawing, the SP/SP server 505 may receive the processing results for profile installation through Factory IT or through a profile server.
  • FIG. 6 is a diagram illustrating the operation of installing the profile in FIG. 2 from Factory IT to the eUICC according to an embodiment of the present disclosure.
  • Figure 6 is an embodiment explaining a method of transferring key information related to BPP from the terminal to the eUICC in one step.
  • Factory IT 615 can obtain and store key information related to the corresponding BPP mapped to N bundles of eUICCs. Factory IT 615 can transmit key information related to the BPP to the terminal 620 that is mapped in the process of provisioning settings to the terminal at a specific time before shipping the terminal from the factory. (Step 635) Factory IT 615 can check the terminal ID and/or EID during processing to provision a profile at the factory, select the encryption key information related to the BPP mapped thereto, and send it to the corresponding terminal 620. It can be transmitted or a request message from the terminal can be received and transmitted as a reply message.
  • the information transmitted to the terminal 620 in step 635 includes BPP and encryption key information such as otPK.DP.KA, [otPK.EUICC.KA], [ServerChallenge], [dpSignature1], dpSignature2, [CERT.DPauth.SIG], Alternatively, it may be transmitted including at least one of CERT.DPpb.SIG.
  • otPK.DP.KA can be transmitted as information included in or transmitted together with the BPP, or it can be signed and transmitted with the secret key of the profile server for profile binding. If otPK.DP.KA is transmitted as signed data, the profile server may also transmit the profile server's public key for verification of the signed data. The public key of the profile server may be transmitted and included in the profile server's certificate.
  • This may be a certificate such as CERT.DPauth.SIG, CERT.DPpb.SIG, for example, or a new certificate with a public key that is mirrored to the secret key used by the profile server for IFPP (e.g. CERT.DPifpp.SIG). It may be possible.
  • the description of the encryption key that can be transmitted in step 635 is as follows.
  • PK.DPpb.SIG is a public key required to verify the signature value used to authenticate the profile server.
  • - otPK.DP.KA Can be used to create a shared secret value that eUICC uses for profile download and transmission sessions with the profile server.
  • - ServerChallenge Contains data for profile server authentication, and data for profile server authentication may be provided in the form of data signed with the profile server's secret key (SK.DPauth.SIG) used for profile server authentication.
  • the challenge may be created in advance when the profile server/server vendor 610 receives the BPP creation request in step 630 or before.
  • - otPK.EUICC.KA It may be included in the data for profile server authentication, or may be included and transmitted in the data for profile binding, and is data signed by the profile server including the relevant information (for example, dpSignature1 or dpSignature2) Alternatively, it may be transmitted (included in one of dpSignature3).
  • - dpSignature1 Can indicate data signed with the profile server's private key (SK.DPauth.SIG) corresponding to the public key included in CERT.DPauth.SIG.
  • - dpSignature2 Can indicate data signed with the profile server's private key (SK.DPpb.SIG) corresponding to the public key included in CERT.DPpb.SIG.
  • - dpSignature3 Can indicate data signed with the profile server's private key (SK.DPifpp.SIG) corresponding to the public key included in CERT.DPifpp.SIG.
  • the profile server 610 may sign all data transmitted in step 635 with the private key of the profile server newly set for IFPP and transmit a certificate containing the corresponding public key together.
  • the data can be transmitted as signed data that can be decrypted with CERT.DPifpp.SIG and PK.EUICC.SIG included in the corresponding certificate. It may also be possible for data to be transmitted with otPK.EUICC.KA included.
  • step 645 data signed by CERT.DPifpp.SIG instead of CERT.DPauth.SIG and CERT.DPpb.SIG, and SK.DPifpp.SIG instead of dpSignature 1 and diSignature 2 may be transmitted.
  • CERT.DPauth.SIG used for the authentication step between the server and the terminal and dpSignature 1, which is data signed with the secret key used for profile server authentication, may be received without being included. If it is received without CERT.DPauth.SIG, CERT.DPpb.SIG can be used for profile server authentication as well as profile binding.
  • the terminal 620 enters the IFPP mode (step 640) when a function for downloading a profile for IFPP is received, or the terminal 620 settings at the time of profile provisioning are in the factory provisioning/setting state, etc. , or it may be at least one of the cases where the user enters the menu selection for profile provisioning in a factory environment.
  • the terminal 620 If the terminal 620 is already set to provisioning/provisioning settings of a profile at the factory, the terminal must already perform the profile download procedure in IFPP mode before receiving a new function for downloading the profile for IFPP. It may be possible to recognize this and immediately enter the corresponding mode. For example, when entering LPA in factory settings, profile setting mode can be automatically entered with IFPP.
  • entering the IFPP mode is a new function, for example, ESfac.prepareFactoryDownload (including BPP, otPK.DP.KA, [CERT.DPauth.SIG], CERT.DPpb received by the terminal 620 in step 635) It can be set before receiving functions such as .SIG, [ServerChallenge], [otPK.EUICC.KA], [dpSignature1], dpSignature2). Meanwhile, as described above in FIGS. 4 and 5, if there are additional certificate chains in [CERT.DPauth.SIG] and CERT.DPpb.SIG, the corresponding certificate chains may be included and transmitted. That is, additional certificate chain information may be included in the information received in step 635 and then transmitted to the eUICC 525 in step 645.
  • ESfac.prepareFactoryDownload including BPP, otPK.DP.KA, [CERT.DPauth.SIG], CERT.DPpb received by the terminal 620 in step
  • otPK.EUICC.KA may be transmitted included in the data signed by the profile server.
  • the terminal 620 and the eUICC 625 which received a message requesting to perform the download procedure of the profile for IFPP, define a new function for injecting BPP for factory installation, and the terminal 620 performs BPP and Related key information can also be delivered to the eUICC (625) in batches.
  • Key information related to BPP delivered in batches may be a message containing at least one piece of information for the terminal 620 to install a profile for IFPP from Factory IT 615.
  • the terminal 620 may transmit a message conveying the BPP for factory installation to the eUICC 625 via the LPA or without passing the LPA. That is, the corresponding BPP delivery function may be called by the terminal's application or software, and the terminal 620 may transmit the corresponding information to the eUICC 625 without going through the LPA.
  • the eUICC 625 When the eUICC 625 receives a function defined for installing BPP for IFPP from the terminal 620 (step 645), it can enter the BPP installation mode for IFPP and proceed with installing the profile. In step 645, install the BPP. Messages transmitted for this purpose may be transmitted as one or more divided messages. If the BPP and the eUICC data required for installation of the BPP are transmitted through one function as in step 645, when the eUICC (625) receives the function, it can recognize that an RSP session has been created. The eUICC 625 recognizes that an RSP session has been created, cancels the session if an RSP session previously exists, and stores otPK.EUICC.KA and otSK.EUICC.KA not used in the session. The operation may be performed by recognizing that a new RSP session is starting.
  • eUICC 525 may include performing one of the following verification procedures. (650 steps)
  • - Verify otPK.EUICC.KA The message received by the eUICC 625 in step 645 may or may not include otPK.EUICC.KA. And otPK.EUICC.KA may be transmitted with or without being included in the data signed by the profile server. If otPK.EUICC.KA is included and received, the eUICC 625 may determine whether it has otSK.EUICC.KA corresponding to otPK.EUICC.KA.
  • data containing otPK.EUICC.KA can be signed and transmitted with one of the secret keys (SK.DPxx.SIG, xx indicates purpose) used by the profile server.
  • this may be a secret key (SK.DPauth.SIG) used for profile binding or a secret key (SK.DPauth.SIG) used for authentication of the profile server.
  • the eUICC 625 sends a public key for verification of the signature or a profile server certificate containing the public key to the terminal ( It can also be received along with the message received from 620).
  • the eUICC 625 may perform one of the following procedures depending on whether otPK.EUICC.KA is received and signed data is received. Of course, the procedure is not limited to the following.
  • the eUICC 625 verifies the signature of the profile server, including the stored otPK.EUICC.KA. If the eUICC 625 fails to verify the signature of the profile, the procedure can be terminated by returning an error to the terminal.
  • the eUICC 625 can also perform additional verification by using otPK.EUICC.KA as an eUICCChallenge to authenticate the profile server in addition to a-i.
  • otPK.EUICC.KA received as data signed by the profile server can be used as an eUICC Challenge to check whether it is the same as otPK.EUICC.KA previously created and stored by eUICC. If there is a value different from the stored value, an error can be returned to the terminal and the procedure can be terminated.
  • the eUICC 625 may not verify the signature of the profile server that signed otPK.EUICC.KA.
  • otPK.EUICC.KA is not included: eUICC 625 does not verify the signature of the profile server that signed otPK.EUICC.KA, or otPK.EUICC.KA is not included and received as described previously in FIG. 4. If the value must be used for signature verification (i.e., if the profile server calculates the signature including that value), the stored otPK.EUICC.KA can be used to verify the signature.
  • eUICC (625) can generate a Session key with the stored otSK.EUICC.KA and the received otPK.DP.KA. otPK.DP.KA is signed with SK.DPpb.SIG. It can be received and included in data.
  • otSK.EUICC.KA to be used by the eUICC 625 is otSK.EUICC.KA corresponding to otPK.EUICC.KA included by the profile server when calculating the signature, or otSK.EUICC.KA corresponding to the received otPK.EUICC.KA. You can judge.
  • the eUICC 625 can decrypt and install the profile. If decryption is not possible with the generated session key, the eUICC 625 cannot install the profile, so it may return an error and end the installation procedure.
  • the eUICC 625 While the eUICC 625 is performing the profile installation procedure, it may not be able to perform the real-time mutual authentication process currently defined in SGP.22. That is, in the process of provisioning a profile at the factory, the eUICC returns the signature data of the eUICC (625), including the Server Challenge, to the profile server, and the profile server verifies the data, allowing the profile server to perform eUICC authentication. There may not be. Accordingly, the message received by the eUICC 625 (step 645) may be received without including the Server Challenge. Therefore, as previously described in step 350 of FIG.
  • the profile server 615 verifies otPK.EUICC.KA signed and delivered by the eUICC 625 in step 630 of preparing the profile, and then generates a BPP to create the eUICC ( 625) can also be authenticated in advance. Additionally, the eUICC 625 may process without authenticating the server. In this case, as previously mentioned, data signed with CERT.DPauth.SIG and SK.DPauth.SIG in step 635 may not be included and received.
  • the eUICC 625 may return an error and end the procedure.
  • the eUICC 625 uses a new certificate for IFPP, such as CERT.DPifpp.SIG, instead of CERT.DPauth.SIG or CERT.DPpb.SIG or both, and the corresponding
  • a new certificate for IFPP such as CERT.DPifpp.SIG
  • the eUICC 625 verifies the signature using the corresponding certificate, returns an error if signature verification fails, and continues the profile installation procedure if signature verification succeeds. there is.
  • the eUICC (625) returns the profile installation result to the terminal 620 (step 655) as in step 480 of FIG. 4 or step 580 of FIG. 5, and the terminal 620 sends the processing result to Factory IT (615). You can reply.
  • Factory IT/OEM 615 may return the returned results to the profile server/server vendor 610.
  • the result returned in step 670 may include at least one information among the used EID (or eUICC certificate containing the EID), otPK.EUICC.KA, processing result, and transaction ID received in step 645. And in the case where the information is transmitted in batches, it may be transmitted in the form of a list of processing results from multiple terminals.
  • the profile server 610 may check the BPP processing result and process usage value deletion/status update. Meanwhile, although not shown in this drawing, the SP/SP vendor 605 may receive the processing results for profile installation through Factory IT/OEM 620 or through the profile server/server vendor 610. .
  • FIG. 7 is a block diagram showing the structures of the profile server 700, Factory IT 720, and terminal 740 in a wireless communication system according to an embodiment of the present disclosure.
  • the profile server 700 may include a communication unit 705, a control unit 710, and an encryption unit 715.
  • the communication unit 705 can transmit data to or receive data from other devices.
  • the communication unit 705 can transmit or receive an encrypted key, an encrypted profile, etc.
  • the communication unit 705 may be equipped with at least one communication module and an antenna.
  • the control unit 710 can control each component of the profile server 700 to install a profile according to the present invention.
  • the specific operation of the control unit 710 is as described above.
  • the profile server 700 determines whether the order is the same by referring to the service provider server, the manufacturer's server, or information received from the service provider and the manufacturer, and provides the profile and eUICC provided information for the same order. It can be processed to be mapped and stored in a storage unit (not shown). Additionally, the operation can be controlled to prepare in advance by mapping a profile to a specific EID by referring to the EID information received from the service provider.
  • the control unit 710 determines whether a profile needs to be prepared for IFPP using information received from a message received through the communication unit 705, and processes entry into the operation of preparing the profile. It can be done.
  • the profile server 700 receives the message received from Factory IT through the communication unit 705, determines that the received message is a request to download a profile for IFPP, processes the operation to prepare a profile for the factory, and sends the processing result to the communication unit. It can be sent to Factory IT through (705).
  • the encryption unit 715 encrypts or decrypts the key or profile under the control of the control unit 710.
  • the encryption unit 715 may include an HSM or may be named HSM itself, and may perform encryption and decryption of the profile without exposing the encryption key. Depending on implementation, the encryption unit 715 may be built into the control unit 710 or may be implemented in the form of software code driven by the control unit 710.
  • Factory IT 720 may include a communication device 725, a control device 730, and a storage device 735. Communication device 725 may transmit data to or receive data from other devices.
  • Factory IT (720) operates as a single device including a storage device (735)
  • Factory IT (720) operates as a separate control device (730) that centrally controls the communication device (725) and the storage device (735).
  • Factory IT 720 may be composed of one or more devices as described above.
  • the communication device 725 may transmit or receive an encrypted key, an encrypted profile, etc.
  • the communication device 725 may be equipped with at least one communication module and an antenna.
  • Factory IT 720 when Factory IT 720 operates as a single device including a storage device 735, the communication device 725 is not connected to the manufacturer's external server but to Factory IT/OEM It can be provided for independent network connection inside.
  • Factory IT 720 can transmit or receive encrypted key information, encrypted profile, etc. through the communication device 725.
  • the received profile or encrypted key, etc. can be transmitted to the terminal 740 through the communication device 725 by determining the mapping between the relevant information and the terminal to which it is mapped by the control device 730 of Factory IT 720. .
  • factory IT/manufacturer devices that transmit encrypted key information, encrypted profiles, etc. to the profile server or return profile installation results may be the same or different devices.
  • the Factory IT device that receives the profile from the profile server/server vendor and the Factory IT device that transmits the profile to the terminal may be the same or different devices.
  • the Factory IT device that transmits the profile to the terminal may or may not have a connection to an external server. Accordingly, the installation result may be transmitted from the device that received it from the terminal to another device within the Factory IT/manufacturer, and may be transmitted from the externally connected factory IT device to the profile server/server vendor.
  • the storage device 735 of Factory IT 720 may store at least one encrypted profile. Additionally, encrypted key information for at least one encrypted profile can be stored.
  • the control device 730 determines this, updates the installation result information of the mapped profile, and updates the result information in the storage device 735. It can be provided in batches to the profile server 700 at a specific point in time.
  • the storage device 735 is a hard disk type, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), and electrically erasable programmable read-only memory (EEPROM). Memory), PROM (Programmable Read-Only Memory), magnetic memory, magnetic disk, and optical disk may include at least one type of storage medium.
  • Factory IT 720 may be implemented in the form of a server, etc.
  • the terminal 740 may include a communication unit 745, a control unit 750, a storage unit 755, and an eUICC 760.
  • the communication unit 745 can transmit data to or receive data from other devices.
  • the communication unit 745 may receive an encrypted key, an encrypted profile, etc.
  • the communication unit 745 may be equipped with at least one communication module and an antenna.
  • the control unit 750 can control each component of the terminal 740 to install a profile according to the present invention.
  • the control unit 750 can control the overall operations of the terminal 740.
  • the control unit 750 may transmit and receive signals through the communication unit 745.
  • the control unit 750 can write and read data into the storage unit 755.
  • control unit 750 may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as application programs.
  • CP communication processor
  • AP application processor
  • the control unit 750 requests the storage unit 755 for the information and displays it on the screen display unit (not shown) or receives the information and adds additional information. Actions can be processed.
  • the control unit 750 matches the data recorded through the storage unit 755 or the information collected through the control unit 750 and the communication unit 745 and refers to the profile installation selection at the factory.
  • the terminal can perform a processing process in which information can be inferred.
  • the control unit 750 can determine whether user consent is required for specific information stored in the terminal 740 and display it on a screen display unit (not shown).
  • the control unit 750 can control the terminal 740 to perform the corresponding operation.
  • the control unit 750 may include an LPA responsible for driving and controlling the eUICC 760, an application in which the LPA is integrated, and an application that manages factory installation.
  • the control unit 750 interprets the information received in the LPA or application and processes a specific Command APDU request to the CP (communication processor), or collects part or all of the requested information from the storage unit 755 and stores it in the LPA or application. It may include a terminal framework that responds to .
  • the control unit 755 compiles predetermined information obtained from the eUICC 760 through the terminal 740 and the communication unit 745, determines the operation of entering the IFPP mode, and controls the eUICC 760 to enter IFPP. can do.
  • the eUICC 760 may operate under the control of the control unit 750.
  • the eUICC 760 enters the IFPP mode, processes the profile installation procedure, and sends the processing result to the terminal. You can reply to (740).
  • the control unit 750 receives profile information or a response message of the profile package received from Factory IT 720, and determines whether there is profile installation request information for IFPP from the received profile information or response message.
  • Determine whether to perform profile installation in factory mode by referring to the terminal settings or user input information upon reception, determine whether to enter normal mode or IFPP mode, and decide whether to enter IFPP mode.
  • configure a message to be delivered to the eUICC (760) configure the profile information of the profile package into one or more messages, control to deliver the message to the eUICC (760), and configure the message to be delivered to the eUICC (760).
  • the processing result received at the terminal 740 is received to determine whether to end the profile installation procedure, the processing result is delivered to the communication unit 745, and the communication unit 745 sends the processing result to Factory IT (720).
  • the terminal 740 can be controlled to transmit.
  • the storage unit 755 may store data such as basic programs, application programs, and setting information for operation of the terminal 740.
  • the storage unit 755 includes a flash memory type, a hard disk type, a multimedia card micro type, and a card type memory (e.g. For example, SD or Memory) and EEPROM (Electrically Erasable Programmable Read-Only Memory).
  • the storage unit 755 may be integrated and implemented as a control unit 750 and a SoC (System on Chip).
  • the control unit 750 can perform various operations using various programs, content, data, etc. stored in the storage unit.
  • the eUICC 760 is a UICC chip built into the terminal 740 and can perform the function of storing, managing, and deleting at least one profile. Profile may collectively refer to data information such as one or more applications, subscriber authentication information, and phone book stored in the existing UICC card.
  • the eUICC 760 may be included as part of the terminal 740 as shown in FIG. 1, and is expressed as a separate module in FIGS. 2 to 6 to explain the operation between the terminal 740 and the eUICC 760.
  • the eUICC 760 may include a control unit, a storage unit, and a communication unit for installing a profile. Some of the applications within the eUICC 760 may be installed on the control unit 750, and the installed applications may include some of the LPA functions.
  • the control unit of the eUICC 760 obtains the profile installation request information of the terminal 720 received through the communication unit and then sends a predetermined message about the profile package and encryption key information through the corresponding message information. acquires information, determines whether the eUICC (760) will enter IFPP, determines the operation, and compares the profile installation procedure for IFPP and the received information with the information in the storage of the eUICC (760) Verification and processing may be performed, the received profile package may be verified, an installation operation may be performed, a message may be composed, and the processing result may be returned to the terminal 740 through the communication unit.
  • Factory IT 720 may include more or fewer components than the components described above.
  • the terminal 740 may be an electronic device, and the electronic device may be of various types.
  • the electronic device may include, for example, a portable communication device (eg, a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance device.
  • the electronic device according to an embodiment of this document is not limited to the above-mentioned devices.
  • FIG. 8 is a block diagram showing the structure of Factory IT in a wireless communication system according to an embodiment of the present disclosure. Specifically, FIG. 8 shows an example of the configuration of Factory IT 720 of FIG. 7.
  • Factory IT may be composed of a central control device (815), communication device 1 (810), a storage device 820, and communication device 2 (825).
  • the storage device 820 may be a server that stores eUICC data (information such as encryption key, certificate, etc.) for profile installation at a specific factory or profiles to be installed.
  • Communication device 2 (825) is a device (e.g., PC) at the contact point of the terminal 830 that will inject the profile into a device including a storage device, and receives the profiles of the terminals to be installed from the storage device 820. After receiving and storing it, it can connect to the terminal 830 wired or wirelessly to transmit a series of commands for profile injection and receive processing results for the commands from the terminal 830.
  • Communication device 1 which provides a connection with an external device, may not provide a direct connection with the storage device 820 and communication device 2 (825) that includes the storage device.
  • the storage device 820 receives and stores the installation results from the communication device 2 (825), and collects the installation results in real time or in batches on the profile server/server vendor (805).
  • Communication device 1 (810) which is a device responsible for transmitting information at a specific point in time, may be a different device.
  • first, second, or first or second may be used simply to distinguish one component from another, and to refer to that component in other respects (e.g., importance or order) is not limited.
  • One (e.g., first) component is said to be “coupled” or “connected” to another (e.g., second) component, with or without the terms “functionally” or “communicatively.”
  • any of the components can be connected to the other components directly (e.g. wired), wirelessly, or through a third component.
  • module used in this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit, for example.
  • a module may be an integrated part or a minimum unit of the parts or a part thereof that performs one or more functions.
  • the module may be implemented in the form of an application-specific integrated circuit (ASIC).
  • ASIC application-specific integrated circuit
  • a storage medium e.g., internal memory or external memory
  • a machine e.g., electronic device
  • a processor of a machine may call at least one instruction among one or more instructions stored from a storage medium and execute it. This allows the device to be operated to perform at least one function according to the at least one instruction called.
  • the one or more instructions may include code generated by a compiler or code that can be executed by an interpreter.
  • a storage medium that can be read by a device may be provided in the form of a non-transitory storage medium.
  • 'non-transitory' only means that the storage medium is a tangible device and does not contain signals (e.g. electromagnetic waves). This term refers to cases where data is stored semi-permanently in the storage medium. There is no distinction between temporary storage cases.
  • Computer program products are commodities and can be traded between sellers and buyers.
  • the computer program product may be distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)) or via an application store (e.g. Play Store TM ) or on two user devices (e.g. It can be distributed (e.g. downloaded or uploaded) directly between smartphones) or online.
  • a machine-readable storage medium e.g. compact disc read only memory (CD-ROM)
  • an application store e.g. Play Store TM
  • two user devices e.g. It can be distributed (e.g. downloaded or uploaded) directly between smartphones) or online.
  • at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.
  • each component (eg, module or program) of the above-described components may include a single entity or a plurality of entities.
  • one or more of the components or operations described above may be omitted, or one or more other components or operations may be added.
  • multiple components eg, modules or programs
  • the integrated component may perform one or more functions of each component of the plurality of components identically or similarly to those performed by the corresponding component of the plurality of components prior to the integration. .
  • operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or , or one or more other operations may be added.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 개시는 보다 높은 데이터 전송률을 지원하기 위한 5G 또는 6G 통신 시스템에 관련된 것이다. 본 개시의 다양한 실시예에 따르면, 무선 통신 시스템에서 eUICC (embed universal integrated circuit card)를 구비하는 단말에 의해 수행되는 방법은, Factory IT 서버로부터 프로파일의 설치를 위한 BPP (bound profile package) 및 상기 BPP와 관련된 암호화 키(key) 정보를 포함하는 제1 메시지를 수신하는 동작, 제1 메시지에 기반하여, 프로파일 설정 모드에 진입하는 동작, eUICC에게, BPP를 포함하는 제2 메시지를 송신하는 동작, eUICC로부터, 프로파일의 설치 결과를 포함하는 제3 메시지를 수신하는 동작을 포함할 수 있다.

Description

무선 통신 시스템에서, 프로파일을 프로비저닝하기 위한 방법 및 장치
본 개시는 무선 통신 시스템에서, 프로파일을 프로비저닝(provisioning)하기 위한 방법 및 장치에 관한 것이다.
구체적으로, 본 개시는 무선 통신 시스템에서 복수의 프로파일들을 단말에 프로비저닝하기 위한 방법 및 장치에 관한 것이다.
5G 이동통신 기술은 빠른 전송 속도와 새로운 서비스가 가능하도록 넓은 주파수 대역을 정의하고 있으며, 3.5 기가헤르츠(3.5GHz) 등 6GHz 이하 주파수('Sub 6GHz') 대역은 물론 28GHz와 39GHz 등 밀리미터파(㎜Wave)로 불리는 초고주파 대역('Above 6GHz')에서도 구현이 가능하다. 또한, 5G 통신 이후(Beyond 5G)의 시스템이라 불리어지는 6G 이동통신 기술의 경우, 5G 이동통신 기술 대비 50배 빨라진 전송 속도와 10분의 1로 줄어든 초저(Ultra Low) 지연시간을 달성하기 위해 테라헤르츠(Terahertz) 대역(예를 들어, 95GHz에서 3 테라헤르츠(3THz) 대역과 같은)에서의 구현이 고려되고 있다.
5G 이동통신 기술의 초기에는, 초광대역 서비스(enhanced Mobile BroadBand, eMBB), 고신뢰/초저지연 통신(Ultra-Reliable Low-Latency Communications, URLLC), 대규모 기계식 통신 (massive Machine-Type Communications, mMTC)에 대한 서비스 지원과 성능 요구사항 만족을 목표로, 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위한 빔포밍(Beamforming) 및 거대 배열 다중 입출력(Massive MIMO), 초고주파수 자원의 효율적 활용을 위한 다양한 뉴머롤로지 지원(복수 개의 서브캐리어 간격 운용 등)와 슬롯 포맷에 대한 동적 운영, 다중 빔 전송 및 광대역을 지원하기 위한 초기 접속 기술, BWP(Band-Width Part)의 정의 및 운영, 대용량 데이터 전송을 위한 LDPC(Low Density Parity Check) 부호와 제어 정보의 신뢰성 높은 전송을 위한 폴라 코드(Polar Code)와 같은 새로운 채널 코딩 방법, L2 선-처리(L2 pre-processing), 특정 서비스에 특화된 전용 네트워크를 제공하는 네트워크 슬라이싱(Network Slicing) 등에 대한 표준화가 진행되었다.
현재, 5G 이동통신 기술이 지원하고자 했던 서비스들을 고려하여 초기의 5G 이동통신 기술 개선(improvement) 및 성능 향상(enhancement)을 위한 논의가 진행 중에 있으며, 차량이 전송하는 자신의 위치 및 상태 정보에 기반하여 자율주행 차량의 주행 판단을 돕고 사용자의 편의를 증대하기 위한 V2X(Vehicle-to-Everything), 비면허 대역에서 각종 규제 상 요구사항들에 부합하는 시스템 동작을 목적으로 하는 NR-U(New Radio Unlicensed), NR 단말 저전력 소모 기술(UE Power Saving), 지상 망과의 통신이 불가능한 지역에서 커버리지 확보를 위한 단말-위성 직접 통신인 비 지상 네트워크(Non-Terrestrial Network, NTN), 위치 측위(Positioning) 등의 기술에 대한 물리계층 표준화가 진행 중이다.
뿐만 아니라, 타 산업과의 연계 및 융합을 통한 새로운 서비스 지원을 위한 지능형 공장 (Industrial Internet of Things, IIoT), 무선 백홀 링크와 액세스 링크를 통합 지원하여 네트워크 서비스 지역 확장을 위한 노드를 제공하는 IAB(Integrated Access and Backhaul), 조건부 핸드오버(Conditional Handover) 및 DAPS(Dual Active Protocol Stack) 핸드오버를 포함하는 이동성 향상 기술(Mobility Enhancement), 랜덤액세스 절차를 간소화하는 2 단계 랜덤액세스(2-step RACH for NR) 등의 기술에 대한 무선 인터페이스 아키텍쳐/프로토콜 분야의 표준화 역시 진행 중에 있으며, 네트워크 기능 가상화(Network Functions Virtualization, NFV) 및 소프트웨어 정의 네트워킹(Software-Defined Networking, SDN) 기술의 접목을 위한 5G　베이스라인 아키텍쳐(예를 들어, Service based Architecture, Service based Interface), 단말의 위치에 기반하여 서비스를 제공받는 모바일 엣지 컴퓨팅(Mobile Edge Computing, MEC) 등에 대한 시스템 아키텍쳐/서비스 분야의 표준화도 진행 중이다.
이와 같은 5G 이동통신 시스템이 상용화되면, 폭발적인 증가 추세에 있는 커넥티드 기기들이 통신 네트워크에 연결될 것이며, 이에 따라 5G 이동통신 시스템의 기능 및 성능 강화와 커넥티드 기기들의 통합 운용이 필요할 것으로 예상된다. 이를 위해, 증강현실(Augmented Reality, AR), 가상현실(Virtual Reality, VR), 혼합 현실(Mixed Reality, MR) 등을 효율적으로 지원하기 위한 확장 현실(eXtended Reality, XR), 인공지능(Artificial Intelligence, AI) 및 머신러닝(Machine Learning, ML)을 활용한 5G 성능 개선 및 복잡도 감소, AI 서비스 지원, 메타버스 서비스 지원, 드론 통신 등에 대한 새로운 연구가 진행될 예정이다.
또한, 이러한 5G 이동통신 시스템의 발전은 6G 이동통신 기술의 테라헤르츠 대역에서의 커버리지 보장을 위한 신규 파형(Waveform), 전차원 다중입출력(Full Dimensional MIMO, FD-MIMO), 어레이 안테나(Array Antenna), 대규모 안테나(Large Scale Antenna)와 같은 다중 안테나 전송 기술, 테라헤르츠 대역 신호의 커버리지를 개선하기 위해 메타물질(Metamaterial) 기반 렌즈 및 안테나, OAM(Orbital Angular Momentum)을 이용한 고차원 공간 다중화 기술, RIS(Reconfigurable Intelligent Surface) 기술 뿐만 아니라, 6G 이동통신 기술의 주파수 효율 향상 및 시스템 네트워크 개선을 위한 전이중화(Full Duplex) 기술, 위성(Satellite), AI(Artificial Intelligence)를 설계 단계에서부터 활용하고 종단간(End-to-End) AI 지원 기능을 내재화하여 시스템 최적화를 실현하는 AI 기반 통신 기술, 단말 연산 능력의 한계를 넘어서는 복잡도의 서비스를 초고성능 통신과 컴퓨팅 자원을 활용하여 실현하는 차세대 분산 컴퓨팅 기술 등의 개발에 기반이 될 수 있을 것이다.
상술한 바와 같은 논의를 바탕으로, 본 개시(disclosure)는, 무선 통신 시스템에서 대량의 프로파일들을 단말에 설치하기 위한 방법 및 장치를 제공하고자 한다.
본 개시의 다양한 실시예에 따르면, 무선 통신 시스템에서 eUICC (embed universal integrated circuit card)를 구비하는 단말에 의해 수행되는 방법은, Factory IT 서버로부터 프로파일의 설치를 위한 BPP (bound profile package) 및 상기 BPP와 관련된 암호화 키(key) 정보를 포함하는 제1 메시지를 수신하는 동작, 제1 메시지에 기반하여, 프로파일 설정 모드에 진입하는 동작, eUICC에게, BPP를 포함하는 제2 메시지를 송신하는 동작, eUICC로부터, 프로파일의 설치 결과를 포함하는 제3 메시지를 수신하는 동작을 포함할 수 있다.
본 개시는 무선 통신 시스템에서 프로파일들을 효과적으로 설치할 수 있는 방법 및 장치를 제공할 수 있다.
본 개시에서 얻을 수 있는 효과는 다양한 실시 예들에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 일 실시 예에 따른 프로파일을 프로비저닝하기 위한 구성 요소 간의 관계를 나타낸 도면이다.
도 2는 본 개시의 일 실시 예에 따른 대량의 프로파일을 프로비저닝하는 동작을 설명하기 위한 도면이다.
도 3은 본 개시의 일 실시 예에 따른 대량의 프로파일을 프로비저닝하기 위해 프로파일을 준비하는 동작을 설명하기 위한 도면이다.
도 4는 본 개시의 일 실시 예에 따른 도 2에서의 프로파일을 Factory IT에서 eUICC로 설치하는 동작을 설명하기 위한 도면이다.
도 5는 본 개시의 일 실시 예에 따른 도 2에서의 프로파일을 Factory IT에서 eUICC로 설치하는 동작을 설명하기 위한 도면이다.
도 6은 본 개시의 일 실시 예에 따른 도 2에서의 프로파일을 Factory IT에서 eUICC로 설치하는 동작을 설명하기 위한 도면이다.
도 7은 본 개시의 일 실시 예에 따른 무선 통신 시스템에서 프로파일 서버, Factory IT, 단말의 구조를 나타낸 블록도이다.
도 8은 본 개시의 일 실시 예에 따른 무선 통신 시스템에서의 Factory IT 의 구조를 나타내 블록도이다.
이하 첨부된 도면을 참조하여 본 개시의 동작 원리를 상세히 설명한다. 하기에서 본 개시를 설명하기에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시의 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이하, 기지국은 단말의 자원할당을 수행하는 주체로서, gNode B, eNode B, Node B, BS (Base Station), 무선 접속 유닛, 기지국 제어기, 또는 네트워크 상의 노드 중 적어도 하나일 수 있다. 단말은 UE (User Equipment), MS (Mobile Station), 셀룰러폰, 스마트폰, 컴퓨터, 또는 통신 기능을 수행할 수 있는 멀티미디어 시스템을 포함할 수 있다. 본 개시에서 하향링크(Downlink; DL)는 기지국이 단말에게 전송하는 신호의 무선 전송 경로이고, 상향링크는(Uplink; UL)는 단말이 기국에게 전송하는 신호의 무선 전송경로를 의미한다. 또한, 이하에서 LTE 혹은 LTE-A 시스템을 일 예로서 설명할 수도 있지만, 유사한 기술적 배경 또는 채널 형태를 갖는 다른 통신시스템에도 본 개시의 실시예가 적용될 수 있다. 예를 들어 LTE-A 이후에 개발되는 5세대 이동통신 기술(5G, new radio, NR)이 본 개시의 실시예가 적용될 수 있는 시스템에 포함될 수 있으며, 이하의 5G는 기존의 LTE, LTE-A 및 유사한 다른 서비스를 포함하는 개념일 수도 있다. 또한, 본 개시는 숙련된 기술적 지식을 가진 자의 판단으로써 본 개시의 범위를 크게 벗어나지 아니하는 범위에서 일부 변형을 통해 다른 통신시스템에도 적용될 수 있다. 이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다.
이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예를 들면, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다. 이때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA(Field Programmable Gate Array) 또는 ASIC(Application Specific Integrated Circuit)과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행할 수 있다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다. 또한 실시예에서 '~부'는 하나 이상의 프로세서를 포함할 수 있다.
이하 설명의 편의를 위하여, 본 개시는 현재 존재하는 통신표준 가운데 3GPP (The 3rd Generation Partnership Project) 단체에서 정의하는 표준인 5GS 및 NR 규격에서 정의하고 있는 용어 및 명칭들을 사용한다. 하지만, 본 개시가 상기 용어 및 명칭들에 의해 한정되는 것은 아니며, 다른 규격에 따르는 무선통신망에도 동일하게 적용될 수 있다. 예를 들면, 본 개시는 3GPP 5GS/NR (5세대 이동통신 표준)에 적용할 수 있다.
이하 설명의 편의를 위하여, 본 개시는 현재 존재하는 eSIM 표준 가운데 GSMA (GSM Association) 단체에서 정의하는 표준인 RSP 규격들(SGP.XX 시리즈)에서 정의하고 있는 용어 및 명칭들을 사용한다. 하지만, 본 개시가 상기 용어 및 명칭들에 의해 한정되는 것은 아니며, 다른 규격에 따르는 eSIM에도 동일하게 적용될 수 있다.
범용 통합 회로 카드(UICC: Universal Integrated Circuit Card)는 단말, 일 예로 이동 통신 단말기 등에 삽입되어 사용되는 스마트카드(smart card)이고 UICC 카드라고도 칭해진다. 상기 UICC에 이동 통신 사업자의 네트워크에 접속하기 위한 접속 제어 모듈이 포함될 수 있다. 이러한 접속 제어 모듈의 예제들은 범용 가입자 식별 모듈(USIM: Universal Subscriber Identity Module), 가입자 식별 모듈(SIM: Subscriber Identity Module), 인터넷 프로토콜 멀티미디어 서비스 식별 모듈(ISIM: IP (Internet Protocol) Multimedia Service Identity Module) 등을 포함한다.
USIM이 포함된 UICC를 통상 USIM 카드라고 부르기도 한다. 마찬가지로 SIM 모듈이 포함된 UICC를 통상적으로 SIM카드라고 부르기도 한다. 하기의 설명에서 SIM 카드라 함은 UICC 카드, USIM 카드, ISIM이 포함된 UICC 등을 포함하는 통상의 의미로 사용될 수 있음에 유의하여야만 할 것이다. SIM 카드라 하여도 그 기술적 적용이 USIM 카드 또는 ISIM 카드 또는 일반적인 UICC 카드에도 동일하게 적용될 수 있음은 물론이다.
SIM 카드는 이동 통신 가입자의 개인 정보를 저장하고, 이동 통신 네트워크에 접속 시 가입자 인증 및 트래픽 (traffic) 보안 키(key) 생성을 수행하여 안전한 이동통신 이용을 가능하게 한다.
SIM 카드는 일반적으로 상기 SIM 카드를 제조할 때 특정 이동 통신 사업자의 요청에 의해 해당 이동 통신 사업자를 위한 전용 카드로 제조되며, 해당 사업자의 네트워크 접속을 위한 인증 정보, 예를 들어, USIM (Universal Subscriber Identity Module) 어플리케이션 및 IMSI (International Mobile Subscriber Identity), K 값, OPc 값 등이 사전에 카드에 탑재되어 출고된다. 따라서 제조된 상기 SIM 카드는 해당 이동 통신 사업자가 납품 받아 가입자에게 제공되며, 이후 필요 시에는 OTA (Over The Air) 등의 기술을 활용하여 상기 UICC 내 어플리케이션의 설치, 수정, 삭제 등의 관리도 수행할 수 있다.
가입자는 소유한 이동 통신 단말기에 UICC 카드를 삽입하여 해당 이동 통신 사업자의 네트워크 및 응용 서비스의 이용이 가능하다. 그리고 가입자는 이동 통신 단말기 교체 시 UICC 카드를 기존 이동 통신 단말기에서 새로운 이동 통신 단말기로 이동 삽입함으로써 UICC 카드에 저장된 인증 정보, 이동통신 전화번호, 개인 전화번호부 등을 새로운 이동 통신 단말기에서 그대로 사용이 가능하다.
그러나, SIM 카드는 이동 통신 단말기 사용자가 다른 이동 통신사의 서비스를 제공받는데 있어 불편한 점이 있다. 이동 통신 단말기 사용자는 이동 통신 사업자로부터 서비스를 받기 위해 SIM 카드를 물리적으로 획득해야 되는 불편함이 있다. 예를 들면, 다른 나라로 여행을 했을 때 현지 이동통신 서비스를 받기 위해서는 현지 SIM 카드를 구해야 하는 불편함이 있다. 로밍 서비스의 경우 불편함을 어느 정도 해결해 주지만, 비싼 요금 및 통신사간 계약이 되어 있지 않은 경우 서비스를 받을 수 없는 문제도 있다.
한편, UICC 카드에 SIM 모듈을 원격으로 다운로드 받아서 설치할 경우, 이러한 불편함을 상당 부분 해결할 수 있다. 예를 들면, 사용자가 원하는 시점에 사용하고자 하는 이동통신 서비스의 SIM 모듈을 UICC 카드에 다운로드 받을 수 있다. 이러한 UICC 카드는 또한 복수 개의 SIM 모듈을 다운로드 받아서 설치하고 그 중의 적어도 한 개의 SIM 모듈만을 선택하여 사용할 수 있다. 이러한 UICC 카드는 단말기에 고정하거나 고정하지 않을 수 있다. 단말에 고정하여 사용하는 UICC를 통상적으로 eUICC라고 하는데, 본 개시에서는 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드를 eUICC로 통칭할 수 있다. 즉, 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하는 UICC 카드 및 고정하지 않는 UICC 카드를 통칭하여 eUICC로 사용할 수 있다. 또한 다운로드 받는 SIM 모듈정보를 통칭하여 프로파일(Profile) 이라는 용어로 사용한다. 프로파일의 예는 초기 설정을 위한 Connectivity를 위해서만 용도 제한된 프로파일인 프로비저닝 프로파일 (provisioning Profile), 그리고 이런 용도 제한이 없는 프로파일인 오퍼레이셔널 프로파일 (operational Profile), 테스트용으로 한정된 테스트 프로파일(test Profile)등으로 용도에 따라 더 구분될 수도 있다.
eUICC내에 프로파일을 설치하기 위해서는 통상 단말의 출고 이후에 단말 사용자가 프로파일 다운로드 서버와 실시간 네트워크 연결을 통해서 프로파일을 다운로드하는 것을 가정하고 있다. 현재, GSMA에서 정의된 eSIM 표준화 규격인 Remote Profile Provisioning 표준 규격들, 일 예로 Consumer 단말향 Remote SIM Provisioning 표준인 SGP.21/22, IoT 단말향 Remote SIM Provisioning 표준인 SGP.31/32, M2M 단말향 Remote SIM Provisioning 표준인 SGP.01/02에 따르면, 단말은 프로파일 다운로드 서버와 실시간으로 네트워크로 연결되어, 단말과 프로파일 서버간에 여러 차례 메시지를 주고받는 과정 및 이 과정에서 상호 인증(Common Mutual Authentication)을 거친 다음에 프로파일을 다운로드하는 과정으로 정의하고 있다. 하지만, 단말은 프로파일 다운로드 서버와 프로파일을 다운로드하는 시점에서 항상 네트워크가 연결된 상황을 가정할 수 없다. 따라서, 이를 해소하기 위해서 단말에 초기 설정을 위한 connectivity만을 제공하는 용도로, 용도가 제한된 프로파일인 provisioning Profile(프로비저닝 프로파일)이 SGP.21/22에 도입되었다. 이에 따라, 단말 제조사는 provisioning Profile이 탑재된 eUICC를 출고할 수도 있다. 또한, 서비스 사업자와 계약에 의거하여 제조사에서 eUICC내에 위와 같은 용도 제한이 없는 통신 사업자의 Operational Profile을 선 탑재하여 출고하는 경우도 가능할 수 있다. eUICC에 프로파일을 선 탑재하는 경우에 있어, 통상 eUICC 제조사 공장에서 프로파일이 선 탑재된 eUICC를 단말 제조사에 납품하는 형태로 탑재하게 되는데, 해당 eUICC를 포함하고 있는 단말들은 단말 제조사가 하드웨어를 구분하여 재고 관리(SKU: Stock Keeping Unit)가 필요하다는 문제가 있어 활성화되지 못하고 있다. 한편, 공장에서 프로파일을 단말에 프로비저닝 하는 신규 Work Item이 최근 GSMA(GSM Association, 통신사업자 연합)에서 승인되어 SGP.41 (기술 요구사항 규격), SGP.42(기술 규격(예정))으로 공장에서 프로파일을 단말에 프로비저닝하기 위한 장치 및 방법들에 대한 표준화 논의가 이루어질 예정이다.
본 개시에서 공장에서 프로파일을 프로비저닝하기 위한 기능은 IFPP (In Factory Profile Provisioning) 기능이라고 지칭하고 해당 기능을 지원하는 상태로 진입하는 경우 IFPP 모드로 진입 또는 IFPP 상태로 표기할 수 있다. 또한, 각 Entity의 이름 끝에 "f"를 추가로 붙여서 해당 모드로 동작하는 상태임을 표기할 수도 있다. 예를 들어, 특정 Entity로서 단말, LPA, eUICC, 프로파일 서버, 팩토리 IT, SP(Service Provider) 서버, EUM(eUICC Manufacturer) 서버는 IFPP 모드를 더 지원하는 Entity일 수 있으며, 또는 해당 기능만을 지원하는 Entity일 수 있다. 예를 들어, 프로파일 서버의 하나인 SM-DP+는 SGP.21/22에서 정의한 Consumer향 Remote SIM Provisioning 기능을 지원하지만, SGP.41/42에서 정의하는 IFPP 기능의 일부를 추가적으로 더 지원하는 서버일 수 있다. 또는 프로파일 서버인 SM-DP+는 IFPP 기능 만을 지원하는 프로파일 서버일 수도 있다. IFPP 상태로 동작하고 있는 프로파일 서버는 일 예로 프로파일서버f와 같이 본 발명에서 혼용하여 표기할 수도 있다.
본 개시에서 UICC(Universal Integrated Circuit Card)는 이동통신 단말기에 삽입하여 사용하는 스마트카드로서 이동통신 가입자의 네트워크 접속 인증 정보, 전화번호부, SMS와 같은 개인정보가 저장되어 GSM, WCDMA, LTE, 5G 등과 같은 이동통신 시스템에 접속 시 가입자 인증 및 트래픽 보안 키 생성을 수행하여 안전한 이동통신 이용을 가능케 하는 칩을 의미할 수 있다. UICC에는 가입자가 접속하는 이동통신 네트워크의 종류에 따라 SIM(Subscriber Identification Module), USIM(Universal SIM), ISIM(IP Multimedia SIM)등의 통신 어플리케이션이 탑재되며, 또한 전자지갑, 티켓팅, 전자여권 등과 같은 다양한 응용 어플리케이션의 탑재를 위한 상위 레벨의 보안 기능을 제공할 수 있다.
본 개시에서 eUICC(embedded UICC)는 단말에 내장된 보안 모듈로 한정하지 않으며 단말에 삽입 및 탈거가 가능한 착탈식 보안 모듈을 포함한다. eUICC는 programmable SIM 카드로 일반적으로 OTA(Over The Air)기술을 이용하여 프로파일을 저장한 서버로부터 다운받아 설치할 수 있다. eUICC는 프로파일 다운로드 및 설치가 가능한 UICC로 명명할 수 있다.
본 개시에서 eUICC에 OTA 기술을 이용하여 프로파일을 다운받아 설치하는 방법은 전술한 바와 같이 단말에 삽입 및 탈거가 가능한 착탈식 UICC에도 적용될 수 있다. 예를 들면, 본 개시의 실시 예는 OTA 기술을 이용하여 프로파일을 다운 받아 설치 가능한 착탈식 UICC에 적용될 수 있다. 본 개시에서 eUICC 고유 식별 번호로(eUICC ID)는 EID로 지칭될 수 있다. 본 개시에서 지칭하는 UICC는 SIM과 혼용될 수 있고, 용어 eUICC는 eSIM과 혼용될 수 있다.
본 개시에서 프로파일(Profile)은 UICC 내에 저장되는 어플리케이션, 파일시스템, 인증키 값 등을 소프트웨어 형태로 패키징 한 것을 의미할 수 있다. 또한, 프로파일을 접속정보로 명명할 수 있다. 또한, 본 개시에서 USIM 프로파일은 프로파일과 동일한 의미 또는 프로파일 내 USIM 어플리케이션에 포함된 정보를 소프트웨어 형태로 패키징 한 것을 의미할 수 있다. 본 개시에서 프로파일 패키지(Profile Package) 내지 암호화된 프로파일 패키지 (Bound Profile Package, BPP)는 프로파일과 혼용되거나 특정 프로파일의 데이터 객체(data object)를 나타내는 용어로 사용될 수 있으며, 프로파일 TLV 또는 프로파일 패키지 TLV (Profile Package TLV)로 명명될 수 있다. 프로파일 식별자는, 프로파일의 고유 식별 번호를 나타내는 ICCID (Integrated Circuit Card Identifier)로 지칭될 수 있다. 프로파일 패키지가 암호화 파라미터를 이용해 암호화된 경우 보호된 프로파일 패키지(Protected Profile Package (PPP)) 또는 보호된 프로파일 패키지 TLV (PPP TLV)로 명명될 수 있다. 프로파일 패키지가 특정 eUICC에 의해서만 복호화 가능한 암호화 파라미터를 이용해 암호화된 경우 묶인 프로파일 패키지(Bound Profile Package (BPP)) 또는 묶인 프로파일 패키지 TLV (BPP TLV)로 명명될 수 있다. 프로파일 패키지 TLV는 TLV (Tag, Length, Value) 형식으로 프로파일을 구성하는 정보를 표현하는 데이터 세트 (set) 일 수 있다.
본 개시에서 프로파일 서버는 프로파일을 생성하거나, 생성된 프로파일을 암호화하거나, 프로파일 원격관리 명령어를 생성하거나, 생성된 프로파일 원격관리 명령어를 암호화하는 기능을 제공하거나, IFPP 모드를 제공하거나, 또는 단말의 복수 프로파일 활성화 지원 기능을 포함할 수 있는 서버로, SM-DP(Subscription Manager Data Preparation), SM-DP+(Subscription Manager Data Preparation plus), SM-SR (Subscription Manager Secure Routing)으로 표현될 수 있다.
본 개시에서 사용하는 용어 '단말' 또는 '기기'는 이동국(MS), 사용자 장비(UE; User Equipment), 모바일 장비(ME: Mobile 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) 단말/디바이스, IoT 단말/디바이스를 포함할 수도 있다. 본 개시에서 단말은 전자장치 또는 단순히 디바이스라 지칭할 수 있다. eUICC로 프로파일 설치하는 기능을 제공하는 단말(120)은 eSIM 단말로 지칭할 수 있다.
본 개시의 실시 예에 따르면, EUM은 eUICC Manufacturer로 eUICC를 생산하고 eUICC를 personalization하여 제공하는 제조 업체를 의미하며, EUM에서 전달하는 정보들은 EUM 서버 또는 별도 구성 요소 간의 채널을 통해서 온 오프라인으로 전달될 수 있다. 또한, EUM은 EUM 서버 또는 EUM에서 수행하는 역할을 의미할 수 있다.
본 개시에서 단말 또는 기기는 UICC 또는 eUICC를 제어하도록 단말 또는 기기 내에 설치된 소프트웨어 또는 애플리케이션을 포함할 수 있다. 소프트웨어 또는 애플리케이션은, 일 예로 Local Profile Assistant(LPA), SIM Manager, IoT Profile Assistant(IPA)와 같은 애플리케이션일 수 있다. 해당 소프트웨어 또는 기능들은 통합되어 제공될 수도 있다. 예를 들어, LPA와 IPA는 하나의 통합 앱으로 제공될 수도 있다. 본 개시에서 UICC 또는 eUICC를 제어하도록 단말 또는 기기 내에 설치된 소프트웨어 또는 애플리케이션을 통칭하여 LPA로 표기할 수 있다.
본 개시에서 APDU(Application Protocol Data Unit)는 단말 또는 기기 내의 제어부(Controller)가 eUICC와 주고받는 메시지 형태 또는 메시지일 수 있다. APDU는 Command와 Response의 한 쌍이며, APDU Command와 APDU Response는 ISO 7816을 참조하여 ETSI 102.221에 정의되어 있다. ETSI 102.221에 정의된 바와 같이 APDU Command는 APDU의 헤더로 CLA(Class of Instruction), INS(Instruction), P1(Instruction Parameter 1), P2(Instruction Parameter 2), Body로 Lc(Number of bytes in the command data field), Data, Le(Number of bytes expected in response of the command)의 구조를 가지며, APDU Response는 Optional Data field와, SW1(Status byte 1), SW2 (Status byte 2)의 구조를 가지며 이에 대한 상세한 설명은 ETSI 102.221 규격을 참조한다. LPA 또는 단말에서 전송하는 애플리케이션 메시지는 eUICC에 APDU 형태로 전송될 수 있으며 이 때 전송하는 정보는 APDU의 Data에 포함되어 전송될 수 있다.
본 개시에서 AKA는 인증 및 키 합의 (Authentication and Key agreement)를 나타낼 수 있으며, 3GPP 및 3GPP2망에 접속하기 위한 인증 알고리즘을 나타낼 수 있다. K는 AKA 인증 알고리즘에 사용되는 eUICC에 저장되는 암호키 값이며, 본 개시에서 OPc는 AKA 인증 알고리즘에 사용되는 eUICC에 저장될 수 있는 파라미터 값이다.
본 개시에서 NAA는 네트워크 접속 어플리케이션 (Network Access Application) 응용프로그램으로, UICC에 저장되어 망에 접속하기 위한 USIM 또는 ISIM과 같은 응용프로그램일 수 있다. NAA는 망접속 모듈일 수 있다.
본 개시에서 End user, 사용자, 가입자, 서비스 가입자, user는 해당 단말의 사용자로 혼용되어 사용될 수 있다.
본 개시에서 Factory IT는 제조 공정에서 단말에 특정 데이터 또는 설정을 프로비저닝하도록 처리하는 역할을 담당하는 장치로 단말에 프로파일을 다운로드 해 주는 기능을 포함하는 모듈을 지칭할 수 있고, 프로파일 서버로부터 프로파일들을 획득하여 저장할 수 있는 기능을 더 포함할 수도 있다. Factory IT는 팩토리 IT 장비,팩토리 IT 서버, 팩토리 프로비저닝 장비, 공장 서버와 혼용되어 사용될 수 있고, 이하 서버로 표현하였더라도 본 발명에서 Factory IT는 1개 이상의 모듈, 일 예로 데이터를 저장하는 서버와 설정 또는 데이터를 eSIM 단말에 주입해 주는 역할을 하는 단말로 기능할 수 있다.
본 개시에서 OEM은 단말 제조사, 제조사와 혼용되어 사용될 수 있다.
본 개시에서 Service provider(SP)는 통신 서비스 사업자, MNO, 모바일 네트워크 사업자, 사업자, 통신사, SP 서버로 혼용되어 사용할 수 있으며 실시 예에 따라 Service provider는 Service Provider의 서버 또는 Service Provider에서 수행하는 역할을 의미할 수 있다.
본 개시에서 서버 벤더는 프로파일 서버를 운용하는 벤더를 의미하며, 프로파일 서버 벤더에서 수행하는 역할을 의미할 수 있다.
본 개시에서 암호화 키는 암복호화키를 모두 포괄하는 의미로 사용하였다. 예를 들어, 암호화 키는 데이터를 암호화하는 데 사용하는 비밀키 (secret key 또는 private key, 개인키로 용어 혼용 사용) 또는 이를 복호화하는 공개키가 포함될 수 있으며, 공개 키는 인증서 형태로 공유될 수 있다.
본 개시에서 일회용 암호화 키, 일회용 공개키 또는 개인키는 key agreement를 위해 요구되는 암호화 키를 의미할 수 있으며, 여기에서 일회용(one-time)은 1번의 프로파일 설치를 위해 사용되는 키라는 의미로 해석될 수 있다. 본 개시에서 후술하는 바와 같이 해당 키는 프로파일 설치 성공 시 폐기, 설치 최종 성공 전에는 eUICC에 저장 가능하며, GSMA SGP.22 정의를 참고하여 해석될 수 있다.
본 개시는 eUICC를 포함하는 단말에서 하드웨어 SKU는 분리하지 않고, 프로파일을 삽입하여, 하드웨어 SKU를 동일하게 유지하면서 eSIM 단말을 출시할 수 있도록 하는 방법 및 장치를 제공하고자 하는 것이다.
또한, 본 개시는 공장 환경의 특성상 대량의 단말들에 빠르게 프로파일 주입이 필요하여, 프로파일 서버와 개별 단말 간 실시간 네트워크 연결 및 상호 인증하는 절차를 포함하여 여러 차례 왕복으로 메시지를 주고받는 과정을 수행하기 어려우므로, 이를 극복하여 대량의 단말들에 프로파일들을 신속하게 다운로드하여 설치해 줄 수 있는 방법 및 장치를 제공하고자 하는 것이다. 이를 위해 프로파일 서버 및 eSIM 단말에서 일반 상황에서의 프로파일 다운로드와 공장에서의 단말에 프로파일을 대량으로 주입하는 환경에서의 프로파일 다운로드를 구분하는 동작이 필요할 수 있다. 또한, 프로파일 서버와 단말 간 실시간 연결을 고려하지 않고 Factory IT 장비에서 프로파일(들)을 단말에 프로비저닝하는 방법이 필요할 수 있으며, 특히 프로파일 서버 (일 예로 SM-DP+) - eUICC간 "비 실시간성"을 고려한 프로파일 암호화 키 전달 및 검증, 설치하는 방법이 필요할 수 있다. 또한, 공장에서 대량으로 프로파일을 프로비저닝하는 환경을 고려한 방식이 필요하며, 특히 이를 위해 프로파일들을 주문 및 준비하는 과정에서 Entity간에 대량의 프로파일(들)의 정보를 전송할 수 있도록 제공하는 방법 및 장치가 필요할 수 있다.
본 개시의 다양한 실시 예에 따르면, 단말 제조사는 대량의 프로파일들을 프로파일 서버와의 실시간 연결이 없이도 eSIM 단말에 미리 설치하여 출고할 수 있으며, H/W SKU 분리 없이 프로파일을 설치함으로써 재고를 효율적으로 관리할 수 있다.
또한, 본 개시의 다양한 실시 예에 따르면, 사용자는 프로파일이 이미 설치된 단말을 구입함으로써 네트워크에 바로 접속할 수 있어 사용자가 프로파일 다운로드를 위해 와이파이 또는 이동통신 망을 찾아가야 하는 불편함을 해소할 수 있으므로 사용자의 편의성을 증대시킬 수 있다.
또한, 본 개시의 다양한 실시 예에 따르면, 통신 사업자는 자사 프로파일 다운로드를 위한 Provisioning Profile 또는 자사의 네트워크 서비스를 바로 이용할 수 있는 operational Profile이 설치된 상태로 단말을 사용자에게 제공할 수 있으므로 사용자의 eSIM 사용 편리성을 재고할 수 있다.
도 1은 본 개시의 일 실시 예들에 따른 프로파일을 프로비저닝하기 위한 구성 요소 간의 관계를 나타낸 도면이다.
도 1을 참조하면, 프로파일 서버/서버 벤더(이하, 프로파일 서버 또는 서버 벤더로 칭할 수 있다.)(100)는 프로파일을 생성하거나, 생성된 프로파일을 저장하거나, 생성된 프로파일을 암호화하거나, 원격 프로파일 관리 명령어(RPM: Remote Profile Management)를 생성하거나, 생성된 프로파일 원격 관리 명령어를 암호화하는 기능을 포함하거나, 생성된 프로파일을 eSIM 단말 또는 다른 프로파일 저장 서버에 전송하는 기능을 지원하거나, IFPP를 위한 프로파일을 생성하거나, IFPP를 위해 생성된 프로파일 저장하거나, 또는 IFPP를 위해 생성된 프로파일을 암호화하는 기능을 지원하는 서버 중 적어도 하나를 나타낼 수 있다. 원격 프로파일 관리(RPM: Remote Profile Management)는 프로파일 서버(100)에서 단말(120)로 전송하는 명령어에 의해 프로파일 설치, 활성화, 비활성화, 삭제 및 기타 기능이 수행되는 일련의 절차를 통칭할 수 있다. RPM은 통신 사업자, 서비스 제공자, 또는 단말의 소유자에 의해 요청되어 프로파일 서버(100)에 의해 명령어가 생성될 수 있다. 프로파일 서버/서버 벤더(100)는 SP(Service Provider)/SP 서버(이하, SP 또는 SP 서버로 칭할 수 있다.)(150)로부터 프로파일 주문 요청을 수신하여 IFPP를 위한 프로파일 생성을 위한 요청인지를 판별하거나, Factory IT 서버/OEM(이하, Factory IT, Factory 서버, 또는 OEM으로 칭할 수 있다.)(110) 내지 SP/SP서버(150)로부터 수신된 프로파일 주문 정보를 주문한 EID 정보와 조합하여 프로파일과 EID를 맵핑하여 프로파일 서버(100)에 준비해 둘 수도 있다. SP/SP서버(150)는 Factory IT서버/OEM(110)으로부터 수신된 프로파일 주문 요청을 수신하여 IFPP를 위한 프로파일들에 대한 제공 주문 요청인지를 판별하여 SP/SP서버(150)에서 프로파일 서버/서버 벤더(100)로 주문을 넣음으로써, 프로파일 서버(100)에서 1개 이상의 BPP(Bound Profile Package)를 Factory IT(110)에 제공하도록 할 수 있다.
단말(120)은 eUICC(140)와 통신 모뎀(미도시)을 포함할 수 있다. 통신 모뎀은 무선 통신을 위한 기저대역 프로세서(Baseband Processor) (이하 기저대역(Baseband))가 1개 이상 탑재될 수도 있다. 단말(120)은 Factory IT(110)로부터 IFPP를 위해 생성된 BPP(들)을 제공받아 eUICC(140)로 BPP(들)을 설치하는 기능을 제공할 수 있다. 단말(120)은 BPP를 eUICC(140)로 전달할 수 있는데, LPAf로 동작하는 LPA(130)를 거쳐서 eUICC(140)에 전달하거나 또는 LPA(130)를 거치지 않고 eUICC(140)로 전달할 수도 있다. LPAf로 동작하는 LPA(130)를 사용하여 eUICC(140)로 전달되는 BPP의 설치 및 암호화 키 정보들에 대한 메시지를 전송하는 방법들에 대한 일 예로는 ES10x로 시작하는 하나 이상의 메시지에 포함되어 전송되는 방법일 수 있다. 이하, 이에 대한 실시 예는 도 4 내지 도 6에서 후술하기로 한다.
한편, 프로파일 서버(100)를 1개로 표현하였으나 프로파일 서버(100)는 복수 개일 수 있고 이에 따라 Factory IT(110)는 복수 개의 프로파일 서버(100)로부터 BPP들을 수신하여 저장해 둘 수도 있다.
전술한 바와 같이 LPA(130)는 eUICC 제어 소프트웨어 또는 애플리케이션으로 IFPP 기능을 지원할 수 있다. LPA(130)는 단말(120) 내지 eUICC(140)의 논리적인 기능으로 구현될 수도 있다. LPAf로 동작하는 LPA(130)는 Factory IT(110)로부터 프로파일과 프로파일 서버(100)를 인증하기 위한 추가적인 인증 정보들을 수신 받아 이를 eUICC(140)로 제공해 줄 수 있고, eUICC(140)로부터 프로파일 설치 결과를 획득하여 Factory IT(110)에 전달해 주는 역할을 수행할 수도 있다.
eUICC(140)은 LPAf로 동작하는 LPA(130)로부터 수신한 ES10x의 하나 이상의 메시지 또는 Factory IT(110) 또는 단말의 공장 설정에 대한 애플리케이션이나 소프트웨어를 통해서 수신한 프로파일 설치 메시지를 통해 공장에서의 프로파일 설치를 위한 요청임을 판별하여 IFPP모드로 진입을 결정할 수 있다. 만약 eUICC(140)가 IFPP 기능을 지원하지 않는 경우, eUICC(140)은 에러를 리턴하고 IFPP 처리를 종료할 수도 있다.
eUICC(140)는 프로파일과 프로파일 서버(100) 인증 정보들을 단말(120)로부터 획득하여 해당 정보를 가지고 프로파일의 복호화를 수행하여 설치를 처리하고, 설치된 결과를 해당 요청을 전송한 구성 요소, 즉 단말의 특정 애플리케이션 또는 단말의 LPAf로 동작하는 LPA(130)에 회신할 수도 있다. 또한, eUICC(140)는 수신된 메시지를 서명한 구성 요소의 서명 검증을 통해서 프로파일을 암호화한 프로파일 서버(100)를 검증하거나 또는 메시지를 전송한 프로파일 서버(100)의 인증을 수행할 수도 있다. eUICC(140)에는 eUICC(140)의 보안 도메인들에서 요구하는 인증서들(Credentials), 예를 들어 프로파일 서버(100)인 SM-DP+ 인증서를 검증하기 위한 증명서 발급자의 루트 공개 키(Certificate Issuer's Root public Key), eUICC 제조사의 키 셋(keyset) 등을 저장하는 공간인 ECASD(Embedded UICC Controlling Authority Security Domain), eSIM 운영 플랫폼 등이 포함될 수 있다. 또한, LPA의 기능의 일부가 구현되어 있을 수도 있다.
Factory IT 서버(110)는 공장 IT 서버로써, 공장에서 단말에 프로파일을 프로비저닝하는 역할을 담당하는 서버일 수 있다. Factory IT 서버(110)는 EUM/EUM 서버(이하, EUM 또는 EUM 서버로 칭할 수 있다.)(160)로부터 일회용 암호화 키를 포함한 해당 eUICC(140)들에 대한 소정의 정보들을 획득하거나, 프로파일 서버/서버 벤더(100)에 획득한 eUICC(140)들에 대한 정보의 전체 또는 일부를 전달하거나, SP/SP 서버(150)에 주문할 EID와 프로파일에 대한 맵핑(mapping)을 위한 정보를 전달하거나, 수신된 암호화 키 정보와 BPP를 저장하거나 하는 서버 일 수 있다.
Factory IT 서버/OEM(110)은 프로파일 서버/서버 벤더(100)에 공장에서 주입을 위한 BPP(S)를 요청, 해당 요청의 결과로써 프로파일 서버/서버 벤더(100)로부터 eUICC(140)에 설치를 위한 BPP와 프로파일 서버(100)에서 서명한 데이터들을 획득, 수신된 BPP들와 서명된 데이터들 Factory IT 서버(110)에 저장, 또는 수신 또는 저장된 BPP들 중에서 프로파일을 설치할 대상 단말의 EID에 맵핑되는 BPP를 골라서 공장 설정 과정에서 맵핑되는 단말로 BPP를 전달 중 적어도 하나를 수행할 수 있다. Factory IT 서버(110)에서 프로파일 서버(100), SP 서버(150), EUM(160)과 주고받는 정보들의 일부는 서버 간 인터페이스를 통한 메시지 송수신이 아닌 다른 온 오프라인 채널 (예, 이메일 전송 등) 다른 형태로 해당 역할을 수행하는 주체 간(즉, 단말 제조사, 프로파일 서버 운영 벤더, 서비스 사업자, eUICC 제조사)에 공유될 수도 있다.
EUM(eUICC Manufacturer)(160)은 eUICC 제조 업체로 eUICC 인증을 위한 자격 증명을 위한 키 정보들을 eUICC(140)에 주입하여 개인화(personalization)한 eUICC(140)들을 단말 제조사에 제공하거나, EUM(eUICC Manufacturer)/EUM 서버(160)에서 일회용 암호화 키를 포함한 해당 eUICC(140)들에 대한 소정의 정보들을 OEM/Factory IT 서버(110)에 제공할 수도 있다. 또한, 본 개시의 도면에는 도시되지 않았으나, 일회용 암호화 키를 포함한 해당 eUICC(140)들에 대한 소정의 정보들은 OEM(110)의 요청에 따라 EUM(eUICC Manufacturer)/EUM 서버(160)에서 프로파일 서버/서버 벤더(100)로 전송될 수도 있다.
SP(Service Provider)(150)는 전술한 바와 같이 프로파일을 사용하여 네트워크 서비스를 제공하는 사업자로, SP/SP 서버(150)에서 IFPP 기능을 위한 프로파일(들)을 프로파일 서버/서버 벤더(100)에 주문하여 프로파일 서버(100)에서 주문받은 프로파일들을 생성 및 준비하도록 할 수 있다.
이하, 전술한 구성 모듈들에 대한 설명을 후술할 도면들에서 표기된 모듈들의 역할 및 관계에서도 적용할 수 있다. 또한, 전술한 구성 모듈 중에서 프로파일 서버/서버 벤더(100), Factory IT 서버/OEM(110), EUM/EUM 서버(160), SP/SP 서버(150)간에 주고받는 정보로써 주문 정보들은, 각 Entity의 서버 간 인터페이스 연동 또는 이메일 등 다른 형태로 전달될 수 있다.
도 2는 본 개시의 일 실시예에 따른 대량의 프로파일들을 프로비저닝하는 동작을 설명하기 위한 도면이다.
도 2를 참조하면, 단말을 출고하기에 앞서 단말 제조사는 공장에서 프로파일을 eUICC에 선 탑재하여 출고할 수 있으며 이 경우 1개 이상의 단말들, 특히 대량의 단말들에 프로파일들을 프로비저닝 할 수도 있다. 이 단계는 프로파일들을 준비하여 Factory IT/OEM(215)에 전달하는 단계 (227 단계), 및 Factory IT에서 이를 N개의 서로 다른 eUICC(225)에 설치하는 단계 (270 단계)로 나누어질 수 있다. 도 2의 각 단계에서 주고받은 상세 정보들 및 이에 대한 실시 예들은 후술하는 도 3 내지 6에서 상세히 설명하도록 한다.
227 단계에서, IFPP용 프로파일들을 준비하여 Factory IT/OEM에 전달할 수 있다. eUICC를 탑재한 단말을 제조하고자 하는 단말 제조사는 EUM/EUM 서버(200)를 통해 M개의 eUICC들을 주문할 수 있고, EUM(200)은 주문받은 M개의 eUICC들에 대한 암호화 키 정보들을 포함한 소정의 정보들을 Factory IT/OEM(215)에 제공(230 단계)할 수 있다. 해당 암호화키 정보들을 포함한 소정의 정보들은 도 3에서 후술하는 바와 같이 EUM의 private key 또는 개별 eUICC의 private key로 암호화되어 전송될 수 있다. EUM/EUM 서버(200)는 IFPP용 프로파일들에 대한 주문을 받은 경우, eUICC별로 BPP 복호화에 필요한 eUICC 암호화 키 정보를 포함하여 Factory IT/OEM(215)에 제공할 수 있다. 이를 수신한 Factory IT/OEM(215)는 주문받은 M개의 eUICC들에 대한 암호화 키 정보들을 Factory IT 서버(215)에 저장(235 단계)할 수 있다.
이후 특정 시점에, Factory IT/OEM(215)는 EUM(200)으로부터 주문한 M개의 eUICC들의 일부 N개 또는 전체 eUICC에 프로파일 탑재를 결정할 수 있다. 이는, SP(Service Provider)/SP 서버(205)로부터의 프로파일의 선 탑재 출고 요청에 따른 것일 수 있다.
Factory IT/OEM(215)는 추가적인 선택적인(optional) 절차로 SP/SP 서버(205)에게 EID에 Linked된 프로파일을 사전에 준비할 수 있도록 Profile(들) 개수, EID(들)의 리스트 중 적어도 하나의 정보를 SP/SP서버(205)에게 전달(240 단계)할 수 있다. SP/SP 서버(205)는 프로파일을 프로파일 서버/서버 벤더(210)에 주문(245 단계)할 수 있다. 앞서 SP/SP 서버(205)가 240 단계를 수행하여 EID 리스트를 가지고 있거나 또는 이전 특정 시점에서 EID 리스트를 획득한 경우, SP/SP 서버(205)는 Profile을 주문 시 EID 정보를 포함하여 프로파일 서버/서버 벤더(210)에 요청할 수 있다.
또한, Factory IT/OEM(215)은 SP/SP 서버(205)에게 EID 리스트를 제공하는 240 단계는 260 단계에서 프로파일 서버/서버 벤더(210)가 BPP를 생성하는 절차의 발생 이전의 특정 시점에 발생할 수 있으며, 이를 수신한 SP/SP 서버(205)는 260 단계 이전에 EID 리스트를 프로파일 서버/서버 벤더(210)에 제공할 수 있다. 또는, Factory IT/OEM(215)는 SP/SP 서버(205)를 통하지 않고 (즉, 240 단계를 거치지 않고) EID를 프로파일 서버/서버 벤더(210)에게 260 단계 이전에 직접 전달할 수도 있다. SP/SP 서버(205), 프로파일 서버/서버 벤더(210), 및 Factory IT/OEM(215)는 해당 주문을 특정할 수 있는 정보를 서로 공유(250 단계)할 수 있다. 해당 주문을 특정할 수 있는 정보는 SP/SP 서버(205) 또는 프로파일 서버/서버 벤더(210)가 Factory IT/OEM(215)에게 제공하는 식별 정보로 공유될 수도 있다. 일 예로 식별 정보는, Batch ID, 주문 ID 같은 정보, 주문한 프로파일 리스트 또는 EID 리스트, 프로파일 리스트 또는 EID 리스트들의 시작과 끝 번호에 관한 정보, 공장 일련 번호, 또는 생산자 식별 번호에 관한 정보 중 적어도 하나일 수 있다.
Factory IT/OEM(215)는 230 단계에서 획득한 eUICC들의 키 정보 중에서 SP(Service Provider)(205)가 프로파일을 탑재할 단말들의 숫자인 N개 만큼 해당 대상 단말들의 eUICC에 해당하는 키 정보들을 프로파일 서버/서버 벤더(210)에 전달(255 단계)할 수 있다. 대상 단말들의 eUICC에 해당하는 키 정보들은 전술한 230 단계에서 수신한 키 정보들의 일부 또는 전체일 수 있다. 프로파일 서버/서버 벤더(210)은 245 단계에서 수신한 프로파일 주문 정보, 240 단계에서 수신한 프로파일-EID의 링크 정보, 250 단계에서 상호 공유한 주문 정보, 255 단계에서 수신한 프로파일을 설치할 대상 eUICC들의 암호화 키 정보들을 수집하는 단계 중 적어도 하나 이상의 단계에서 수집한 정보들을 조합하여 프로파일 서버(210)에서 암호화된 프로파일 패키지를 생성한 후 (260 단계) 해당 생성한 프로파일 패키지들과 eUICC binding에 대한 정보를 Factory IT/OEM(215)에 제공(265 단계)할 수 있다. 프로파일 서버(210)는 생성한 암호화된 프로파일 패키지들과 각 BPP 암호화 키 정보들을 하나 이상의 메시지로 Factory IT/제조사(215)에게 전송할 수 있고 해당 메시지로 전송되는 데이터의 일부 또는 전부는 서명된 데이터로 제공될 수도 있다.
270 단계에서, Factory IT(215)에서 IFPP를 위한 프로파일들을 eUICC에 설치하는 동작에 대해서 설명할 수 있다. 이 단계는 N개의 eUICC에 대해서 수행될 수 있다.
Factory IT/OEM(215)는 공장에서 단말을 출고하기 전에 단말에 프로파일을 주입하여 출고할 수 있다. 이를 위해 Factory IT(215)에 BPP와 eUICC에서 프로파일 복호화에 필요한 일련의 암호화 키 정보들을 Factory IT/OEM(215)에서 획득하여 저장할 수 있다. 해당 일련의 암호화 키 정보들은 eUICC의 일회용 공개 키(이하 otPK.eUICC.KA로 표기)를 포함할 수 있다.
Factory IT(215)에 BPP와 eUICC에서 프로파일 복호화에 필요한 일련의 암호화 키 정보들을 공장 내부의 유무선 네트워크를 통해 공장에서 개별 단말(220)들에 전송될 수 있다. BPP와 일련의 암호화 키 정보들은 하나 이상의 메시지에 포함되어 단말(220)에게 전송될 수 있다. otPK.eUICC.KA가 포함되어 전송되는 경우, otPK.eUICC.KA는 프로파일 서버로부터 서명된 데이터에 포함되어 단말(220)에게 수신될 수 있다. 일 예로, 다음 중 하나로 서명된 데이터에 포함되어 수신될 수 있다. 물론 하기의 예시에 제한되지 않는다.
-SK.DPauth.SIG: 프로파일 서버에서 프로파일 서버의 인증을 사용하는 프로파일 서버의 비밀키
- SK.DPpb.SIG: 프로파일 서버에서 프로파일 서버의 프로파일 바인딩을 위해 사용한 개인키
- SK.DPxx.SIG: xx가 IFFP 용도를 의미하도록 정의된 프로파일 서버의 개인키
전술한 바와 같이, SK.DPpb.SIG는 프로파일 서버에서 프로파일 바인딩을 위해 사용하는 프로파일 서버의 비밀키 또는 프로파일 서버가 IFPP 용도를 위해 사용한 프로파일 서버의 비밀 키 일수 있다. DPxx.SIG에서 용도를 나타내는 xx에서 xx가 IFPP 용도 임을 나타내는 특정 정보로 표기될 수 있다.
단말(220)은 Factory IT(215)로부터 BPP(들)을 제공받아 eUICC(225)로 IFPP모드에서 BPP(들)을 주입하는 기능을 제공할 수 있다. 예를 들어, 해당 단말(220)이 BPP를 수신하는 시점에 Factory Provisioning 모드인 상태로 동작하거나 단말(220)은 BPP 수신 시점에서 IFPP로 진입해야 함으로 인지하여 동작을 개시할 수도 있다. 또는, 단말(220)은 공장 직원의 단말에 입력되는 이벤트, 또는 설정 값, 또는 특정 VPN(Virtual Private Network) 임으로 인지 등을 통해서 해당 모드로 진입할 수도 있다. 한편, UI 또는 설정 값으로 IFPP 모드 진입은 일반 환경에서는 사용자에게 표시되지 않도록 제한되는 UI로 제공될 수 있다. 단말(220)은 BPP를 eUICC(225)으로 전달할 수 있는데, 전술한 바와 같이 LPAf(미도시)를 거쳐서 eUICC(225)에 전달하거나 또는 LPAf(미도시)를 거치지 않고 eUICC(225)로 전달할 수 있다 (275 단계).
LPAf(미도시)를 사용하여 eUICC로 전달되는 메시지의 한 예로 ES10x의 하나 이상의 메시지에 포함되어 전송될 수 있다. 이하, 구체적인 실시 예는 도 4 내지 도 6에서 후술하기로 한다.
eUICC(225)가 단말(220)로부터 수신된 메시지는 IFPP를 위한 동작임을 인지할 수 있는 정보를 포함할 수 있다. eUICC(225)가 단말(220)로부터 수신한 메시지에 기반하여 IFPP용으로 프로파일 설치 동작 수행으로 판단하여 진입할 수 있다. IFPP를 위한 동작임을 인지할 수 있는 정보는 IFPP용으로 정의되는 신규 function 이거나 또는 기존 SGP.21/22 내지 SGP. 31/32에서 정의한 ES10x 메시지에 IFPP 구분자 파라미터가 추가되거나, 또는 단말 출고 후 일반 환경에서 (Consumer향, 또는 M2M향 또는 IoT향) 프로파일 프로비저닝을 위해서는 포함되는 않는, 공장 출고용 식별 정보일 수 있다. 일 예로 공장 일련 번호, Batch ID, 생산자 식별 정보와 같은 값 중의 하나일 수 있다. 물론 이에 한정되지 않는다.
전술한 바와 같이, 단말(220)은 프로파일 서버로부터 otpk.eUICC.KA가 포함된 데이터를 수신할 수 있고 해당 otpk.eUICC.KA가 포함된 데이터는 다음 중 하나로 서명된 데이터에 포함되어 수신될 수 있다. 물론 하기의 예시에 제한되지 않는다.
- SK.DPauth.SIG: 프로파일 서버가 프로파일 서버의 인증을 위해 사용한 프로파일 서버의 비밀키
- SK.DPpb.SIG: 프로파일 서버가 프로파일 바인딩을 위해 사용하는 프로파일 서버의 비밀키
- SP.DPifpp.SIG: 프로파일 서버가 IFPP용으로 특정하여 사용한 프로파일 서버의 비밀 키
단말(220)은 서명된 데이터를 다시 eUICC(225)에 LPAf를 거치거나 또는 LPAf를 거치지 않고 eUICC(225)에 전달할 수 있다. eUICC(225)는 eUICC(225)가 수신된 데이터에 대한 프로파일 서버(210)의 서명을 검증하고, 사전에 저장해 둔 eUICC의 일회성 비밀키(otSK.EUICC.KA)를 이용하여 세션 키를 생성하여 BPP를 복호화하여 설치를 처리할 수 있다. (280 단계)
eUICC(225)는 프로파일의 설치 결과를 LPAf 또는 LPAf를 거치지 않고 단말에 전송하여 단말에서 Factory IT 서버(215)에 회신해 줄 수 있다. (285 단계)
Factory IT(215)는 프로파일 설치 결과를 다시 프로파일 서버/서버 벤더(210)에게 회신해 줄 수 있다. Factory IT/OEM(215)은 프로파일 설치 결과들을 개별적으로 프로파일 서버/서버 벤더(210)에 회신할 수도 있고, 프로파일 설치 결과들을 수집했다가 특정 시점에 일괄로 프로파일 서버/서버 벤더(210)에 제공할 수도 있다. 또한, 프로파일 서버/서버 벤더(210) 또는 Factory IT/OEM(215)은 프로파일 설치 결과(들)을 SP/SP 서버(205)에 선택적으로 제공할 수도 있다.
도 3은 본 개시의 일 실시 예에 따른 대량의 프로파일을 프로비저닝하기 위해 프로파일을 준비하는 동작을 설명하기 위한 도면이다. 도 3은 도 2의 227 단계에 대한 절차를 구체적으로 도시한 도면이다. 또한 후술한 바와 같이 도 3은 도 4 내지 도 6의 절차를 수행하기 전에 Factory IT/OEM에 BPP를 준비하는 일 예이며, 도 4 내지 도 6의 절차를 수행하기 전에 도 3의 절차에 한정하여 BPP를 획득해야 하는 것은 아니다.
도 3을 참조하면, eUICC를 탑재하고자 하는 Factory IT/OEM(315)는 EUM/EUM 서버(300)에게 eUICC들을 주문할 수 있고, EUM(300)은 eUICC에서 사용하는 otSK/PK. EUICC.KA 쌍을 미리 만들어서, Factory IT/OEM(315)에게 otSK.EUICC.KA가 탑재된 eUICC 납품 시에 eUICC별로 otPK.EUICC.KA, [eUICC Info], [EID], eUICC 또는 EUM의 비밀키로 서명된 otPK.EUICC.KA가 포함된 데이터 (도 3의 330 단계에서는 Signed (otOK.EUICC.KA, [eUICC Info])로 표기), eUICC Signature, eUICC의 인증서(CERT.EUICC.SIG) 및 인증서 체인, EID, 또는 PK.EUICC.SIG 중 적어도 하나를 포함하여 전달할 수 있다. EMU(300)에서 Factory IT/OEM(315)으로 전달되는 정보는 EUM의 서명된 데이터로 전송되거나 서명되지 않은 데이터로 전송될 수도 있다. 만약에 EUM 서명된 데이터로 전송되는 경우, EUM의 서명 값(eumSignature) 및 EUM 인증서 내지 EUM의 공개키(PK.EUM.SIG)가 더 포함되어 전송되는 것도 가능할 수 있다. 또한 해당 전송되는 정보 중에서 해당 eUICCs 주문에 공통으로 적용되는 정보들(일 예로 eUICC Info)는 eUICC별 중복 포함되지 않고 전송되는 것도 가능할 수 있다. (330 단계) 위에 언급한 바와 같이 otPK.EUICC.KA는 EUM의 비밀키로 서명되어 전송될 수도 있다. otPK.EUICC.KA가 EUM의 비밀키로 서명되어 전송되는 경우, eUICC의 서명 값 및/또는 eUICC별 인증서를 포함하지 않고 전송될 수 있다.
전송되는 정보들은 프로파일 서버에서 Factory IT(315)와 연동된 interface를 통해서 전달 또는 다른 온/오프라인 방법을 통해 전달될 수 있다. 각 전송되는 정보는 다음을 나타낼 수 있다. 물론 하기의 예시에 제한되지 않는다.
- otPK.EUICC.KA: eUICC의 일회성 공개키로, 프로파일 서버와 eUICC간 세션 키 생성에 사용되는 공개키
- SK(Data including otPK.EUICC.KA): eUICC의 비밀키로 서명된 otPK.EUICC.KA를 포함하는 데이터로, 하기 데이터 포맷의 예시에서는 euiccSignature로 표시
- CERT.EUICC.SIG과 인증서 체인: eUICC 인증서 및 eUICC 인증서 검증을 위한 인증서들의 체인을 의미한다.
- CERT.EUICC.SIG는 eUICC의 고유 식별 번호인 EID와 eUICC 서명을 복호화하기 위한 공개 키(PK.EUICC.SIG)를 포함. eUICC가 EUM으로부터 인증된 것인지를 증명하는 데에도 사용된다.
- CERT.EUICC.SIG의 상위 인증서 체인에는 EUM 공개 키를 포함하는 인증서인 CERT.EUM.SIG가 포함될 수 있다.
- eUICC Info: eUICC Capability에 대한 정보로, IFPP를 지원하는 eUICC인지를 나타내는 capability에 대한 indication이 포함되거나 포함되어 있지 않을 수 있다. 특정 주문 건에 대해서 동일한 eUICC Capability를 가지는 경우 eUICC Info는 eUICC별이 아닌 주문 건에 대해 전송될 수도 있다.
- EID: eUICC별 할당되는 고유 식별 번호
- PK.EUICC.SIG: eUICC 서명을 복호화하기 위한 eUICC의 공개키로, CERT.EUICC.SIG에 포함되는 값으로 전송되거나 CERT.EUICC.SIG에 포함되지 않고 전송되는 경우에 별도 파라미터로 전송될 수 있다.
전달되는 데이터 형식의 일 예로 다음과 같이 표 1의 형식일 수 있다.
Figure PCTKR2023011123-appb-img-000001
해당 정보를 수신한 Factory IT/OEM(315)은 해당 정보들을 저장하여 가지고 있다가 특정 시점에, Factory IT/OEM(315)는 EUM(300)으로부터 주문한 M개의 eUICC들의 일부인 N개 또는 전체 eUICC에 프로파일 탑재를 결정하거나 또는 SP가 Factory IT/OEM(315)에 해당 프로파일들을 출고할 단말(320)들에 선 탑재를 요청할 수 있다.
Factory IT/OEM(315)는 선택적인(optional) 절차로 SP/SP 서버(305)에게 EID에 Linked된 프로파일을 사전에 준비할 수 있도록 프로파일 개수 및 EID(들)의 정보 중의 적어도 하나를 포함하여 SP/SP 서버(305)에게 전달할 수 있다. (333 단계)
SP/SP 서버(305)는 프로파일을 프로파일 서버/서버 벤더(310)에 주문할 수 있다. (335 단계)
SP/SP 서버(305)가 333 단계 또는 이전의 특정 시점에서 EID 리스트들을 획득하여 가지고 있는 경우에, SP/SP 서버(305)는 Profile을 주문하면서 EID 정보를 포함하여 프로파일 서버/서버 벤더(310)에 주문을 넣을 수도 있다. 프로파일 주문 메시지는 신규 function 또는 기존 GSMA RSP에서 정의한 Service Provider-프로파일 서버간 ES2+ 주문 interface에 IFPP 주문 식별 정보를 더 포함한 형태로 정의될 수도 있다. 주문 메시지에 포함되는 정보는, 적어도 다음 중 하나를 포함할 수 있다. 물론 하기의 정보에 제한되지 않는다. Batch ID는 그룹의 프로파일 주문을 식별하기 위한 ID이므로 Profile Order ID, Bundle Order ID등의 다른 용어로 대체 사용될 수 있다.
- 주문 프로파일들의 묶음을 나타내는 Batch ID
- Batch ID별 할당된 프로파일의 개수 또는 ICCID Lists
- 주문 프로파일(들)의 개수
- ICCID(s)
- 프로파일이 Linked가 필요한 EID(s)
- SP (Service Provider) ID
- 주문 프로파일들을 준비할 프로파일 서버 주소 (예로 FQDN 타입의 주소)
- IFPP 주문 식별자 (IFPP indication)
- 생성한 BPP를 전달할 Factory IT 일련 번호
- 생성한 BPP를 전달할 OEM 식별 번호 (생산자 번호)
IFPP 주문 식별자로 IFPP indication, 또는 Batch ID는 ES2+ 주문 interface의 Profile Type 데이터의 값의 하나에 포함되어 전송될 수도 있다.
프로파일 서버(310)는 IFPP만을 지원하는 프로파일 서버일 수도 있으나, IFPP를 프로파일 서버의 기능 중의 하나로 지원하는 프로파일 서버일 수도 있다. 예를 들어, 프로파일 서버(310)는 GSMA에서 정의한 SGP.21/22 (스마트폰 등 Consumer 단말에 프로파일 프로비저닝을 위한 규격) 또는 SGP.31/32 (IoT 특화 단말에 프로파일 프로비저닝을 위한 규격)을 지원하는 프로파일 서버로 공장에서의 프로파일 프로비저닝을 위한 기능을 추가적으로 지원하는 서버일 수 있다. 해당 프로파일 다운로드 주문을 수신한 프로파일 서버(310)는 IFPPOrder로 정의된 신규 Function 또는 기존 ES2+.DownloadOrder의 신규 파라미터로 IFPP 판단 정보가 있는지를 판단하여 해당 주문이 IFPP용으로 프로파일 준비임을 인지하여 관리할 수 있다. 이는 일 예로 전술한 IFPP 주문 식별자 또는 Batch ID 일 수 있다. 한편, 앞서 335 단계에서 EID가 함께 수신되지 않은 경우에는, 프로파일 서버(310)가 해당 Profile을 할당 단계 (allocated)로 상태를 변경하여 처리해 둘 수 있으며, EID가 335 단계에서 함께 수신된 경우에 EID를 ICCID와 연결하여 Profile의 상태를 링크된 단계(Linked)로 변경하여 준비해 둘 수도 있다.
SP/SP 서버(305) 내지 프로파일 서버/서버 벤더(310)는 Factory IT/OEM(315)에게 해당 주문을 특정할 수 있는 정보를 공유할 수 있다. (340 단계)
SP/SP 서버(305) 내지 프로파일 서버/서버 벤더(310)는 Factory IT/제조사(315)가 공통으로 동일 주문에 대한 건인지 인지할 수 있는 정보일 수 있다. 즉, 추후 프로파일 서버(310)가 프로파일 다운로드 요청을 수신할 수 있다. (345 단계) 프로파일 서버(310)가 프로파일 다운로드 요청을 수신 시, 이전에 SP로부터 요청받아 준비한 프로파일들과 맵핑(mapping)할 수 있도록 해야 하며, 이를 위해서 SP-Factory IT-프로파일 서버 간 주문 정보를 공유할 수 있다. 일 예로, 공유할 수 있는 주문 정보는, Batch ID, 프로파일을 저장한 서버의 주소, 프로파일 생성을 요청한 서비스 사업자 식별 정보, 주문한 프로파일 리스트 또는 EID 리스트의 시작과 끝 번호와 같은 정보, 또는 주문한 프로파일 리스트, EID 리스트, Factory IT 식별 번호 중 적어도 하나일 수 있다.
345 단계에서, Factory IT/OEM(315)는 공장에서 단말을 출고하기 전에 단말에 프로파일을 주입하여 출고하고자 할 수 있다. 이를 위해 Factory IT/OEM(315)는 프로파일 서버(310)에 IFPP용으로 준비된 BPP를 요청할 수 있다.
Factory IT(315)에서 프로파일 서버(310)로 IFPP 요청임을 표시(indication)하는 방법은 IFPP을 위한 BPP 요청임을 나타내는 신규 Function으로 메시지를 전송, ES9+. Function에 IFPP 식별 indication를 전송, 또는 해당 IFPP에서만 요구되는 파라미터(일 예로 otPK.eUICC.KA, Batch ID, 또는 SP ID 중 적어도 하나 이상의 정보)가 포함되어 전송되는 경우 중 적어도 하나로 프로파일 서버(310)가 판단할 수 있다. 전술한 ES9+. Function의 일 예로, ES9+. GetBoundProfilePackage과 같은 메시지일 수 있다. 한편, IFPP용 BPP 요청 또는 해당 BPP 생성 요청에 수반되는 일련의 후속 메시지들의 데이터의 하나에, Factory IT/OEM(315)는 330 단계에서 획득한 eUICC들의 Key 정보 중에서 SP(Service Provider)(305)가 프로파일을 탑재할 단말들의 숫자만큼 해당 대상 단말들의 eUICC에 해당하는 otPK.EUICC.KA를 포함된 Key 정보들을 프로파일 서버/서버 벤더(310)에 전달할 수도 있다. 또한, Factory IT/OEM(315)에서 프로파일 서버/서버 벤더(310)로 전송되는 해당 BPP 생성 요청에 수반되는 일련의 후속 메시지들의 데이터의 하나에 BPP 생성을 위해 제공되는 추가 정보로써 단말의 capability로 device info 내지 eUICC capability 정보로 eUICC info를 선택적으로 포함하여 전송할 수도 있다.
프로파일 서버/서버 벤더(310)가 Factory IT(315)로부터 IFPP용 BPP 요청임을 판단할 수 있는 메시지를 수신하고, otPK.eUICC.KA에 대한 키 정보를 수신한 경우에, 프로파일 서버/서버 벤더(310)는 IFPP를 위한 BPP 준비로 판단하여 프로파일 서버(310)는 IFPP용 BPP를 생성 단계를 수행할 수 있다. (350 단계) 프로파일 서버(310)는 IFPP 모드에서 암호화된 프로파일 패키지인 BPP를 생성하는 절차로 진입할 수 있다. 프로파일 서버(310)가 IFPP용으로 BPP 생성에 대한 판단하는 경우는 Factory IT(315)로부터 수신되는 메시지에 이를 인지할 수 있는 정보(일 예로, IFPP용으로 정의된 신규 function, 기존 ES9+ 메시지에 공장에서의 프로파일 다운로드 요청임을 인지할 수 있는 신규 IFPP indication, 또는 신규 파라미터(암호화 Key 정보 등) 중 적어도 하나를 포함하는 정보)를 수신하는 경우일 수 있다. 프로파일 서버/서버 벤더(310)가 IFPP용 BPP를 생성해야 함으로 판단하면, 프로파일 서버(310)는 다음의 절차 중 하나 이상의 절차를 포함하여 IFPP용으로 BPP를 생성할 수 있다. 물론 하기의 예시에 제한되지 않는다.
- Profile Eligibility Check
- 프로파일 다운로드를 수행하기 전에, 프로파일 서버(310)가 SP에서 ES2+ 주문 Interface를 통해 수신한 프로파일 타입이 타겟이 되는 단말/EID에 설치가 적합한지 확인하는 절차로 선택적으로 수행될 수 있다. 335 단계 내지 345 단계를 통해서 EID, eUICC Info, Device Info 중 적어도 하나 이상의 정보가 수신되는 경우, 335 단계에서 수신되는 프로파일 주문, 특히 주문에서 명시한 프로파일 타입을 설치할 수 있는지 여부를 선택적으로(Optionally) 수행할 수 있다. 이에 따라, 프로파일 서버(310)는 IFPP용 프로파일의 설치가 가능한 EID/단말인지 여부를 포함하여 자격 검증을 하거나 하지 않을 수 있다.
- eUICC의 인증서인 CERT.EUICC.SIG 검증
: 프로파일 서버(310)가 345 단계에서 CERT.EUICC.SIG를 수신한 경우 검증을 수행할 수 있다. 프로파일 서버(310)는 EUM의 인증서를 가지고 345 단계에서 수신된 CERT.EUICC.SIG를 검증할 수 있다. CERT.EUICC.SIG는 EID를 포함할 수 있는데, EID는 EUM 인증서 안의 EINs의 하나를 포함하는 일련의 번호로 구성될 수 있다. 프로파일 서버는 CERT.EUICC.SIG에 포함된 EID와 EUM 인증서인 CERT.EUM.SIG에 포함된 허용된 EINs (EUM 식별 IDs)의 값 중의 하나가 매칭 되는 지를 확인하여 CERT.EUICC.SIG가 적법한 eUICC인지를 인증할 수 있다.
- eUICC의 서명을 검증
: 프로파일 서버(310)는 otPK.EUICC.KA가 포함된 데이터의 서명에 사용한 eUICC의 비밀키를 CERT.EUICC.SIG에 포함된 eUICC의 공개키를 가지고 복호화할 수 있다. 본 개시의 일 실시예에 따르면, 345 단계에서 수신된 otPK.EUICC.KA가 포함된 데이터가 EUM의 비밀키로 서명되어 수신되었다면, 프로파일 서버는 CERT.EUM.SIG에 포함된 EUM의 공개키를 가지고 복호화를 수행할 수 있다.
- otSK/PK.DP.KA
: 프로파일 서버의 일회용 비밀키와 공개키 쌍을 생성할 수 있다.
- otSK.DP.KA와 otPK.EUICC.KA를 가지고 Session Key 생성
: 프로파일 서버(310)는 otSK.DP.KA와 otPK.EUICC.KA를 사용하여 특정 프로파일 전송 세션에 사용할 공유된 비밀 값(shared secret value)을 생성할 수 있다.
- ServerChallenge
: 345 단계 내지 345 단계의 전 단계에서 Factory IT/OEM(315)에서 프로파일 서버(310)에 해당 정보를 포함하여 전송을 요구하는 경우, 프로파일 서버(310)가 생성할 수 있다.
- eUICC(325)가 프로파일 서버(310)와 eUICC(325)간 상호 인증 절차에서 프로파일 서버(310)가 eUICC(325)로 보내는 Server Challenge 값을 그대로 보낼 수 있도록 설계된 경우 제공할 수 있다.
- BPP (Bound Profile Package)
: 세션 키, 키 교체 패키지, ISD-P 생성 및 구성 정보가 포함하여 EID와 바인딩한 프로파일 패키지를 생성할 수 있다.
350 단계에서 프로파일 서버(310)가 IFPP를 위한 BPP를 성공적으로 생성하면, 프로파일 서버/서버 벤더(310)는 BPP와 BPP설치에 필요한 일련의 정보들을 Factory IT/OEM(315)에게 하나 이상의 메시지들을 통해 전송할 수 있다. (355 단계) 만약 앞서 BPP를 요청하는 시점에서 Factory IT(315)가 프로파일 서버(310)에 Push 서비스를 등록한 경우에, 해당 BPP와 BPP설치에 필요한 일련의 정보들은 350 단계에서, 프로파일 서버(310)가 이를 준비한 시점에서 푸시 메시지에 포함하여 전송하거나 프로파일 서버(310)가 푸시 메시지로 프로파일이 준비되었음을 알리고 이에 대해 Factory IT(315)가 프로파일 서버(310)로 접속하여 획득하는 절차로 진행될 수도 있다.
프로파일서버/서버 벤더(310)는 Factory IT/OEM(315)으로 생성한 BPP 및 맵핑된 eUICC에서 BPP 검증을 위해 요구되는 일련의 프로파일 서버의 암호화 키 정보리스트들을 하나이상의 메시지를 통해서 전송할 수 있다. 해당 암호화 키 정보, 일 예로 프로파일 서버의 공개키(예를 들어, PK.DPxx.SIG)들은 인증서에 포함되어 전달되거나 인증서에 포함하지 않고 전달될 수 있다. 또한, 프로파일서버/서버 벤더(310)에서 전송하는 정보는 주문 식별 정보, 일 예로 Service Provider ID 또는 Batch ID 또는 주문 ID와 같은 정보가 포함할 수도 있다. 프로파일 서버/서버 벤더(310)에서 전송하는 정보의 일 예로 ESbpp.BulkProfileResponse ([SP ID], ([Batch ID], (BPP including otPK.DP.KA, [CERT.EUICC.SIG], [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EIUCC.KA]) X N, SM-DPf Certificate Chains)와 같은 메시지일 수 있다.
프로파일 서버/서버 벤더(310)에서 전송하는 정보의 다른 일 예는 ESbpp.GetBoundProfilePackageforIfpp response (batchOrderId, ([EID], BPP including otPK.DP.KA, CERT.DPpb.SIG, eUICC Signature, [otPK.EUICC.KA])X N, Device Info, eUICC Info, SM-DPf Certificate Chains)와 같은 메시지일 수 있다.
355단계에서, otPK.EUICC.KA는 포함되어 전송될 수도 있으며, 만약 포함되어 전송되는 경우에 있어서 서명된 정보로 전송될 수 있다. otPK.EUICC.KA는 BPP에 포함된 ES8+의 하나에 포함되어 전송되거나 또는 BPP에 포함되지 않고 전송될 수도 있다.
355 단계에서 전달되는 정보들은 하나의 메시지 또는 한 개 이상의 메시지로 구성되어 Factory IT/OEM(315)에 전달되어 Factory IT(315)에 저장될 수도 있다.
Factory IT(315)는 수신된 BPP, BPP별로 맵핑된 EID와 해당 EID에 BPP를 다운로드 설치하기 위한 암호화 키 정보들을 맵핑하여 저장해 두었다가, 프로파일의 프로비저닝을 수행할 수 있다. (360 단계) 해당 절차는 Factory IT(315)가 단말(320)에 BPP 및 해당 EID에 BPP를 다운로드 설치하기 위한 암호화 키 정보들을 전송해 주어, 해당 단말(320)이 eUICC(325)에 BPP와 다운로드 설치를 위한 암호화 키 정보들을 전달하여 eUICC(325)가 전달된 BPP 및 이를 설치하기 위한 암호화 키를 검증하고 프로파일 설치하는 절차를 포함하여 수행될 수 있다.
단말(320)에서 eUICC(325)로 BPP 설치 절차는 LPAf(미도시)를 거쳐서 eUICC(325)에 전달 또는 LPAf를 거치지 않고 eUICC(325)로 전달할 수 있다. LPAf를 사용하여 eUICC로 전달되는 메시지의 한 예로 ES10x의 하나 이상의 메시지에 포함되어 전송할 수 있다. 또한, 단말에서 전송 방법은 다음 중의 하나의 방법일 수 있다. 물론, 하기의 방법에 제한되지 않는다.
- 기존 SGP.22의 서버와 eUICC간 인증 절차, Profile 설치를 위한 사전 정보 공유 절차, 및 BPP 설치 절차의 3 단계를 재활용하여 처리하는 방법
- 전술한 SGP.22의 3 단계의 절차에서, 서버와 eUICC간 인증 절차, 및 BPP 설치 절차를 재활용하는 2 단계로 처리하는 방법
- 1 단계로 이루어진 신규 Function을 정의하여 BPP 및 BBP와 관련된 Key 정보를 단말(320)에서 일괄적으로 eUICC(325)에 전달하는 방법
이하, BPP Installation에 관한 절차는 도 4 내지 도 6에서 상세하게 후술하기로 한다.
도 4는 본 개시의 일 실시 예에 따른 도 2에서의 프로파일을 Factory IT에서 eUICC로 설치하는 동작을 설명하기 위한 도면이다. 도 4 내지 도 6의 프로파일을 준비하는 절차(430 단계, 530 단계, 630 단계)는 도 3의 준비 절차로 수행하거나 도 2에서 후술할 준비 절차로 수행될 수 있으나, 이에 한정하지 않는다. 즉, 도 2 내지 도 3의 방법을 따라 수행하지 않더라도 프로파일 서버가 BPP와 암호화 키를 생성하여 준비해 둔 경우에, 도 4 내지 도 6과 같이 이후 프로파일 설치 절차를 처리할 수도 있다. 도 4는 전술한 SGP.22의 3 단계의 절차를 재활용하여 처리하는 방법으로 서버와 eUICC간 인증 절차, Profile 설치를 위한 사전 정보 공유 절차, 및 BPP 설치 절차를 모두 수행하여 처리하는 방법에 대해 기술한다.
도 4를 참조하면, IFPP용 BPP가 준비되면, Factory IT(415)는 N개 묶음의 eUICC에 맵핑되는 해당 BPP와 관련된 Key 정보들을 획득하여 이를 저장할 수 있다. Factory IT(415)는 해당 BPP와 관련된 Key 정보들을 공장에서 단말을 출고하기 전 특정 시점에 단말에 설정 값들을 프로비저닝 하는 과정에서 맵핑되는 단말(420)에 전송할 수 있다. (435 단계) Factory IT(415)는 공장에서 프로파일을 프로비저닝하기 위한 처리를 하는 과정에서 단말 ID 및/또는 EID를 확인할 수 있고, 이에 맵핑된 BPP와 관련된 암호화 Key 정보들을 골라서 해당 단말(420)에 전송하거나 또는 단말의 요청 메시지를 수신하여 이에 대한 회신 메시지로 전송할 수 있다.
435 단계에서 단말(420)에 전달되는 정보는 BPP(including otPK.DP.KA)와 암호화 키 정보로써 [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], [dpSignature1], 또는 dpSignature2 중 적어도 하나를 포함하여 전달될 수 있다. 물론 하기의 설명에 제한되지 않는다.
- CERT.DPauth.SIG: 프로파일서버 자체의 인증에 사용되는 프로파일서버 인증서. 프로파일 서버가 프로파일서버의 인증을 위해 사용한 서명 값의 검증을 위해 필요한 공개키인 PK.DPpb.SIG를 포함할 수 있다.
- CERT.DPpb.SIG: 프로파일서버 인증서로 프로파일과 eUICC간 바인딩에 사용한 프로파일 서버의 서명 값을 검증하는데 필요한 공개키인 PK.DPpb.SIG를 포함할 수 있다.
- otPK.DP.KA: eUICC가 프로파일 서버와의 프로파일 다운로드 및 전송 세션에 사용하는 공유된 비밀 값(shared secret value) 생성에 사용될 수 있다.
- ServerChallenge: 프로파일 서버 인증을 위한 데이터에 포함되어, 프로파일 서버 인증에 사용한 프로파일 서버의 비밀키(SK.DPauth.SIG)로 서명된 데이터 형태로 제공될 수도 있다.
- otPK.EUICC.KA: 프로파일 서버 인증을 위한 데이터에 포함되거나, 또는 프로파일 바인딩을 위한 데이터에 포함되어 전송될 수 있으며, 해당 정보를 포함하여 프로파일 서버가 서명한 데이터로써(예를 들어 dpSignature1 또는 dpSignature2의 하나에 포함되어) 전송될 수도 있다. otPK.EUICC.KA는 전송되지 않을 수도 있다.
- dpSignature1: CERT.DPauth.SIG에 포함된 공개키에 대응되는 프로파일 서버의 비밀키(SK.DPauth.SIG)로 서명한 데이터를 나타낼 수 있다.
- dpSignature2: CERT.DPpb.SIG에 포함된 공개키에 대응되는 프로파일 서버의 비밀키(SK.DPpb.SIG)로 서명한 데이터를 나타낼 수 있다.
단말(420)은 IFPP 모드의 진입(440 단계)은 IFPP용으로 프로파일의 다운로드를 위한 function이 수신되거나, 프로파일 프로비저닝을 하는 시점에서의 단말(420)설정이 공장 프로비저닝/설정 등의 상태로 진입되어 있거나, 또는 공장 환경에서의 사용자의 프로파일 프로비저닝을 위한 메뉴 선택으로 진입되는 경우 중 적어도 하나일 수 있다.
단말(420)이 이미 공장에서의 프로파일의 프로비저닝/프로비저닝 설정 등의 상태로 설정되어 있는 경우에, 단말은 IFPP용으로 프로파일 다운로드를 위한 신규 function이 수신되기 전에 이미 IFPP 모드로 프로파일 다운로드 절차를 수행해야 함을 인지하고 해당 모드로 바로 진입이 가능할 수 있다. 예를 들어, 공장 설정 상태에서 LPA에 진입 시 IFPP로 프로파일 설정 모드로 자동 진입할 수도 있다. 이에 따라 IFPP 모드의 진입(440 단계)은 신규 function, 일 예로 435 단계에서 단말(420)이 수신한 ESfac.prepareFactoryDownload (including BPP(including otPK.DP.KA), [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], [dpSignature1], dpSignature2)와 같은 function을 수신하기 이전에 설정될 수 있다. [CERT.DPauth.SIG], CERT.DPpb.SIG에 인증서 체인이 더 있는 경우, 해당 인증서 체인들이 더 포함되어 전송될 수도 있다. 즉, 435 단계에서 추가 인증서 체인 정보가 더 포함되어 전송되고, 이후 추가 인증서 체인 정보는 445 단계 또는 460 단계 또는 475 단계 중 적어도 하나의 단계에 포함되어 eUICC(525)에 전송될 수 있다. 전술한 435 단계에서, IFPP용 프로파일의 다운로드 절차의 수행을 요청하는 메시지를 수신한 단말(420)과 eUICC(425)는 기존의 SGP.22에서 정의한 단말 출고 후의 프로파일 설치 과정을 재활용하여 프로파일 설치를 수행할 수 있다.
현재 SGP.22에서는 프로파일 설치 과정에서의 상호 인증 과정을 수행해야 하는데, 해당 상호 인증 과정에서 eUICC, 프로파일 서버가 랜덤 값을 생성하여 해당 전달한 랜덤 값이 서명된 값을 검증하여 상호 인증을 하게 된다. 예를 들어, eUICC는 랜덤 값으로 eUICC Challenge 값을 생성하여 이를 포함한 데이터를 프로파일 서버에 전송하게 되면 프로파일 서버가 eUICC Challenge를 프로파일 서버의 비밀키로 서명한 다음에 eUICC에 회신하면 eUICC가 프로파일 서버의 비밀키로 서명된 값을 프로파일 서버의 공개 키로 검증하여 프로파일 서버가 전송한 데이터에 포함된 eUICC Challenge값이 앞서 eUICC가 생성하여 보낸 값과 같은지 여부를 판단하여 프로파일 서버를 인증할 수 있다. 마찬 가지로, 프로파일 서버도 Server Challenge 값을 생성하여 eUICC에게 전송하고 eUICC는 해당 값을 포함한 데이터를 eUICC가 서명하여 회신하면, eUICC의 비밀키로 서명된 값을 eUICC의 공개 키로 검증하여 eUICC가 전송한 데이터에 포함된 Server Challenge값이 앞서 프로파일 서버가 생성하여 보낸 값과 같은지를 판단하여 eUICC를 인증할 수 있다.
공장에서 프로파일을 프로비저닝하는 과정에서 프로파일 서버(410)와 eUICC(425)간 상호 인증을 위한 eUICC Challenge 값과 Server Challenge 값을 실시간으로 생성하여 전달할 수 없기 때문에 해당 값들은 미리 사전에 생성된 정보로써 전달될 수 있다. 예를 들어, 프로파일 서버가 eUICC로 회신하는 eUICC Challenge은 eUICC가 앞서 도 2 내지 도 3의 프로파일 주문/생성 단계에서 프로파일 서버가 획득한 eUICC 사전 생성한 랜덤 값일 수 있다. 이는 일 예로 otPK.EUICC.KA 값일 수 있다.
한편, 공장에서 프로파일을 프로비저닝하는 과정에서 eUICC가 Server Challenge를 포함한 eUICC의 서명 데이터를 프로파일 서버에 회신하여 해당 데이터를 프로파일 서버가 검증하는 방법으로써, 프로파일 서버가 eUICC 인증을 수행할 수 없을 수도 있다. 따라서, eUICC(425)가 프로파일 서버(410)는 인증하되, 프로파일 서버(410)는 eUICC(425)를 프로파일 다운로드를 수행하는 과정 중에 인증하지 않을 수도 있다. 일 예로, 프로파일 서버는 프로파일 다운로드를 수행하는 과정 중에 인증하지 않고, 프로파일 서버(410)는 앞서 프로파일을 준비하는 단계(예를 들어, 도 3의 350 단계)에서 eUICC가 서명하여 전달한 otPK.EUICC.KA를 검증한 다음에 BPP를 생성함으로써 eUICC(425)를 사전에 인증할 수 있다.
한편, 프로파일 서버(410)는 SGP.22의 상호 인증 과정을 모사하기 위해 선택적으로 기존 ES10x 절차에서 프로파일 서버(410)가 eUICC(425)에 전송하는 Server Challenge 값을 서버가 서명한 데이터에 포함하여 Factory IT(415)에 제공할 수 있다. 프로파일 서버(410)로부터 eUICC(425)에 전송하는 Server Challenge 값을 서버가 서명한 데이터를 수신한 Factory IT(415)가 해당 정보를 단말(420)에 전송하여, 단말(420)로 하여금 eUICC(425)에 전달할 수도 있다. Server Challenge는 프로파일 서버(410)가 BPP 생성 요청을 수신 또는 그 이전 시점에 생성해 두었다가 제공해 줄 수도 있다.
단말(420)의 LPAf(미도시)는 IFPP로 진입하여 eUICC(425)에게 서버 인증 정보로 eUICC Challenge가 포함된 데이터를 전송해 줄 수도 있다. 해당 데이터는 서버가 서명한 데이터 형태로 전송될 수도 있다. (445 단계) 일 예로, ES10b.AuthenticateServer (Data1(Including otPK.EUICC.KA), dpSignature1, CERT.DPauth.SIG)와 같은 메시지 일 수 있다. dpSignature1은 Data1을 프로파일 서버(410)의 비밀 키로 서명한 값일 수 있다. 해당 메시지를 수신한 eUICC(425)는 프로파일 서버(410)를 검증할 수 있으며(450 단계), otPK.EUICC.KA는 eUICC Challenge 및 프로파일 서버의 서명 검증에 사용될 수 있다. 450 단계에서, eUICC(425)에서 프로파일 서버(410)를 인증하는 검증 절차는 다음의 절차 중 하나를 포함하여 수행될 수 있다. 물론 하기의 절차에 제한되지 않는다.
- eUICC(425)는 프로파일 서버의 서명을 검증: 수신된 프로파일 서버의 인증서에 포함 또는 포함되지 않은 공개 키(예를 들어, PK.DP.SIG)를 가지고 dpSignature1를 복호화한 값과 Data1(Including otPK.EUICC.KA)의 값과 비교하여 동일 값을 가지는 지 여부로 하여 검증.
- CERT.DPauth.SIG Certificate chain 검증: CERT.DPauth.SIG 인증 체인과 eUICC의 인증 체인이 동일 인증 체인에 있는 지 여부로 검증
- CERT.DPauth.SIG에서 프로파일 서버의 공개 키를 추출
eUICC(425)는 프로파일 서버(410)의 인증서 및 서명을 검증하면 해당 결과를 단말(420)의 LPAf에 회신해 줄 수 있다. (455 단계) eUICC(425)는 프로파일 서버(410)의 인증서 및 서명을 검증에 실패하는 경우에 에러 메시지를 단말(420)에 회신해 주어(455 단계), 에러 메시지를 회신한 단말(420)은 프로파일 설치 동작을 종료하고 에러 결과를 Factory IT(415)에 회신할 수 있다. (485 단계)
단말(420)의 LPAf가 455 단계에서 회신한 메시지를 통해 프로파일 서버(410)의 인증 절차를 성공적으로 수행함을 확인하게 되면 프로파일 다운로드에 필요한 준비 정보를 단말(420)의 LPAf가 eUICC(425)로 전송해 줄 수 있다. (460 단계)
한편, 전술한 445 내지 455 단계는 선택적으로 수행될 수 있다. 예를 들어, CERT.DPauth.SIG를 사용하는 인증 절차를 수행하지 않고 440 단계에서 460 단계로 진입하여 이후 단계들을 처리할 수도 있다. 이는 435 단계에서 수신되는 메시지에 CERT.DPauth.SIG이 포함되지 않고 수신되는 경우일 수 있다.
한편, CERT.DPauth.SIG가 수신되지 않는 경우 CERT.DPpb.SIG는 프로파일 바인딩과 더불어 프로파일 서버의 인증을 위한 용도를 포함하여 사용될 수 있다.
445 내지 455 단계가 수행되었다면, eUICC(425)는 445 단계를 RSP session 생성 시점으로 판단하여 동작할 수 있다. 앞서, 445 내지 455 단계를 수행하지 않은 eUICC(425)은 465단계에서 메시지를 수신한 시점을 RSP session 생성 시점으로 판단하여 동작할 수 있다. 이 경우 만약, eUICC(425)가 해당 메시지를 수신하기 이전에 이미 생성된 RSP session을 가지고 있었다면 eUICC(425)는 이전 생성된 RSP Session을 삭제하고 이전에 RSP session에서 (프로파일 설치를 완료하지 않았으므로) 최종 사용하지 않은 otPK.EUICC.KA 및 otSK.EUICC.KA를 삭제하지 않고 저장한 다음, 새로운 RSP session을 시작할 수 있다.
전술한 460 단계에서 전송되는 메시지는 otPK.EUICC.KA를 포함하는 Data2, 해당 데이터를 서명한 값인 dpSignature2, 또는 CERT.DPpb.SIG 중 적어도 하나를 포함하는 메시지일 수 있다. 일 예로, ES10b. PrepareDownload for IFPP와 같은 신규 IFPP용 function으로 정의될 수도 있다 otPK.EUICC.KA는 데이터2의 bppeUICCOtpk에 해당하는 값으로 전송되는 것도 가능할 수도 있다.
해당 메시지를 수신한 eUICC(425)는 프로파일 다운로드를 준비를 위한 검증 절차를 수행할 수 있다 (465 단계). 465 단계에서, eUICC(425)의 동작은 적어도 하나 이상의 다음 절차를 포함하여 수행될 수 있다. 물론 하기의 절차에 제한되지 않는다.
- CERT.DPpb.SIG Certificate chain 검증: CERT.DPpb.SIG 인증 체인과 eUICC의 인증 체인이 동일 인증 체인에 있는 지로 검증
- 프로파일 서버의 서명을 검증: CERT.DPpb.SIG에서 추출한 프로파일 서버의 공개 키를 가지고 dpSignature2를 복호화한 값을 Data2(Including otPK.EUICC.KA)의 값과 비교하여 동일 값을 가지는 지 확인
- CERT.DPauth.SIG와 CERT.DPpb.SIG가 같은 owner ID를 가지고 있는지 확인 (다만, 해당 절차는 앞서 445 단계에서 455 단계가 수행되지 않은 경우, 수행되지 않을 수 있다.)
- CERT.DPpb.SIG에서 프로파일 서버의 공개 키를 추출
- 수신된 otPK.EUICC.KA에 대응되는 otSK.EUICC.KA가 있는지 확인
- 확인한 해당 otSK.EUICC.KA 또는/그리고 otPK.EUICC.KA를 해당 RSP session에 attach(연결)
- 인증서 체인 검증한 CERT.DPpb.SIG를 해당 RSP session에 attach
eUICC(425)는 서명 검증을 포함한 전술한 절차를 완료하면 해당 결과를 단말(420)의 LPAf에 전송할 수 있다. (470 단계) 만약 수신된 Data2에서 otPK.EUICC.KA가 bppeUICCOtpk의 값으로 전송되는 경우, IFPP 모드로 동작하는 eUICC(425)는 수신된 otPK.EUICC.KA가 없는 경우 새로운 otPK/SK.EUICC.KA 쌍을 생성하지 않고, 에러를 리턴할 수도 있다. 만약 수신되는 Data2에 포함된 데이터에 사용자 interaction에 대한 정보가 요구되는 경우(일 예로, Confirmation Code 입력에 대한 Flag가 set되어 있는 경우), eUICC(425)는 IFPP 모드로 동작하는 경우에 있어 에러를 리턴하지 않고 silently ignore하고 이후 475단계를 이어서 절차를 수행하거나 에러 메시지를 단말(420)로 회신해 주고(470 단계), 단말(420)은 475단계 및 480 단계를 수행하지 않고 프로파일 설치 동작을 종료하고 에러 결과를 Factory IT(415)에 회신할 수도 있다. (485 단계)
전술한 470 단계에서, 단말(420)의 LPAf는 해당 결과에 대해 정상 응답 메시지를 수신한 이후에, otPK.DP.KA와 BPP를 eUICC(425)에 전송할 수 있으며 otPK.DP.KA는 BPP에 포함된 데이터로써 전송될 수 있다. 한편, 후술한 바와 같이 전술한 465 단계 수행의 결과로 470 단계에서 인증서 오류 등 에러가 리턴 될 경우에도, 단말(420)은 475단계 및 480 단계를 수행하지 않고 프로파일 설치 동작을 종료하고 에러 결과를 Factory IT(415)에 회신할 수도 있다. (485 단계)
단말(420)의 LPAf는 BPP를 1개 이상의 APDU로 분할하여 eUICC(425)에 전송할 수 있다. (475 단계) 포함되어 전송되는 BPP는 세션 키로 암호화되어 전송될 수 있고, otPK.DP.KA가, 전송되는 BPP와 함께 또는 패키지에 포함되어 전송될 수 있다. LPAf에서 eUICC로 전송되는 메시지의 일 예는 ES10b. LoadBoundProfilePackage와 같은 function일 수 있으며, 해당 메시지의 데이터로 프로파일 서버에서 전송하는 ES8+ function들의 데이터들이 포함되어 전송될 수 있다.
eUICC(425)가 475 단계를 통해 수신된 일련의 BPP 설치를 위한 메시지들을 수신할 수 있고 이 중 하나의 메시지에 otPK.DP.KA가 포함되어 수신될 수 있다. eUICC(425)는 otPK.DP.KA가 프로파일 서버가 서명한 데이터에 포함되어 전송되는 경우에 서명한 데이터 검증을 위한 프로파일 서버의 공개키 (또는 공개키가 포함된 인증서)를 함께 또는 이전 단계에서 수신해서 사용할 수 있다. 이는 예를 들어, 앞서 획득한 PK.DPpb.SIG (또는 해당 공개키가 포함된 인증서로 CERT.DPpb.SIG)일 수 있다. 만약 이전 460 단계에서도 CERT.DPpb.SIG가 수신되었고 수신에 따른 인증서 검증이 수행된 경우, eUICC(425)는 465 단계에서 RSP session에 CERT.DPpb.SIG를 attach할 수 있다. eUICC(425)가 465 단계에서 RSP session에 CERT.DPpb.SIG를 attach 하는 경우, eUICC(425)는 475 단계에서 CERT.DPpb.SIG에 대한 인증서 체인 검증을 생략하고, 서명 검증에 CERT.DPpb.SIG를 사용할 수 있다.
eUICC(425)는 otPK.DP.KA를 수신하거나 또는 otPK.DP.KA가 추가로 포함되어 수신된 데이터를 검증하여 otPK.DP.KA를 추출하여, eUICC(425)는 해당 RSP session에 attach한 저장된 otSK.EUICC.KA와 조합하여 Shared secret을 생성하여 프로파일 설치를 위한 세션 키를 만들어 프로파일 설치를 완료할 수 있다.
한편, 445 단계 또는 460 단계 또는 475 단계 중의 적어도 하나의 데이터에 otPK.EUICC.KA가 Data에 포함되어 수신되지 않았으나 프로파일 서버의 서명 값에 해당 otPK.EUICC.KA가 포함되어 계산되고, 해당 계산된 서명 값이 수신될 수 있다. 일 예로 프로파일 서버가 430 단계에서 앞서 도 2 및 도 3에서 설명한 바와 같이 프로파일을 생성하는 절차를 수행하면서, otPK.EUICC.KA를 포함하여 서명 값을 생성하는 것도 가능할 수 있다. 프로파일서버/서버 벤더(410)와 eUICC(425)가 상호 합의하여 정의한 설정에 따라서, eUICC(425)는 445 단계 또는 460 단계 또는 475 단계 중의 하나에서 수신된 Data에 대한 프로파일 서버의 서명을 검증하는 과정에서 프로파일 서버의 서명을 계산할 때 저장된 otPK.EUICC.KA를 추가로 포함하여 서명을 생성한 다음, 해당 서명 값이 수신된 서명 값과 같은 지로 프로파일 서버를 검증하는 것도 가능할 수 있다. 이 때 사용할 저장된 otPK.EUICC.KA는 해당 RSP Session에 attach된 otSK.EUICC.KA에 대응되는 otPK.EUICC.KA 또는 해당 RSP Session에 attach된 otPK.EUICC.KA로 판단할 수 있다. 이는 이하 도면에서 추가 설명하지 않더라도, 동일하게 도 5의 545 단계 또는 550 단계 또는 575 단계, 도 6의 645 단계 또는 650 단계에도 적용될 수 있다.
eUICC(425)는 프로파일 설치 결과(480)를 단말(420)의 LPAf에 회신하고(480 단계), 단말은 해당 처리 결과를 Factory IT(485)에 회신할 수 있다. (485 단계) Factory IT/OEM(415)은 485 단계에서 회신된 처리 결과를 프로파일 서버/서버 벤더(410)에 회신할 수 있다. (490 단계) 490 단계에서 회신되는 결과에는, 사용한 EID (또는 EID가 포함된 eUICC 인증서), otPK.EUICC.KA, 처리 결과, 앞서 445 단계 내지 460 단계에서, 475 단계에서 수신한 transaction ID 중에 적어도 하나의 정보가 포함되어 회신 될 수 있고 해당 정보들이 일괄로 전송되는 경우에 있어서 여러 개 단말에서의 처리 결과에 대한 List 형태로 전달될 수도 있다. 490 단계에서 처리 결과를 수신한 프로파일 서버(410)는 BPP 처리 결과를 확인하여 사용 값 삭제/상태 업데이트를 처리할 수도 있다. 한편, 본 도면에서는 표기하지 않았으나, SP/SP 서버(405)는 프로파일 설치에 대한 처리 결과를 Factory IT/OEM(415)를 통해서 수신 또는 프로파일 서버/서버 벤더(410)를 경유해서 수신할 수도 있다. 한편, 도 4를 포함해 본 발명의 다른 도면에서도 검증에 실패하는 경우에 있어서 eUICC는 에러를 단말의 LPAf, 또는 단말의 LPAf를 경유하지 않은 경우에 해당 절차를 initiate한 단말 내의 entity에 전송하고 설치 절차를 종료할 수 있음에 유의해야 한다.
본 개시의 일 실시예에 따르면, 도 4의 460 단계에서 송수신되는 메시지는 하기의 표 2와 같은 형태일 수 있다.
otPK.EUICC.KA를 1개만 eUICC에 저장해 두고 사용하는 경우에 있어서, 단말제조사와 eUICC 제조사간 설정에 따라 eUICCOtpk는 460 단계에서 제공하지 않을 수 있다.
Figure PCTKR2023011123-appb-img-000002
도 5는 본 개시의 일 실시 예에 따른 도 2에서의 프로파일을 Factory IT에서 eUICC로 설치하는 동작을 설명하기 위한 도면이다. 도 5는 전술한 도 4에서 Profile 설치를 위한 사전 정보 공유 절차 460 내지 470 단계를 제외하고 서버와 eUICC간 인증 절차 및 BPP 설치 절차를 수행하여 프로파일을 프로비저닝하는 동작에 대해 기술한다.
도 5를 참조하면, IFPP용 BPP가 준비되면, Factory IT(515)는 N개 묶음의 eUICC에 맵핑되는 해당 BPP와 관련된 Key 정보들을 획득하여 이를 저장할 수 있다. Factory IT(515)는 해당 BPP와 관련된 Key 정보들을 공장에서 단말을 출고하기 전 특정 시점에 단말에 설정 값들을 프로비저닝하는 과정에서 맵핑되는 단말(520)에 전송할 수 있다. (535 단계) Factory IT(515)는 공장에서 프로파일을 프로비저닝하기 위한 처리를 하는 과정에서 단말 ID 및/또는 EID를 확인할 수 있고, 이에 맵핑된 BPP와 관련된 암호화 Key 정보들을 골라서, 해당 단말(520)에 전송하거나 또는 단말의 요청 메시지를 수신하여 이에 대한 회신 메시지로 전송할 수 있다.
535 단계에서 단말(520)에 전달되는 정보는 BPP(including otPK.DP.KA)와 암호화 키 정보로써 [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], [dpSignature1], 또는 dpSignature2 중 적어도 하나를 포함하여 전달될 수 있다.
- CERT.DPauth.SIG: 프로파일서버 자체의 인증에 사용되는 프로파일서버 인증서. 프로파일 서버가 프로파일서버의 인증을 위해 사용한 서명 값의 검증을 위해 필요한 공개키인 PK.DPauth.SIG를 포함할 수 있다.
- CERT.DPpb.SIG: 프로파일서버 인증서로 프로파일과 eUICC간 바인딩에 사용한 프로파일 서버의 서명 값을 검증하는데 필요한 공개키인 PK.DPpb.SIG를 포함할 수 있다.
- otPK.DP.KA: eUICC가 프로파일 서버와의 프로파일 다운로드 및 전송 세션에 사용하는 공유된 비밀 값(shared secret value) 생성에 사용될 수 있다.
- ServerChallenge: 프로파일 서버 인증 (Authenticate Server)을 위한 데이터에 포함되어 전송될 수 있고, 프로파일 서버 인증데이터는 프로파일 서버 인증에 사용한 프로파일 서버의 비밀키(SK.DPauth.SIG)로 서명된 값으로 제공될 수 있다.
- otPK.EUICC.KA: 프로파일 서버 인증을 위한 데이터에 포함되거나, 또는 프로파일 바인딩을 위한 데이터에 포함되에 전송될 수 있으며, 해당 정보를 포함하여 프로파일 서버가 서명한 데이터로써(예를 들어 dpSignature1 또는 dpSignature2의 하나에 포함되어) 전송될 수도 있다.
- dpSignature1: CERT.DPauth.SIG에 포함된 공개키에 대응되는 프로파일 서버의 비밀키(SK.DPauth.SIG)로 서명한 데이터를 나타낼 수 있다.
- dpSignature2: CERT.DPpb.SIG에 포함된 공개키에 대응되는 프로파일 서버의 비밀키(SK.DPpb.SIG)로 서명한 데이터를 나타낼 수 있다.
단말(520)은 IFPP 모드의 진입(540 단계)는 IFPP용으로 프로파일의 다운로드를 위한 function이 수신되거나, 프로파일 프로비저닝을 하는 시점에서의 단말(520)설정이 공장 프로비저닝/설정 등의 상태로 진입되어 있거나, 또는 공장 환경에서의 사용자의 프로파일 프로비저닝을 위한 메뉴 선택으로 진입되는 경우 중 적어도 하나일 수 있다.
단말(520)이 이미 공장에서의 프로파일의 프로비저닝/프로비저닝 설정 등의 상태로 설정되어 있는 경우에, 단말은 IFPP용으로 프로파일 다운로드를 위한 신규 function이 수신되기 전에 이미 IFPP 모드로 프로파일 다운로드 절차를 수행해야 함을 인지하고 해당 모드로 바로 진입하는 것도 가능할 수 있다. 예를 들어, 공장 설정 상태에서 LPA에 진입 시 IFPP로 프로파일 설정 모드로 자동 진입할 수도 있다. 이에 따라 IFPP 모드의 진입(540 단계)은 신규 function, 일 예로 단말(520)이 535 단계에서 수신한 ESfac.prepareFactoryDownload (including BPP(including otPK.DP.KA), [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], [dpSignature1], 또는 dpSignature2)와 같은 function을 수신하기 이전에 설정될 수 있다. 앞서 도 4에서 설명한 바와 같이 [CERT.DPauth.SIG] 및 CERT.DPpb.SIG가 포함되는 경우 535 단계에서 수신한 정보에는 [CERT.DPauth.SIG] 및 CERT.DPpb.SIG를 인증하기 위해 추가 인증서 체인 정보가 더 포함될 수 있으며, 이후 545 단계 또는 575 단계 중 적어도 하나로 eUICC(525)에 전송될 수 있다.
전술한 535 단계에서, IFPP용 프로파일의 다운로드 절차의 수행을 요청하는 메시지를 수신한 단말(520)과 eUICC(525)는 기존의 SGP.22에서 정의한 단말 출고 후의 프로파일 설치 과정을 재활용하여 프로파일 설치를 수행할 수 있다.
현재 SGP.22에서는 프로파일 설치 과정에서의 상호 인증 과정을 수행해야 하는데, 해당 상호 인증 과정에서 eUICC, 프로파일 서버가 랜덤 값을 생성하여 해당 전달한 랜덤 값이 서명된 값을 검증하여 상호 인증을 하게 된다.
예를 들어, eUICC는 랜덤 값으로 eUICC Challenge 값을 생성하여 이를 포함한 데이터를 프로파일 서버에 전송하게 되면 프로파일 서버가 상기 eUICC Challenge를 프로파일 서버의 비밀키로 서명한 다음에 eUICC에 회신하면 eUICC가 프로파일 서버의 비밀키로 서명된 값을 프로파일 서버의 공개 키로 검증하여 프로파일 서버가 전송한 데이터에 포함된 eUICC Challenge값이 앞서 eUICC가 생성하여 보낸 값과 같은지를 판단하여 프로파일 서버를 인증할 수 있다. 마찬 가지로, 프로파일 서버도 Server Challenge 값을 생성하여 eUICC에게 전송하고 eUICC는 해당 값을 포함한 데이터를 eUICC가 서명하여 회신하면, eUICC의 비밀키로 서명된 값을 eUICC의 공개 키로 검증하여 eUICC가 전송한 데이터에 포함된 Server Challenge값이 앞서 프로파일 서버가 생성하여 보낸 값과 같은지 여부를 판단하여 eUICC를 인증할 수 있다.
공장에서 프로파일을 프로비저닝하는 과정에서 프로파일 서버(510)와 eUICC(525)간 상호 인증을 위한 eUICC Challenge 값과 Server Challenge 값을 실시간으로 생성하여 전달할 수 없기 때문에 해당 값들은 미리 사전에 생성된 정보로써 전달될 수 있다. 예를 들어, 프로파일 서버가 eUICC로 회신하는 eUICC Challenge은 eUICC가 앞서 도 2 내지 도 3의 프로파일 주문/생성 단계에서 프로파일 서버가 획득한 eUICC 사전 생성한 랜덤 값일 수 있다. 이는 일 예로 otPK.EUICC.KA 값일 수 있다.
한편, 공장에서 프로파일을 프로비저닝하는 과정에서 eUICC가 Server Challenge를 포함한 eUICC의 서명 데이터를 프로파일 서버에 회신하여, 해당 데이터를 프로파일 서버가 검증하는 방법으로써, 프로파일 서버가 eUICC 인증을 수행할 수 없을 수도 있다. 따라서, eUICC(525)가 프로파일 서버(510)는 인증하되, 프로파일 서버(510)는 eUICC(525)를 프로파일 다운로드를 수행하는 과정 중에 인증하지 않을 수도 있다. 일 예로, 프로파일 서버는 프로파일 다운로드를 수행하는 과정 중에 인증하지 않고, 프로파일 서버(510)는 앞서 프로파일을 준비하는 단계(예를 들어, 도 3의 350 단계)에서 eUICC가 서명하여 전달한 otPK.EUICC.KA를 검증한 다음에 BPP를 생성함으로써 eUICC(525)를 사전에 인증할 수도 있다.
한편, 프로파일 서버(510)는 SGP.22의 상호 인증 과정을 모사하기 위해 기존 ES10x 절차에서 프로파일 서버(510)가 eUICC (525)에 전송하는 Server Challenge 값을 서버가 서명한 데이터에 포함하여 Factory IT에 제공함으로써, Factory IT가 해당 정보를 단말에 전송하여, 단말로 하여금 eUICC에 전달할 수도 있다. Server Challenge는 프로파일 서버(510)가 BPP 생성 요청을 수신 또는 그 이전 시점에 생성해 두었다가 제공해 줄 수도 있다.
단말(520)의 LPAf(미도시)는 IFPP로 진입하여 eUICC(525)에게 서버 인증 정보로 eUICC Challenge가 포함된 데이터를 전송해 줄 수 있다. 해당 데이터는 서버가 서명한 데이터 형태로 전송될 수도 있다. (545 단계)
545 단계가 수행되었다면, eUICC(525)는 545 단계를 RSP session 생성 시점으로 판단하여 동작할 수 있다. eUICC(525)가 545 단계를 RSP session 생성 시점으로 판단하는 경우, eUICC(525)가 해당 메시지를 수신하기 이전에 이미 생성된 RSP session을 가지고 있었다면 eUICC(425)는 이전 생성된 RSP Session을 삭제하고 이전에 RSP session에서 (프로파일 설치를 완료하지 않았으므로) 최종 사용하지 않은 otPK.EUICC.KA 및 otSK.EUICC.KA를 삭제하지 않고 저장한 다음, 새로운 RSP session을 시작할 수 있다.
545 단계에서 전송되는 메시지의 일 예는, ES10b.AuthenticateServer (Data1(Including otPK.EUICC.KA), dpSignature1, CERT.DPauth.SIG)와 같은 메시지 일 수 있다. dpSignature1은 Data1을 프로파일 서버(510)의 비밀 키로 서명한 값이다. 해당 메시지를 수신한 eUICC(525)는 프로파일 서버(510)를 검증할 수 있으며(550 단계), otPK.EUICC.KA는 eUICC Challenge 및 프로파일 서버의 서명 검증에 사용될 수 있다. 550 단계에서, eUICC(525)에서 프로파일 서버(510)를 인증하는 검증 절차는 다음의 절차 중 하나를 포함하여 수행될 수 있다. 물론 하기의 절차에 제한되지 않는다.
- CERT.DPauth.SIG Certificate chain 검증: CERT.DPauth.SIG 인증 체인과 eUICC의 인증 체인이 동일 인증 체인에 있는 지 여부로 검증
- eUICC(525)는 프로파일 서버의 서명을 검증: 수신된 프로파일 서버의 공개 키를 가지고 dpSignature1를 복호화한 값을 Data1(Including otPK.EUICC.KA)의 값을 비교하여 동일 값을 가지는 지 여부로 하여 검증.
- CERT.DPauth.SIG에서 프로파일 서버의 공개 키를 추출
- otPK.EUICC.KA에 맵핑되는 otSK.EUICC.KA 및/또는 otPK.EUICC.KA를 해당 RSP session에 attach(연결)
eUICC(525)는 프로파일 서버(510)의 인증서 및 서명을 검증하면 해당 결과를 단말(520)의 LPAf에 회신해 줄 수 있다. (555 단계) eUICC(525)는 프로파일 서버(510)의 인증서 및 서명을 검증에 실패하는 경우에 에러 메시지를 단말(520)에 회신해 주어(555 단계), 에러 메시지를 회신한 단말(520)은 프로파일 설치 동작을 종료하고 에러 결과를 Factory IT(515)에 회신할 수 있다. (585 단계)
단말(520)의 LPAf는 555 단계에서 회신한 메시지를 통해 정상 응답 메시지를 수신한 이후에 otPK.DP.KA와 BPP를 eUICC(525)에 전송할 수 있으며, 단말(520)의 LPAf는 BPP를 1개 이상의 APDU로 분할하여 eUICC(525)에 전송할 수 있다. 575 단계에서, 포함되어 전송되는 BPP는 세션 키로 암호화되어 전송될 수 있고, otPK.DP.KA가 BPP와 함께 또는 포함되어 전송될 수 있다. 단말(520)의 LPAf에서 eUICC(525)로 전송되는 메시지의 일 예는 ES10b. LoadBoundProfilePackage와 같은 function일 수 있으며, 해당 메시지의 데이터로 프로파일 서버(510)에서 전송하는 ES8+ function들의 데이터들이 포함되어 전송될 수 있다. eUICC(525)가 575 단계를 통해 수신된 일련의 BPP 설치를 위한 메시지들을 수신할 수 있고 이 중 하나의 메시지에 otPK.DP.KA가 포함되어 수신될 수 있다. eUICC(525)는 otPK.DP.KA가 프로파일 서버(510)가 서명한 데이터에 포함되어 전송되는 경우에 서명한 데이터 검증을 위한 공개키를 함께 또는 이전 단계에서 수신해서 사용할 수 있다. 일 예로 PK.DPpb.SIG를 포함하는 CERT.DPpb.SIG가 전술한 575 단계에서 함께 전송되거나 전술한 545 단계에서 전송되었을 수 있고, 이 경우 eUICC(525)는 545 단계에서 생성한 RSP session에 CERT.DPpb.SIG가 attach하여 575 단계에서 해당 attach된 CERT.DPpb.SIG를 사용하여 서명 검증에 사용할 수 있다.
eUICC(525)는 otPK.DP.KA를 수신하거나 또는 포함되어 수신된 서명된 데이터(dpSignature2)를 CERT.DPpb.SIG에 포함된 공개 키를 가지고 검증하여 otPK.DP.KA를 추출하여, eUICC(525)가 저장해 둔 otSK.EUICC.KA와 조합하여 Shared secret을 생성하여 프로파일 설치를 위한 세션 키를 만들어 프로파일을 설치를 완료할 수 있다. 사용할 otSK.EUICC.KA는 해당 RSP session에 attach되는 otSK.EUICC.KA 또는 RSP session에 attach되는 otPK.EUICC.KA에 맵핑되는 것을 사용할 수 있다.
eUICC(525)는 프로파일 설치 결과를 단말(520)의 LPAf에 회신하고(580 단계), 단말(520)은 해당 처리 결과를 Factory IT/OEM에 회신할 수 있다. (585 단계) Factory IT/OEM(515)은 585 단계에서 회신된 처리 결과를 프로파일 서버/서버 벤더(510)에 회신할 수 있다. (590 단계) 590 단계에서 회신되는 결과에는 사용한 EID (또는 EID가 포함된 eUICC 인증서), otPK.EUICC.KA, 처리 결과, 앞서 545 단계 또는575 단계에서 수신한 transaction ID 중 적어도 하나의 정보가 포함되어 회신 될 수 있고 해당 정보들이 일괄로 전송되는 경우에 있어서 여러 개 단말에서의 처리 결과에 대한 List 형태로 전달될 수도 있다. 590 단계에서 처리 결과를 수신한 프로파일 서버(510)는 BPP 처리 결과를 확인하여 사용 값 삭제/상태 업데이트를 처리할 수도 있다. 한편, 본 도면에서는 표기하지 않았으나, SP/SP 서버(505)는 프로파일 설치에 대한 처리 결과를 Factory IT를 통해서 수신 또는 프로파일 서버를 경유해서 수신할 수도 있다.
도 6은 본 개시의 일 실시 예에 따른 도 2에서의 프로파일을 Factory IT에서 eUICC로 설치하는 동작을 설명하기 위한 도면이다. 도 6은 BPP와 관련된 Key 정보를 단말에서 하나의 단계로 일괄 eUICC로 전달하는 방법을 설명하는 실시 예이다.
도 6을 참조하면, IFPP용 BPP가 준비(630 단계)되면, Factory IT(615)에서는 N개 묶음의 eUICC에 맵핑되는 해당 BPP와 관련된 Key 정보들을 획득하여 이를 저장할 수 있다. Factory IT(615)는 해당 BPP와 관련된 Key 정보들을 공장에서 단말을 출고하기 전 특정 시점에 단말에 설정 값들을 프로비저닝하는 과정에서 맵핑되는 단말(620)에 전송할 수 있다. (635 단계) Factory IT(615)는 공장에서 프로파일을 프로비저닝하기 위한 처리를 하는 과정에서 단말 ID 및/또는 EID를 확인할 수 있고, 이에 맵핑된 BPP와 관련된 암호화 Key 정보들을 골라서 해당 단말(620)에 전송하거나 또는 단말의 요청 메시지를 수신하여 이에 대한 회신 메시지로 전송할 수 있다.
635 단계에서 단말(620)에 전달되는 정보는 BPP, 암호화 키 정보로써 otPK.DP.KA, [otPK.EUICC.KA], [ServerChallenge], [dpSignature1], dpSignature2, [CERT.DPauth.SIG], 또는 CERT.DPpb.SIG 중 적어도 하나를 포함하여 전달될 수 있다. otPK.DP.KA는 BPP에 포함 또는 함께 전송되는 정보로써 전송될 수 있고, 프로파일 바인딩을 위한 프로파일 서버의 비밀키로 서명되어 전송될 수도 있다. otPK.DP.KA가 서명된 데이터로 전송되는 경우에, 프로파일 서버는 해당 서명된 데이터의 검증을 위해 프로파일 서버의 공개 키를 함께 전송할 수 있다. 해당 프로파일 서버의 공개 키는 프로파일 서버의 인증서에 포함되어 전송될 수 있다. 이는 일 예로 CERT.DPauth.SIG, CERT.DPpb.SIG와 같은 인증서 일 수도 있고, 또는 IFPP를 위해 프로파일 서버가 사용한 비밀 키에 대칭되는 공개 키에 대한 신규 인증서(일 예로 CERT.DPifpp.SIG)일 수도 있다. 635 단계에서 전송될 수 있는 암호화 키 설명은 다음과 같다.
- CERT.DPauth.SIG: 프로파일서버 자체의 인증에 사용되는 프로파일서버 인증서. 프로파일 서버가 프로파일서버의 인증을 위해 사용한 서명 값의 검증을 위해 필요한 공개키인 PK.DPpb.SIG를 포함할 수 있다.
- CERT.DPpb.SIG: 프로파일서버 인증서로 프로파일과 eUICC간 바인딩에 사용한 프로파일 서버의 서명 값을 검증하는데 필요한 공개키인 PK.DPpb.SIG를 포함할 수 있다.
- otPK.DP.KA: eUICC가 프로파일 서버와의 프로파일 다운로드 및 전송 세션에 사용하는 공유된 비밀 값(shared secret value) 생성에 사용될 수 있다.
- ServerChallenge: 프로파일 서버 인증을 위한 데이터를 포함하고, 프로파일 서버 인증을 위한 데이터는 프로파일 서버 인증에 사용한 프로파일 서버의 비밀키(SK.DPauth.SIG)로 서명된 데이터 형태로 제공될 수도 있음. Challenge는 프로파일 서버/서버 벤더(610)가 (630 단계)에서 BPP 생성 요청을 수신 또는 그 이전 시점에 미리 생성해 둘 수 있다.
- otPK.EUICC.KA: 프로파일 서버 인증을 위한 데이터에 포함되거나, 또는 프로파일 바인딩을 위한 데이터에 포함되어 전송될 수 있으며, 해당 정보를 포함하여 프로파일 서버가 서명한 데이터로써(일 예로, dpSignature1 또는 dpSignature2 또는 dpSignature3의 하나에 포함되어) 전송될 수도 있다.
- dpSignature1: CERT.DPauth.SIG에 포함된 공개키에 대응되는 프로파일 서버의 비밀키(SK.DPauth.SIG)로 서명한 데이터를 나타낼 수 있다.
- dpSignature2: CERT.DPpb.SIG에 포함된 공개키에 대응되는 프로파일 서버의 비밀키(SK.DPpb.SIG)로 서명한 데이터를 나타낼 수 있다.
- dpSignature3: CERT.DPifpp.SIG에 포함된 공개키에 대응되는 프로파일 서버의 비밀키(SK.DPifpp.SIG)로 서명한 데이터를 나타낼 수 있다.
한편, 도면에서는 도시하지 않았으나, 프로파일 서버(610)는 635 단계에서 전송되는 데이터들을 모두 IFPP용으로 신규 설정한 프로파일 서버의 비밀키로 서명하고 이에 대한 대응되는 공개 키가 포함된 인증서를 함께 전송할 수도 있다. 이 경우, CERT.DPpb.SIG와 CERT.DPauth.SIG 대신에 CERT.DPifpp.SIG 그리고 해당 인증서에 포함되는 PK.EUICC.SIG로 복호화가 가능한 서명된 데이터로써, 데이터들이 전송될 수 있고 해당 서명된 Data에 otPK.EUICC.KA가 포함되어 전송되는 것도 가능할 수 있다. 다시 말해서 645 단계에서 CERT.DPauth.SIG와 CERT.DPpb.SIG 대신에 CERT.DPifpp.SIG가, 그리고 dpSignature 1과 diSignature 2 대신에 SK.DPifpp.SIG로 서명한 데이터가 전송될 수도 있다.
한편, 앞서 도 4 내지 도 6에서와 같이 서버와 단말간 인증 단계를 위해 사용하는 CERT.DPauth.SIG 및 프로파일 서버 인증을 위해 사용한 비밀키로 서명한 데이터인 dpSignature 1은 미 포함되어 수신될 수도 있다. CERT.DPauth.SIG가 미 포함되어 수신되는 경우 CERT.DPpb.SIG는 프로파일 바인딩과 더불어 프로파일 서버의 인증을 위한 용도를 포함하여 사용될 수 있다.
단말(620)은 IFPP 모드의 진입(640 단계)은 IFPP용으로 프로파일의 다운로드를 위한 function이 수신되거나 프로파일 프로비저닝을 하는 시점에서의 단말(620)설정이 공장 프로비저닝/설정 등의 상태로 진입되어 있거나, 또는 공장 환경에서의 사용자의 프로파일 프로비저닝을 위한 메뉴 선택으로 진입되는 경우 중 적어도 하나일 수 있다.
단말(620)이 이미 공장에서의 프로파일의 프로비저닝/프로비저닝 설정 등의 상태로 설정되어 있는 경우에, 단말은 IFPP용으로 프로파일 다운로드를 위한 신규 function이 수신되기 전에 이미 IFPP 모드로 프로파일 다운로드 절차를 수행해야 함을 인지하고 해당 모드로 바로 진입하는 것도 가능할 수 있다. 예를 들어, 공장 설정 상태에서 LPA에 진입 시 IFPP로 프로파일 설정 모드로 자동 진입할 수도 있다. 이에 따라 IFPP 모드의 진입(640 단계)은 신규 function, 일 예로 단말(620)이 635 단계에서 수신한 ESfac.prepareFactoryDownload (including BPP, otPK.DP.KA, [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], [dpSignature1], dpSignature2)와 같은 function을 수신하기 이전에 설정될 수 있다. 한편, 도 4 내지 도 5에서 전술한 바와 같이 [CERT.DPauth.SIG], CERT.DPpb.SIG에 인증서 체인이 더 있는 경우, 해당 인증서 체인들이 더 포함되어 전송될 수도 있다. 즉, 635 단계에서 수신되는 정보에 추가 인증서 체인 정보가 더 포함되어 전송되고, 이후 645 단계를 통해 eUICC(525)에 전송될 수 있다.
해당 수신되는 메시지에 otPK.EUICC.KA는 프로파일 서버가 서명한 데이터에 포함되어 전송될 수도 있다.
전술한 635 단계에서, IFPP용 프로파일의 다운로드 절차의 수행을 요청하는 메시지를 수신한 단말(620)과 eUICC(625)는 공장 설치용 BPP 주입을 위한 신규 function을 정의하여, 단말(620)에서 BPP와 관련된 Key 정보들을 일괄로 eUICC(625)로 전달할 수도 있다. 일괄 전달되는 BPP와 관련된 Key 정보들은 단말(620)이 Factory IT(615)로부터 IFPP용으로 프로파일 설치를 위한 정보들 중 적어도 하나 이상의 정보를 포함하는 메시지일 수 있다.
단말(620)은 eUICC(625)에 공장 설치용 BPP를 전달하는 메시지를 LPA를 경유하거나 또는 LPA를 경유하지 않고 eUICC(625)에 전달할 수 있다. 즉, 해당 BPP 전달하는 function을 단말의 담당 애플리케이션 또는 소프트웨어에서 호출하여, 단말(620)에서 해당 정보들이 LPA를 거치지 않고 eUICC(625)로 전송할 수도 있다.
eUICC(625)는 단말(620)로부터 IFPP용 BPP 설치를 위해 정의된 Function을 수신하면(645 단계), IFPP용 BPP 설치 모드로 진입하여 프로파일 설치를 진행할 수 있다.645 단계에서, BPP를 설치하기 위해 전송하는 메시지는 하나 이상의 분할된 여러 개의 메시지로 전송되는 절차를 수행할 수도 있다. BPP 및 BPP의 설치를 위해 필요한 eUICC 데이터들이 645 단계와 같이 하나의 function을 통해서 전송되는 경우 eUICC(625)가 해당 function을 수신하면 RSP session이 생성된 것으로 인지할 수 있다. eUICC(625)가 RSP session이 생성된 것으로 인지하고, 이전에 RSP session이 존재하는 경우에 해당 session을 캔슬하며, 해당 세션에서 사용하지 않은 otPK.EUICC.KA 및 otSK.EUICC.KA들은 저장하고, 새로운 RSP session을 시작하는 것으로 인지하여 동작을 수행할 수도 있다.
eUICC(525)는 다음 중 하나의 검증 절차 수행을 포함할 수 있다. (650 단계)
- CERT.DPauth.SIG Certificate chain 검증: CERT.DPauth.SIG 인증 체인과 eUICC의 인증 체인이 동일 인증 체인에 있는 지로 검증
- CERT.DPauth.SIG 검증: 프로파일 서버 인증을 위해 사용한 프로파일 서버의 인증서의 유효성을 검증
- PK.Dpauth.SIG를 가지고 프로파일 서버의 서명 값을 검증: CERT.Dpauth.SIG에서 추출한 PK.DPpb.SIG를 사용하여, 프로파일 서버가 SK.DPpb.SIG로 서명하여 전달한 데이터를 복호화하여 서명을 검증
- CERT.DPpb.SIG Certificate chain 검증: CERT.DPpb.SIG 인증 체인과 eUICC의 인증 체인이 동일 인증 체인에 있는 지로 검증
- CERT.DPpb.SIG 검증: 프로파일 바인딩을 위해 사용한 프로파일 서버의 인증서의 유효성을 검증
- PK.DPpb.SIG를 가지고 프로파일 서버의 서명 값을 검증: CERT.DPpb.SIG에서 추출한 PK.DPpb.SIG를 사용하여, 프로파일 서버가 SK.DPpb.SIG로 서명하여 전달한 데이터를 복호화하여 서명을 검증
- otPK.EUICC.KA를 검증: 645 단계에서 eUICC(625)가 수신한 메시지에는 otPK.EUICC.KA가 포함되거나 포함되지 않을 수 있다. 그리고 otPK.EUICC.KA는 프로파일 서버가 서명한 데이터에 포함 또는 포함되지 않고 전송될 수도 있다. otPK.EUICC.KA가 포함되어 수신되는 경우, eUICC(625)는 otPK.EUICC.KA에 대응되는 otSK.EUICC.KA를 가지는 지 여부를 판단할 수도 있다.
한편, 수신되는 otPK.EUICC.KA가 포함된 데이터는 프로파일 서버가 사용하는 비밀 키(SK.DPxx.SIG, xx는 용도를 의미) 중의 하나로 서명되어 전송될 수 있다. 이는 일 예로, 프로파일 바인딩을 위해 사용한 비밀 키(SK.DPauth.SIG)이거나 프로파일 서버의 인증의 위해 사용한 비밀 키(SK.DPauth.SIG)일 수 있다. otPK.EUICC.KA가 포함된 데이터가 프로파일 서버의 비밀 키로 서명되어 수신된 경우, eUICC(625)는 해당 서명의 검증을 위한 공개 키 내지 해당 공개키가 포함된 프로파일 서버 인증서를 645 단계에서 단말(620)로부터 수신한 메시지와 함께 수신할 수도 있다. eUICC(625)는 otPK.EUICC.KA 수신 및 서명된 데이터로 수신되었는지 여부에 따라 아래와 같은 절차 중 하나를 수행할 수 있다. 물론 하기의 절차에 제한되지 않는다.
a. otPK.EUICC.KA가 포함되고 서명된 데이터로 수신된 경우,
i. eUICC(625)는 저장하고 있는 otPK.EUICC.KA를 포함하여 프로파일 서버의 서명을 검증. 만약 eUICC(625)가 프로파일의 서명 검증에 실패하는 경우 단말에 에러를 회신하여 절차를 종료할 수 있다.
ii. eUICC(625)는 a-i에 추가적으로 otPK.EUICC.KA를 프로파일 서버를 인증하기 위한 eUICCChallenge 용도로 사용하여 추가 검증을 수행하는 것도 가능. 앞서 도 4 내지 도 5에서 전술한 바와 같이 프로파일 서버가 서명한 데이터로 수신된 otPK.EUICC.KA가 eUICC Challenge로 사용하여 eUICC가 이전에 생성하여, 저장하고 있는 otPK.EUICC.KA와 같은지 확인할 수 있고, 저장하고 있는 값과 다른 경우, 단말에 에러를 회신하여 절차를 종료할 수 있다.
b. otPK.EUICC.KA가 포함되고, 서명되지 않은 데이터로 수신된 경우,
i. eUICC(625)는 otPK.EUICC.KA를 서명한 프로파일 서버의 서명 검증을 하지 않을 수 있다.
c. otPK.EUICC.KA가 포함되지 않은 경우: eUICC(625)는 otPK.EUICC.KA를 서명한 프로파일 서버의 서명 검증을 하지 않거나 앞서 도 4에서 설명한 바와 같이 otPK.EUICC.KA가 포함되어 수신되지 않았으나 해당 값이 서명 검증을 위해 사용되어야 하는 경우에 (즉, 프로파일 서버가 signature를 해당 값을 포함하여 계산한 경우), 저장된 otPK.EUICC.KA를 사용하여 서명 검증을 할 수 있다.
- Session 키 생성: eUICC(625)는 저장하고 있는 otSK.EUICC.KA와 수신된 otPK.DP.KA를 가지고 Session키를 생성할 수 있다.otPK.DP.KA는 SK.DPpb.SIG로 서명된 데이터에 포함되어 수신될 수 있다. eUICC(625)가 사용할 otSK.EUICC.KA는 프로파일 서버가 signature를 계산할 때 포함한 otPK.EUICC.KA에 대응되는 otSK.EUICC.KA 또는 수신된 otPK.EUICC.KA에 대응되는 otSK.EUICC.KA로 판단할 수 있다.
- 복호화 및 BPP 설치: 앞서 생성한 세션 키를 가지고 eUICC(625)는 프로파일을 복호화 및 설치를 수행할 수 있다. 만약, 생성한 세션 키로 복호화가 불가능한 경우, eUICC(625)는 프로파일을 설치할 수 없으므로, 이에 대한 에러를 리턴하고 설치 절차를 종료할 수 있다.
한편, eUICC(625)가 프로파일 설치를 위한 절차를 수행하는 과정에서 SGP.22에서 현재 정의하고 있는 실시간 상호 인증 과정을 수행하지 못할 수 있다. 즉, 공장에서 프로파일을 프로비저닝하는 과정에서 eUICC가 Server Challenge를 포함한 eUICC(625)의 서명 데이터를 프로파일 서버에 회신하여, 해당 데이터를 프로파일 서버가 검증하는 방법으로써, 프로파일 서버가 eUICC 인증을 수행할 수 없을 수도 있다. 이에 따라, eUICC(625)가 수신하는 메시지(645 단계)에 Server Challenge가 포함되지 않고 수신될 수 있다. 따라서, 앞서 도 3의 350 단계에서 설명한 바와 같이 프로파일 서버(615)는 앞서 프로파일을 준비하는 630 단계에서 eUICC(625)가 서명하여 전달한 otPK.EUICC.KA를 검증한 다음에 BPP를 생성함으로써 eUICC(625)를 사전에 인증할 수도 있다. 또한, eUICC(625)에서 서버를 인증하지 않고 처리할 수도 있다. 이 경우에, 앞서 언급한 바와 같이 635 단계에서 CERT.DPauth.SIG 및 SK.DPauth.SIG로 서명된 데이터가 포함되어 수신되지 않을 수 있다.
만약 eUICC(625)가 IFPP에서 프로파일 서버 인증을 수행하도록 설정되어 있으며 (650 단계)에서 프로파일 서버 인증을 위한 위의 CERT.DPauth.SIG 및 SK.DPauth.SIG로 서명된 데이터를 수신 받지 못하는 경우에 있어서 eUICC(625)는 에러를 리턴하고 절차를 종료할 수도 있다.
만약, 전술한 바와 같이 eUICC(625)가 IFPP에서 CERT.DPauth.SIG 내지 CERT.DPpb.SIG 대신, 또는 이 둘을 대신하여 CERT.DPifpp.SIG와 같은 IFPP용의 신규 인증서를 사용하고 이에 상응하는 SK.DPifpp.SIG로 서명된 데이터를 받는 경우에 eUICC(625)는 해당 인증서를 사용하여 서명을 검증하고, 서명 검증에 실패하면 에러를 리턴하고 서명 검증에 성공하면 프로파일 설치 절차를 이어서 수행할 수도 있다.
eUICC(625)는 앞서 도 4의 480 단계 또는 도 5의 580 단계와 같이 프로파일 설치 결과를 단말(620)에 회신하고 (655 단계), 단말(620)은 해당 처리 결과를 Factory IT(615)에 회신할 수 있다. (660 단계) Factory IT/OEM(615)은 회신된 결과를 프로파일 서버/서버 벤더(610)에 회신해 줄 수 있다. (670 단계) 670 단계에서 회신되는 결과에는 사용한 EID (또는 EID가 포함된 eUICC 인증서), otPK.EUICC.KA, 처리 결과, 645 단계에서 수신한 transaction ID 중 적어도 하나의 정보가 포함되어 회신 될 수 있고 해당 정보들이 일괄로 전송되는 경우에 있어서 여러 개 단말에서의 처리 결과에 대한 List 형태로 전달될 수도 있다. 이를 수신한 프로파일 서버(610)는 BPP 처리 결과를 확인하여 사용 값 삭제/상태 업데이트를 처리할 수도 있다. 한편, 본 도면에서는 표기하지 않았으나, SP/SP벤더(605)는 프로파일 설치에 대한 처리 결과를 Factory IT/OEM(620)를 통해서 수신 또는 프로파일 서버/서버 벤더(610)를 경유해서 수신할 수도 있다.
도 7은 본 개시의 일 실시 예에 따른 무선 통신 시스템에서 프로파일 서버(700), Factory IT(720) 및 단말(740)의 구조를 나타내는 블록도이다.
도 7을 참조하면, 본 개시의 일 실시 예에 따른 프로파일 서버(700)는 통신부(705), 제어부(710) 및 암호화부(715)를 포함할 수 있다.
통신부(705)는 다른 장치들로 데이터를 송신하거나 다른 장치로부터 데이터를 수신할 수 있다. 통신부(705)는 암호화된 키, 암호화된 프로파일 등을 송신하거나 수신할 수 있다. 이를 위하여 통신부(705)는 적어도 하나의 통신 모듈과 안테나 등을 구비할 수 있다.
제어부(710)는 본 발명에 따른 프로파일 설치를 위하여 프로파일 서버(700)의 각 구성 요소를 제어할 수 있다. 제어부(710)의 구체적인 동작을 상술한 바와 같다. 일 실시 예에 따르면, 프로파일 서버(700)는 서비스 사업자 서버 또는 제조사의 서버 또는 서비스 사업자와 제조사로부터 수신된 정보를 참조하여 동일한 주문 건인지를 판단하고, 동일한 주문 건에 대해서 프로파일과 eUICC 제공 정보를 맵핑하여 저장부(미도시)에 저장해 두도록 처리할 수 있다. 또한, 서비스 사업자로부터 수신된 EID 정보를 참조하여 프로파일을 특정 EID와 맵핑하여 미리 준비하도록 동작을 제어할 수 있다. 또 다른 일 실시 예에 따르면, 제어부(710)는 통신부(705)을 통해서 수신된 메시지로부터 수신된 정보를 가지고 IFPP용으로 프로파일을 준비해야 하는지를 판단하여 프로파일을 준비하는 동작으로 진입을 처리하여 동작을 수행할 수 있다. 프로파일 서버(700)는 Factory IT로부터 수신된 메시지를 통신부(705)를 통해 수신하여 해당 수신 메시지로부터 IFPP용 프로파일의 다운로드 요청임으로 판단하고 공장용으로 프로파일을 준비하도록 동작을 처리하여 해당 처리 결과를 통신부(705)를 통해 Factory IT로 송신해 줄 수 있다. 암호화부(715)는 제어부(710)의 제어에 따라 키 또는 프로파일의 암호화 또는 복호화를 수행한다.
암호화부(715)는 HSM을 포함하거나 HSM 그 자체로 명명될 수 있으며, 암호 키를 노출시키지 않고 프로파일의 암호화 및 복호화를 수행할 수 있다. 구현하기에 따라, 암호화부(715)는 제어부(710)에 내장되거나, 제어부(710)에 의하여 구동되는 소프트웨어 코드 형식으로 구현될 수 있다.
도 7을 참조하면, 본 개시의 일 실시 예에 따른 Factory IT(720)는 통신 장치(725), 제어 장치(730), 및 저장 장치(735)를 포함할 수 있다. 통신 장치(725)는 다른 장치들로 데이터를 송신하거나 다른 장치로부터 데이터를 수신할 수 있다. Factory IT(720)가 저장 장치(735)를 포함하는 하나의 장치로써 동작하는 경우, Factory IT(720)는 통신 장치(725)와 저장 장치(735)를 중앙에서 통제하는 별도의 제어 장치(730) 및 저장 장치(735)를 구비할 수도 있다. Factory IT(720)는 전술한 바와 같이 1개 이상의 장치로도 구성될 수도 있다.
통신 장치(725)는 암호화된 키, 암호화된 프로파일 등을 송신하거나 수신할 수 있다. 이를 위하여 통신 장치(725)는 적어도 하나의 통신 모듈과 안테나 등을 구비할 수 있다. 본 개시의 일 실시 예에 따르면, Factory IT(720)가 저장 장치(735)를 포함하는 하나의 장치로써 동작하는 경우, 통신 장치(725)는 제조사의 외부 서버와의 연결이 아닌 Factory IT/OEM의 내부에 독립적인 네트워크 연결을 위해서 구비될 수 있다. Factory IT(720)는 통신 장치(725)을 통해서 암호화된 키 정보와 암호화된 프로파일 등을 송신하거나 수신할 수 있다. 수신된 프로파일 또는 암호화된 키 등은 Factory IT(720)의 제어 장치(730)에 의해서 해당 정보와 맵핑되는 단말과의 맵핑을 판단하여 통신 장치(725)를 통해 단말(740)에 송신될 수 있다.
한편, 암호화된 키 정보와 암호화된 프로파일 등을 프로파일 서버로 송신 또는 프로파일 설치 결과를 회신하는 factory IT/제조사 장치들은 서로 같거나 같지 않은 장치일 수 있다. 예를 들어, 프로파일을 프로파일 서버/서버 벤더로부터 수신한 Factory IT 장치와 단말에 프로파일을 전송해 주는 Factory IT 장치는 서로 같거나 다른 장치일 수 있다. 프로파일을 단말에 전송해 주는 Factory IT 장치는 외부 서버와의 연결이 있거나 없을 수도 있다. 따라서, 설치 결과는 이를 단말로부터 수신한 장치로부터 Factory IT/제조사 내의 다른 장치로 전달되어 외부 연결이 있는 factory IT 장치로부터 프로파일 서버/서버 벤더에 전달될 수도 있다.
Factory IT(720)의 저장 장치(735)는 적어도 하나의 암호화된 프로파일을 저장할 수 있다. 또한, 적어도 하나의 암호화된 프로파일에 대한 암호화된 키 정보를 저장할 수 있다. Factory IT(720)의 통신 장치(725)는 프로파일 설치 결과를 수신하면 제어 장치(730)가 이를 판단하여 맵핑된 프로파일의 설치 결과 정보를 업데이트하여 결과 정보를 저장 장치(735)에 업데이트했다가, 특정 시점에 프로파일 서버(700)에 일괄로 제공해 줄 수 있다. 저장 장치(735)는 하드디스크 타입(hard disk type), 램 (Random Access Memory, RAM), SRAM(Static Random Access Memory), 롬(Read-Only Memory, ROM), EEPROM(Electrically Erasable Programmable Read-Only Memory), PROM(Programmable Read-Only Memory), 자기 메모리, 자기 디스크, 광디스크 중 적어도 하나의 타입의 저장매체를 포함할 수 있다. Factory IT(720)는 서버 등의 형태로 구현될 수 있다.
도 7을 참조하면, 단말(740)은 통신부(745), 제어부(750), 저장부(755), 및 eUICC(760)를 포함할 수 있다. 통신부(745)는 다른 장치들로 데이터를 송신하거나 다른 장치로부터 데이터를 수신할 수 있다. 통신부(745)는 암호화된 키, 암호화된 프로파일 등을 수신할 수 있다. 이를 위하여 통신부(745)는 적어도 하나의 통신 모듈과 안테나 등을 구비할 수 있다. 제어부(750)는 본 발명에 따른 프로파일 설치를 위하여 단말(740)의 각 구성 요소를 제어할 수 있다. 제어부(750)는 단말(740)의 전반적인 동작들을 제어할 수 있다. 예를 들어, 제어부(750)는 통신부(745)를 통해 신호를 송수신할 수 있다. 또한, 제어부(750)는 저장부(755)에 데이터를 기록하고 읽을 수 있다. 제어부(750)는 적어도 하나일 수 있다. 예를 들어, 제어부(750)는 통신을 위한 제어를 수행하는 CP(communication processor) 및 응용 프로그램 등 상위 계층을 제어하는 AP(application processor)를 포함할 수 있다. 일 실시 예에 따르면, 저장부(755)에 단말 저장된 Configuration 정보가 있는 경우에 제어부(750)는 해당 정보를 저장부(755)에 요청하여 화면 표시부(미도시)가 표시하거나 해당 정보를 받아서 추가적인 동작을 처리할 수 있다. 또다른 일 실시예에 따르면, 제어부(750)는 저장부(755)를 통해서 읽은 데이터 기록, 또는 제어부(750) 및 통신부(745)를 통해 수집된 정보를 매칭하여 공장에서의 프로파일 설치 선택에 참조할 수 있는 정보를 단말이 추론하는 처리 과정을 수행할 수 있다. 또한, 제어부(750)는 단말(740)에 저장된 특정 정보에 대한 사용자 동의가 필요한지 여부를 판단하고, 화면 표시부(미도시)에 표시할 수 있다.
제어부(750)는 이에 대응하는 동작을 수행하도록 단말(740)을 제어할 수 있다. 일 실시 예에 따르면, 제어부(750)는 eUICC(760)의 구동 및 제어를 담당하는 LPA, LPA가 통합 구현된 애플리케이션, 공장 설치를 관장하는 애플리케이션을 포함할 수 있다. 또한, 제어부(750)는 LPA로 또는 애플리케이션에 수신된 정보를 해석하여 CP(communication processor)에 특정 Command APDU 요청을 처리하거나 요청된 정보의 일부 또는 전체를 저장부(755)로부터 수집하여 LPA 또는 애플리케이션에 회신하는 단말 프레임워크를 포함할 수 있다.
제어부(755)는 단말(740)과 통신부(745)을 통해 eUICC(760)로부터 획득한 소정의 정보를 종합하여 IFPP 모드로 진입하는 동작을 판단하여 eUICC(760)에 IFPP로 진입할 수 있도록 제어할 수 있다. eUICC(760)은 제어부(750)의 제어에 따라 동작할 수 있다, 본 개시의 일 실시 예에 따르면, eUICC(760)는 IFPP모드로 진입하여 프로파일 설치에 대한 절차를 처리하고 해당 처리 결과를 단말(740)에 회신해 줄 수 있다. 본 개시의 일 실시 예에 따른 제어부(750)는 Factory IT(720)로부터 수신 받은 프로파일 패키지의 프로파일 정보 또는 응답 메시지를 수신하고, 수신된 프로파일 정보 또는 응답 메시지로부터 IFPP용 프로파일 설치 요청 정보가 있는지를 판단하고, 수신 시의 단말 설정 또는 사용자 입력 정보를 참조하여 공장 모드에서의 프로파일 설치를 수행할 지를 판단하고, 일반 모드로 진입할 지 IFPP 모드로 진입을 판단하고, IFPP 모드로 진입을 결정하고, IFPP로 프로파일을 설치하기 위해 eUICC(760)에 전달할 메시지를 구성하고, 프로파일 패키지의 프로파일 정보를 하나 이상의 메시지로 구성하고, 해당 메시지를 eUICC(760)에 전달할 수 있도록 제어하고, eUICC(760)로부터 단말(740)에 수신된 처리 결과를 수신하여 프로파일 설치 절차를 종료할 지 여부를 판단하고, 처리 결과를 통신부(745)에 전달하고, 통신부(745)로 하여금 처리 결과를 Factory IT(720)에 전달하도록 단말(740)을 제어할 수 있다.
저장부(755)는 단말(740)의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장할 수 있다. 본 개시에 따른 일 실시 예에서는 저장부(755)는 플래시 메모리 타입(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) 중 적어도 하나의 저장 매체를 포함할 수 있다. 저장부(755)는 제어부(750)와 SoC(System on Chip)으로 통합 구현되어 있을 수 있다. 제어부(750)는 저장부에 저장된 각종 프로그램, 컨텐츠, 데이터 등을 이용하여 다양한 동작을 수행할 수 있다.
도 7에서 eUICC(760)는 단말(740)에 내장된 UICC칩으로, 적어도 하나의 프로파일을 저장, 관리, 삭제하는 기능을 수행할 수 있다. 프로파일은 기존 UICC 카드에 저장되는 하나 또는 복수 개의 어플리케이션 및 가입자 인증정보, 전화번호부 등의 데이터 정보를 총칭할 수 있다. eUICC(760)는 도 1에서 도시한 것과 같이 단말(740)의 일부로 포함될 수 있으며 도 2 내지 도 6에서는 단말(740)과 eUICC(760)간의 동작을 설명하기 위해서 각각 별도 모듈로 표현하였다. eUICC(760)는 프로파일을 설치하기 위한 제어부, 저장부, 통신부를 포함할 수도 있다. eUICC(760)내에 애플리케이션의 일부는 제어부(750)에 설치되어 있을 수 있으며 설치되어 있는 애플리케이션은 LPA의 기능의 일부를 포함할 수도 있다.
본 개시의 일 실시 예에 따르면, eUICC(760)의 제어부는 통신부를 통해서 수신된 단말(720)의 프로파일 설치 요청 정보를 획득한 후, 해당 메시지 정보를 통해서 프로파일 패키지와 암호화 키 정보들에 대한 소정의 정보를 획득하고, eUICC(760)가 IFPP로 진입할 지 여부를 판단하여 동작을 결정하고, 이에 따라 IFPP을 위한 프로파일 설치 절차 및 수신된 정보를 eUICC(760)의 저장부에 있는 정보와 비교 검증하여 처리하고, 수신된 프로파일 패키지를 검증하여 설치에 대한 동작을 수행하고, 메시지를 구성하여 통신부를 통해 단말(740)에 처리 결과를 회신해 줄 수 있다.
다만, 도 7에서 언급하는 구성 요소가 전술한 예에 한정되는 것은 아니다. 예를 들어, Factory IT(720)는 전술한 구성 요소보다 더 많은 구성 요소를 포함하거나 더 적은 구성 요소를 포함할 수 있다. 본 문서에 개시된 다양한 실시 예들에 따른 단말(740)은 전자 디바이스가 될 수 있으며, 상기 전자 디바이스는 다양한 형태의 디바이스가 될 수 있다. 상기 전자 디바이스는, 예를 들면, 휴대용 통신 디바이스 (예: 스마트폰), 컴퓨터 디바이스, 휴대용 멀티미디어 디바이스, 휴대용 의료 기기, 카메라, 웨어러블 디바이스, 또는 가전 디바이스를 포함할 수 있다. 본 문서의 일 실시 예에 따른 전자 디바이스는 전술한 기기들에 한정되지 않는다.
도 8은 본 개시의 일 실시 예에 따른 무선 통신 시스템에서의 Factory IT 의 구조를 나타내 블록도이다. 구체적으로, 도 8은 도 7의 Factory IT(720)에 대한 구성의 일 예를 도시한다.
도 8을 참조하면, Factory IT(800)는 중앙 제어장치(815)와 통신장치 1(810), 저장장치(820)과 통신장치 2(825)로 구성될 수 있다. 저장 장치(820)는 특정 공장에서 프로파일 설치를 위한 eUICC 데이터(암호화 키, 인증서 등 정보) 또는 설치할 프로파일들을 저장하는 서버일 수 있다. 통신장치 2(825)는 저장 장치를 포함하는 장치로 프로파일을 주입할 단말(830)의 접점에 있는 장치(예를 들어, PC)로, 저장 장치(820)로부터 설치를 처리할 단말들의 프로파일들을 수신 받아 저장하고 있다가, 단말(830)에 유무선으로 연결하여 프로파일 주입을 위한 일련의 명령을 전송하고, 단말(830)로부터 명령에 대한 처리 결과를 수신하는 역할을 수행할 수 있다. OEM 내부의 공장에서 프로파일을 설치하는 데 관여하는 장치들, 일 예로 저장 장치(820)와 통신장치 2(825)는 사내 망으로만 연결되어 사외 통신 연결을 지원하지 않을 수 있다. 사외 통신 연결을 지원하지 않는 경우, 통신장치 1(810)이 외부 연결의 접점에 있는 장치로써 프로파일 서버/서버 벤더(865)에 BPP를 요청하거나 또는 요청한 결과로 BPP를수신할 수 있다. 또는, 사외 통신 연결을 지원하지 않는 경우, 통신 장치1(810)이 프로파일 설치 결과를 프로파일 서버/서버 벤더(805)에 전송을 수행할 수 있다. 외부 장치와 연결을 제공하는 통신 장치 1(810)은 저장 장치(820), 저장 장치가 포함된 통신 장치2(825)와는 직접적인 연결을 제공하지 않을 수 있다. 이에 따라, 단말(830)에 프로파일을 설치하고 나서 설치 결과를 통신장치 2(825)로부터 수신 받아 저장하는 저장장치(820)와 설치 결과를 프로파일 서버/서버 벤더(805)에 실시간 또는 일괄로 모아서 특정 시점에 전달하는 역할을 하는 장치인 통신 장치 1(810)은 서로 다른 장치일 수도 있다.
본 문서의 다양한 실시 예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시 예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 상기 아이템 한 개 또는 복수 개를 포함할 수 있다. 본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나","A 또는 B 중 적어도 하나,""A, B 또는 C," "A, B 및 C 중 적어도 하나,"및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제 1", "제 2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제 1) 구성요소가 다른(예: 제 2) 구성요소에, "기능적으로" 또는 "통신적으로"라는 용어와 함께 또는 이런 용어 없이, "커플드" 또는 "커넥티드"라고 언급된 경우, 그것은 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제 3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.
본 문서에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구현된 유닛을 포함할 수 있으며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로 등의 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는, 상기 부품의 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 일 실시 예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.
본 문서의 다양한 실시 예들은 머신(machine)(예: 전자 디바이스) 의해 읽을 수 있는 저장 매체(storage medium)(예: 내장 메모리 또는 외장 메모리)에 저장된 하나 이상의 명령어들을 포함하는 소프트웨어(예: 프로그램)로서 구현될 수 있다. 예를 들면, 머신(예: 전자 디바이스)의 프로세서는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 상기 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 상기 하나 이상의 명령어들은 컴파일러에 의해 생성된 코드 또는 인터프리터에 의해 실행될 수 있는 코드를 포함할 수 있다. 기기로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, '비일시적'은 저장매체가 실재(tangible)하는 디바이스고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.
일 실시 예에 따르면, 본 문서에 개시된 다양한 실시 예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory (CD-ROM))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두 개의 사용자 디바이스들(예: 스마트폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
다양한 실시 예들에 따르면, 상기 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있다. 다양한 실시 예들에 따르면, 전술한 해당 구성요소들 중 하나 이상의 구성요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 상기 복수의 구성요소들 각각의 구성요소의 하나 이상의 기능들을 상기 통합 이전에 상기 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시 예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.
상술한 본 개시의 구체적인 실시 예들에서, 본 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. 무선 통신 시스템에서eUICC (embed universal integrated circuit card)를 구비하는 단말에 의해 수행되는 방법에 있어서,
    Factory IT 서버로부터 프로파일의 설치를 위한 BPP (bound profile package) 및 상기 BPP와 관련된 암호화 키(key) 정보를 포함하는 제1 메시지를 수신하는 동작;
    상기 제1 메시지에 기반하여, 프로파일 설정 모드에 진입하는 동작;
    상기 eUICC에게, 상기 BPP를 포함하는 제2 메시지를 송신하는 동작; 및
    상기 eUICC로부터, 프로파일의 설치 결과를 포함하는 제3 메시지를 수신하는 동작을 포함하는, 방법.
  2. 청구항 1에 있어서, 상기 제2 메시지를 송신하는 동작은,
    상기 eUICC에게, 프로파일의 설치를 위한 프로파일 설치 준비 정보를 포함하는 제4 메시지를 송신하는 동작; 및
    상기 eUICC로부터, 상기 제4 메시지에 응답한 상기 프로파일 설치 준비 정보에 기반한 검증 결과를 포함하는 제5 메시지를 수신하는 동작;
    상기 eUICC에게, 상기 제5 메시지에 기반하여 상기 BPP를 분할하여 송신하는 동작을 포함하는,
    상기 BPP는 상기 세션 키로 보호되는 것인, 방법.
  3. 청구항 1에 있어서,
    상기 암호화 키 정보는 프로파일의 설치를 특정하는 일회용 공개키를 포함하는, 방법.
  4. 청구항 1에 있어서,
    상기 BPP는 특정 eUICC에 설치되기 위한 암호화된 프로파일 패키지를 의미하며,
    상기 BPP는, 프로파일 서버(profile server)에 의해, 상기 특정 eUICC에 의해서만 복호화할 수 있는 암호화 파라미터를 이용하여 암호화된 것인, 방법.
  5. 청구항 3에 있어서,
    상기 프로파일 설치 준비 정보는, 상기 일회용 공개키를 포함하는 프로파일 데이터 및 프로파일 서버의 비밀키로 서명된 프로파일 데이터의 서명 값 중 적어도 하나를 포함하는, 방법.
  6. 청구항 5에 있어서,
    상기 검증 결과는 상기 eUICC에 의해 상기 프로파일 데이터의 상기 일회용 공개키에 대응하는 일회용 비밀키가 확인되거나, 상기 eUICC에 의해 상기 프로파일 데이터의 서명 값이 확인된 결과를 포함하는, 방법.
  7. 청구항 1에 있어서,
    상기 프로파일 설정 모드는,
    프로파일의 설치를 위한 명령(function call)을 수신하거나,
    상기 프로파일 설정 모드가 미리 설정되어 있거나, 또는
    상기 단말이 사용자의 입력을 수신하여 진입하는 것인, 방법.
  8. 청구항 1에 있어서, 상기 방법은
    상기 Factory IT 서버에게, 상기 eUICC로부터 수신한 상기 제3 메시지를 전달하는 동작을 더 포함하는, 방법.
  9. 무선 통신 시스템에서 eUICC(embed universal integrated circuit card)를 구비하는 단말에 있어서,
    송수신기(transceiver); 및
    상기 송수신기와 결합된 컨트롤러(controller)를 포함하고,
    상기 컨트롤러는,
    Factory IT 서버로부터 프로파일의 설치를 위한 BPP (bound profile package) 및 상기 BPP와 관련된 암호화 키(key) 정보를 포함하는 제1 메시지를 수신하고,
    상기 제1 메시지에 기반하여, 프로파일 설정 모드에 진입하며,
    상기 eUICC에게, 상기 BPP를 포함하는 제2 메시지를 송신하고,
    상기 eUICC로부터, 프로파일의 설치 결과를 포함하는 제3 메시지를 수신하도록 설정되는, 단말.
  10. 청구항 9에 있어서, 상기 컨트롤러는,
    상기 eUICC에게, 프로파일의 설치를 위한 프로파일 설치 준비 정보를 포함하는 제4 메시지를 송신하고,
    상기 eUICC로부터, 상기 제4 메시지에 응답한 상기 프로파일 설치 준비 정보에 기반한 검증 결과를 포함하는 제5 메시지를 수신하며,
    상기 eUICC에게, 상기 제5 메시지에 기반하여 상기 BPP를 분할하여 송신하도록 설정되고,
    상기 BPP는 상기 세션 키로 보호되는 것인, 단말.
  11. 청구항 9에 있어서,
    상기 암호화 키 정보는 프로파일의 설치를 특정하는 일회용 공개키를 포함하는, 단말.
  12. 청구항 9에 있어서,
    기 BPP는 특정 eUICC에 설치되기 위한 암호화된 프로파일 패키지를 의미하며,
    상기 BPP는, 프로파일 서버(profile server)에 의해, 상기 특정 eUICC에 의해서만 복호화할 수 있는 암호화 파라미터를 이용하여 암호화된 것인, 단말.
  13. 청구항 11에 있어서,
    상기 프로파일 설치 준비 정보는, 상기 일회용 공개키를 포함하는 프로파일 데이터 및 프로파일 서버의 비밀키로 서명된 프로파일 데이터의 서명 값 중 적어도 하나를 포함하는, 단말.
  14. 청구항 13에 있어서,
    상기 검증 결과는 상기 eUICC에 의해 상기 프로파일 데이터의 상기 일회용 공개키에 대응하는 일회용 비밀키가 확인되거나, 상기 eUICC에 의해 상기 프로파일 데이터의 서명 값이 확인된 결과를 포함하는, 단말.
  15. 청구항 9에 있어서,
    상기 프로파일 설정 모드는,
    프로파일의 설치를 위한 명령(function call)을 수신하거나,
    상기 프로파일 설정 모드가 미리 설정되어 있거나, 또는
    상기 단말이 사용자의 입력을 수신하여 진입하는 것인, 단말.
PCT/KR2023/011123 2022-08-12 2023-07-31 무선 통신 시스템에서, 프로파일을 프로비저닝하기 위한 방법 및 장치 WO2024034949A1 (ko)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
KR20220101535 2022-08-12
KR10-2022-0101535 2022-08-12
KR10-2022-0160219 2022-11-25
KR1020220160219A KR20240022967A (ko) 2022-08-12 2022-11-25 무선 통신 시스템에서, 프로파일을 프로비저닝하기 위한 방법 및 장치
KR10-2023-0038787 2023-03-24
KR1020230038787A KR20240022974A (ko) 2022-08-12 2023-03-24 무선 통신 시스템에서, 프로파일을 프로비저닝하기 위한 방법 및 장치
KR1020230073672A KR20240022979A (ko) 2022-08-12 2023-06-08 무선 통신 시스템에서, 프로파일을 프로비저닝하기 위한 방법 및 장치
KR10-2023-0073672 2023-06-08
KR1020230093155A KR20240022985A (ko) 2022-08-12 2023-07-18 무선 통신 시스템에서, 프로파일을 프로비저닝하기위한 방법 및 장치
KR10-2023-0093155 2023-07-18

Publications (1)

Publication Number Publication Date
WO2024034949A1 true WO2024034949A1 (ko) 2024-02-15

Family

ID=89852088

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/011123 WO2024034949A1 (ko) 2022-08-12 2023-07-31 무선 통신 시스템에서, 프로파일을 프로비저닝하기 위한 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2024034949A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180060199A1 (en) * 2016-08-24 2018-03-01 Apple Inc. LOCAL RECOVERY OF ELECTRONIC SUBSCRIBER IDENTITY MODULE (eSIM) INSTALLATION FLOW
US20200045544A1 (en) * 2017-03-31 2020-02-06 Huawei Technologies Co., Ltd. Method for adding authentication algorithm program, and relevant device and system
WO2021047765A1 (en) * 2019-09-10 2021-03-18 Telefonaktiebolaget Lm Ericsson (Publ) Profile handling of a batch of identity modules
US10985926B2 (en) * 2017-09-01 2021-04-20 Apple Inc. Managing embedded universal integrated circuit card (eUICC) provisioning with multiple certificate issuers (CIs)
KR20220109239A (ko) * 2021-01-28 2022-08-04 삼성전자주식회사 eSIM (embedded Subscriber Identity Module) Profile을 활용하여 네트워크에 접속하는 방법 및 전자 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180060199A1 (en) * 2016-08-24 2018-03-01 Apple Inc. LOCAL RECOVERY OF ELECTRONIC SUBSCRIBER IDENTITY MODULE (eSIM) INSTALLATION FLOW
US20200045544A1 (en) * 2017-03-31 2020-02-06 Huawei Technologies Co., Ltd. Method for adding authentication algorithm program, and relevant device and system
US10985926B2 (en) * 2017-09-01 2021-04-20 Apple Inc. Managing embedded universal integrated circuit card (eUICC) provisioning with multiple certificate issuers (CIs)
WO2021047765A1 (en) * 2019-09-10 2021-03-18 Telefonaktiebolaget Lm Ericsson (Publ) Profile handling of a batch of identity modules
KR20220109239A (ko) * 2021-01-28 2022-08-04 삼성전자주식회사 eSIM (embedded Subscriber Identity Module) Profile을 활용하여 네트워크에 접속하는 방법 및 전자 장치

Similar Documents

Publication Publication Date Title
WO2016080726A1 (en) Apparatus and method for profile installation in communication system
WO2018101775A1 (en) Apparatus and method for installing and managing esim profiles
WO2018008972A1 (en) Method and apparatus for accessing cellular network for sim profile
WO2016163796A1 (en) Method and apparatus for downloading a profile in a wireless communication system
WO2016024695A1 (en) Method and apparatus for profile download of group devices
WO2017052136A1 (ko) 이동 통신 시스템에서 프로파일 다운로드 방법 및 장치
WO2016178548A1 (ko) 프로파일 제공 방법 및 장치
WO2016153281A1 (ko) 무선 통신 시스템에서 프로파일을 다운로드 하는 방법 및 장치
WO2019050325A1 (en) METHOD AND APPARATUS FOR SUPPORTING PROFILE TRANSFER BETWEEN DEVICES IN A WIRELESS COMMUNICATION SYSTEM
WO2016003200A1 (en) Method and apparatus for installing profile for euicc
WO2018147711A1 (en) APPARATUS AND METHOD FOR ACCESS CONTROL ON eSIM
WO2021066569A1 (en) Method and apparatus for reinstalling sim profile in wireless communication system
WO2020226466A1 (en) Method and apparatus for managing and verifying certificate
WO2020171475A1 (ko) 무선 통신 시스템의 기기변경 방법 및 장치
WO2022108357A1 (en) Method and apparatus for handling profiles by considering removable euicc supporting multiple enabled profiles
EP3530016A1 (en) Apparatus and method for installing and managing esim profiles
WO2022139373A1 (en) Method and apparatus to manage authentication and subscription information in wireless communication system
WO2022031148A1 (en) Method and apparatus for installing and managing multiple esim profiles
WO2014171711A1 (ko) 이동 통신에서 가입 사업자 변경 제한 정책을 지원하는 정책 적용 방법 및 장치
WO2020184995A1 (ko) Euicc 단말을 변경하는 방법 및 장치
WO2024034949A1 (ko) 무선 통신 시스템에서, 프로파일을 프로비저닝하기 위한 방법 및 장치
WO2022092976A1 (en) Method and device for managing communication bundle of smart secure platform
WO2022045869A1 (en) Apparatus and method for managing events in communication system
WO2024072114A1 (ko) 무선 통신 시스템에서 프로파일 프로비저닝을 위한 euicc의 암호화 키 관리 방법 및 장치
WO2024101925A1 (ko) 무선 통신 시스템에서 프로파일 프로비저닝을 위한 euicc의 암호화 키 생성 방법 및 장치

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: 23852830

Country of ref document: EP

Kind code of ref document: A1