WO2016167551A1 - 통신 시스템에서 프로파일을 관리하는 기법 - Google Patents

통신 시스템에서 프로파일을 관리하는 기법 Download PDF

Info

Publication number
WO2016167551A1
WO2016167551A1 PCT/KR2016/003858 KR2016003858W WO2016167551A1 WO 2016167551 A1 WO2016167551 A1 WO 2016167551A1 KR 2016003858 W KR2016003858 W KR 2016003858W WO 2016167551 A1 WO2016167551 A1 WO 2016167551A1
Authority
WO
WIPO (PCT)
Prior art keywords
euicc
profile
certificate
message
information
Prior art date
Application number
PCT/KR2016/003858
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
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to EP19181026.6A priority Critical patent/EP3562184B1/en
Priority to AU2016247689A priority patent/AU2016247689B2/en
Priority to KR1020177032815A priority patent/KR102558361B1/ko
Priority to US15/566,561 priority patent/US10439823B2/en
Priority to CN201680029919.0A priority patent/CN107873137B/zh
Priority to EP16780274.3A priority patent/EP3297309B1/en
Publication of WO2016167551A1 publication Critical patent/WO2016167551A1/ko
Priority to US16/594,752 priority patent/US10965470B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • 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
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • 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/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present disclosure relates to a method and an apparatus for downloading and installing a communication service in a communication system to a communication connection, and a method and an apparatus for downloading and installing a profile in a communication system in real time.
  • a 5G communication system or a pre-5G communication system is called a system after a 4G network (Beyond 4G Network) or a system after an LTE system (Post LTE).
  • 5G communication systems are being considered for implementation in the ultra-high frequency (mmWave) band (e.g., 60 gigabyte (60 GHz) band).
  • mmWave ultra-high frequency
  • 5G communication system beamforming, massive array multiple input / output (Full-Dimensional MIMO), and full dimensional multiple input / output (FD-MIMO) are used in 5G communication system to increase path loss mitigation of radio waves and increase the transmission distance of radio waves.
  • Array antenna, analog beam-forming, and large scale antenna techniques are discussed.
  • 5G communication systems have advanced small cells, advanced small cells, cloud radio access network (cloud RAN), ultra-dense network (ultra-dense network) , Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, Coordinated Multi-Points (CoMP), and interference cancellation The development of such technology is being done.
  • Hybrid FSK and QAM Modulation FQAM
  • SWSC sliding window superposition coding
  • ACM Advanced Coding Modulation
  • FBMC Fan Bank Multi Carrier
  • NOMA NOMA
  • SAP Non orthogonal multiple access
  • SCMA sparse code multiple access
  • IoT Internet of Things
  • M2M Machine Type Communication
  • MTC Machine Type Communication
  • 5G communication system technologies such as sensor network, machine to machine (M2M), machine type communication (MTC), and the like
  • 5G communication technologies are implemented by techniques such as beamforming, MIMO, and array antennas. It is.
  • cloud radio access network (cloud RAN) as the big data processing technology described above may be an example of convergence of 5G technology and IoT technology.
  • a UICC Universal Integrated Circuit Card
  • the UICC may include a connection control module for accessing a network of a mobile network operator (MNO). Examples of such access control modules include a universal subscriber identity module (USIM), a subscriber identity module (SIM), and an IP multimedia service identity module (ISIM).
  • USIM universal subscriber identity module
  • SIM subscriber identity module
  • ISIM IP multimedia service identity module
  • a UICC containing a USIM is also commonly called a USIM card.
  • a UICC containing a SIM module is commonly referred to as a SIM card.
  • a UICC card may be used in a conventional meaning including a SIM card, a USIM card, a UICC including an ISIM, and the like. That is, the technical content described as the UICC card can be equally applied to a USIM card, an ISIM card, or a general SIM card.
  • the UICC card stores personal information of a mobile communication subscriber and enables secure mobile communication by performing subscriber authentication and generating a traffic secure key when accessing a mobile communication network.
  • the UICC card is generally manufactured as a dedicated card for the corresponding MNO at the request of a specific mobile communication service provider (ie, MNO) when the card is manufactured, and an example of authentication information for network access of the corresponding MNO is provided.
  • MNO mobile communication service provider
  • the Universal Subscriber Identity Module (USIM) application, the International Mobile Subscriber Identity (IMSI), the K value, the OPc value, and the like may be pre-loaded onto the card.
  • the manufactured UICC card is delivered to the subscriber by the corresponding mobile carrier, and if necessary, management of installation, modification, and deletion of the application in the UICC may be performed by using technologies such as OTA (Over The Air). Can be.
  • the subscriber inserts the UICC card into the owned mobile communication terminal to use the network and application services of the corresponding mobile communication provider.
  • the subscriber can move the UICC card from the existing terminal to the new terminal to store the UICC card.
  • Authentication information, mobile phone number, personal phone book, etc. can be used in the new terminal as it is.
  • the UICC card is inconvenient for the user of the mobile communication terminal to receive services of other mobile communication companies.
  • the mobile terminal user has an inconvenience of physically obtaining a UICC card in order to receive a service from a mobile communication provider.
  • a user travels to another country, it is inconvenient to obtain a local UICC card in order to receive a local mobile communication service.
  • a roaming service to solve the above inconvenience to some extent, there is a problem that can not receive the service if there is a high rate and a contract between the carriers.
  • the SIM module of the mobile communication service to be used at the time desired by the user may be downloaded to the UICC card.
  • Such a UICC card can also download and install a plurality of SIM modules and select and use only one SIM module therein.
  • Such a UICC card may or may not be fixed to the terminal.
  • a UICC fixed to a terminal is called an eUICC (embedded UICC).
  • an eUICC is used to be fixed to a terminal, and means a UICC card that can be downloaded by selecting a SIM module remotely from a server.
  • the profile must be downloaded and installed from the eUICC. Therefore, eUICC profile management technique is required.
  • the present disclosure provides a method and apparatus for downloading, in real time, a profile for a terminal to establish a communication connection in a communication system.
  • the present disclosure also provides an apparatus and method for providing a profile to a terminal in a communication system.
  • the present disclosure provides a profile installation method of a terminal having an embedded universal integrated circuit card (eUICC) in a mobile communication system, the method comprising: requesting an eUICC certificate from an eUICC and receiving the eUICC certificate; Requesting the eUICC information from the eUICC to receive the eUICC information; Transmitting a download initialization message including the eUICC information to a profile providing server; Receiving a response message to the download initialization message including a certificate of the profile providing server and a signature value of the profile providing server; Transmitting a certificate of the profile providing server and a signature value of the profile providing server included in the response message to the eUICC; Receiving a disposable public key of the eUICC and a signature value of the eUICC from the eUICC; Transmitting a profile package request message including a one-time public key of the eUICC and a signature value of the eUICC to the profile providing server; And installing the profile by transmitting the received profile package to
  • the present disclosure provides a terminal device having an embedded universal integrated circuit card (eUICC) in a mobile communication system, requesting an eUICC certificate from an eUICC to receive the eUICC certificate, and requesting the eUICC information from the eUICC to obtain the eUICC information.
  • eUICC embedded universal integrated circuit card
  • Receive and transmit a download initialization message including the eUICC information to a profile providing server receive a response message to the download initialization message including a certificate of the profile providing server and a signature value of the profile providing server, Delivering the certificate of the profile providing server and the signature value of the profile providing server included in the response message to the eUICC, receiving the one-time public key of the eUICC and the signature value of the eUICC from the eUICC, 1 of the eUICC Profile package containing a private public key and the signature value of the eUICC
  • a control unit for transmitting the request message to the profile providing server and controlling the installation of the profile by transferring the received profile package to the eUICC in response to the profile package request message;
  • a transceiver configured to perform the reception or transmission operation under the control of the controller, wherein the received eUICC certificate further includes an eUICC manufacturer (EUM) certificate.
  • EUM eUICC manufacturer
  • an apparatus and method for communication connection by downloading and installing a profile in a communication system are provided.
  • an apparatus for transmitting a profile and an apparatus for transmitting profile information and a method of operating the same are provided so that the profile can be downloaded from the apparatus.
  • a profile capable of using a communication service may be installed in a mobile communication terminal.
  • FIG. 1 is a diagram illustrating a method of connecting a mobile communication network of a terminal using a UICC having a fixed profile mounted on the terminal;
  • FIG. 2 illustrates the overall structure of a system for remote profile installation and management of eUICC
  • FIG. 3 is a diagram for explaining an internal structure of an eUICC
  • FIG. 4 illustrates a configuration of a terminal in accordance with a manner in which an LPA function is implemented
  • 5A and 5B are diagrams illustrating how an eUICC of a terminal downloads a profile in a communication system
  • 6A, 6B illustrate another method of profile installation according to the present disclosure
  • 7A, 7B, and 7C illustrate a method of provisioning bulk profiles for multiple terminals at once
  • FIG. 8 is a diagram illustrating a configuration of a terminal device of the present disclosure.
  • FIG. 9 is a diagram illustrating a configuration of a server device according to the present disclosure.
  • a UICC card that can be downloaded by selecting a SIM module remotely is called an eUICC. That is, among the UICC cards that can be downloaded by selecting the SIM module remotely, the UICC card that is fixed or not fixed to the terminal is collectively referred to as eUICC.
  • the SIM module information downloaded to the eUICC is collectively referred to as the term eUICC profile (profile).
  • the UICC is a smart card that is inserted into a mobile communication terminal and used to store personal information such as network access authentication information, a phone book, and a short message service (SMS) of a mobile communication subscriber. It refers to a chip that enables secure mobile communication by performing subscriber authentication and traffic security key generation when accessing a mobile communication network such as wideband code division multiple access (WCDMA) and long term evolution (LTE).
  • WCDMA wideband code division multiple access
  • LTE long term evolution
  • UICC is equipped with communication applications such as Subscriber Identification Module (SIM), Universal SIM (USIM), and IP Multimedia SIM (ISIM) according to the type of mobile communication network to which the subscriber is connected. It can provide a high level security function for mounting various application applications.
  • an embedded UICC may be a security module in a chip form that is not removable but may be inserted into or detached from the terminal.
  • eUICC can download and install profiles using OTA (Over The Air) technology.
  • OTA Over The Air
  • the eUICC may be named as a UICC capable of downloading and installing a profile.
  • a method of downloading and installing a profile using the OTA technology in the eUICC may be applied to a removable UICC that can be inserted into and removed from the terminal. That is, in the embodiment of the present disclosure, it may be applied to a UICC that can download and install a profile using an OTA technology.
  • UICC may be used interchangeably with SIM
  • eUICC may be used interchangeably with eSIM
  • a profile may mean packaging of an application, a file system, an authentication key value, and the like stored in the UICC in software form.
  • 'USIM profile' may mean the same meaning as 'profile' or packaged information included in the USIM application in the profile in software form.
  • the 'provisioning profile' is a profile for downloading another profile such as the 'USIM profile', and may be pre-loaded in the eUICC at the production stage.
  • the profile providing server includes a subscription manager data preparation (SM-DP), a subscription manager data preparation plus (SM-DP +), an off-card entity of profile domain, a profile encryption server, and a profile. It may be represented as a generation server, a profile provider (PP), a profile provider, and a PPC holder (Profile Provisioning Credentials holder).
  • the profile information delivery server may be represented by a discovery and push function (DPF) or a subscription manager discovery service (SM-DS).
  • DPF discovery and push function
  • SM-DS subscription manager discovery service
  • the profile management server may include a subscription manager secure routing (SM-SR), a subscription manager secure routing (SM-SR +), an off-card entity of eUICC Profile Manager, or a PMC holder (SM-SR +). It may be represented as a Profile Management Credentials holder (EM), an eUICC Manager (EM).
  • SM-SR subscription manager secure routing
  • EM Profile Management Credentials holder
  • EM eUICC Manager
  • the profile providing server (or SM-DP +) may collectively refer to a combination of the functions of the profile providing server and the profile management server. That is, in the following description, it should be noted that the operation of the profile provision server may be performed in the profile management server. Similarly, the operation described with respect to the profile management server (or SM-SR +) may be performed at the profile providing server, of course.
  • the term 'terminal' refers to a mobile station (MS), a user equipment (UE), a user terminal (UT), a wireless terminal, an access terminal, a terminal, a subscriber unit. ), A subscriber station (SS), a wireless device, a wireless communication device, a wireless transmit / receive unit (WTRU), a mobile node, mobile, or other terms.
  • the terminal is photographed such as, for example, a cellular telephone, a smart phone having a wireless communication function, a personal digital assistant (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, or a digital camera having a wireless communication function.
  • PDA personal digital assistant
  • the terminal may include a machine to machine (M2M) terminal, a machine type communication (MTC) terminal / device, but is not limited thereto.
  • M2M machine to machine
  • MTC machine type communication
  • the terminal may be referred to as an electronic device.
  • the electronic device may include a UICC that can download and install a profile. If the UICC is not embedded in the electronic device, the UICC physically separated from the electronic device may be inserted into the electronic device and connected to the electronic device.
  • the UICC may be inserted into the electronic device in the form of a card.
  • the electronic device may include the terminal, and in this case, the terminal may be a terminal including a UICC that can download and install a profile.
  • the UICC may be embedded in the terminal, when the terminal and the UICC is separated, the UICC may be inserted into the terminal and may be inserted into the terminal and connected to the terminal.
  • the UICC which can download and install a profile may be called eUICC, for example.
  • the profile identifier may be referred to as a profile ID, an integrated circuit card ID (ICCID), an Issuer Security Domain Profile (ISD-P), or a factor matching a profile domain (PD).
  • the profile ID may indicate a unique identifier of each profile.
  • the eUICC identifier may be a unique identifier of the eUICC embedded in the terminal and may be referred to as an EID.
  • the eUICC identifier may be an identifier of the provisioning profile (Profile ID of Provisioning Profile).
  • the eUICC identifier may be a terminal ID.
  • the eUICC identifier may refer to a specific secure domain (Secure Domain) of the eUICC chip.
  • a profile container may be referred to as a profile domain.
  • the profile container may be a security domain.
  • the application protocol data unit may be a message for the UE to interwork with the eUICC.
  • the APDU may be a message for the profile providing server or the profile management server to interwork with the eUICC.
  • PPC Profile Provisioning Credentials
  • PPC may be a means used for mutual authentication, profile encryption, and signing between the profile provision server and the eUICC.
  • PPC is a symmetric key, a risk shamir adleman (RSA) certificate and a private key, an elliptic curved cryptography (ECC) certificate and private key, a root certification authority (CA), and a certificate chain.
  • RSA risk shamir adleman
  • ECC elliptic curved cryptography
  • CA root certification authority
  • certificate chain May include one or more of the following.
  • different PPCs may be stored or used in the eUICC for each of the plurality of profile providing servers.
  • Profile Management Credentials may be a means used for mutual authentication, transmission data encryption, and signing between the profile management server and the eUICC.
  • the PMC may include one or more of a symmetric key, an RSA certificate and a private key, an ECC certificate and a private key, a root CA, and a certificate chain.
  • different PMCs for each of the plurality of profile management servers may be stored or used in the eUICC.
  • the AID is an application identifier and may distinguish different applications within the eUICC.
  • a profile package TLV may be referred to as a profile TLV.
  • the Profile Package TLV may be a data set representing information constituting the profile in a TLV (Tag, Length, Value) format.
  • Authentication and Key agreement may represent AKA authentication and key agreement, may refer to an authentication algorithm for connection to the 3GPP (3 rd generation partnership project) and 3GPP2 networks.
  • K is an encryption key value used in the AKA authentication algorithm and stored in the eUICC.
  • OPc is a parameter value that is used in the AKA authentication algorithm and can be stored in the eUICC.
  • a network access application is a network access application and may be an application program such as USIM or ISIM for accessing a network stored in a UICC.
  • the NAA may be a network access module.
  • FIG. 1 is a diagram illustrating a method for connecting a mobile communication network of a terminal using a UICC having a fixed profile mounted on the terminal.
  • the UICC 120 may be inserted into the terminal 110.
  • the UICC 120 may be removable or may be pre-built in the terminal.
  • the fixed profile of the UICC on which the fixed profile is mounted means that 'access information' for accessing a specific communication company is fixed.
  • the access information may be, for example, an International Mobile Subscriber Identity (IMSI), which is a subscriber identifier, and a K or Ki value required for network authentication together with the subscriber identifier.
  • IMSI International Mobile Subscriber Identity
  • the terminal can perform authentication with a mobile communication company's authentication processing system (eg, HLR (home location register) or AuC (Authentication Center)) using the UICC.
  • the authentication process may be an AKA (Authentication and Key Agreement) process. If the authentication is successful, the terminal can use a mobile communication service such as telephone or mobile data using the mobile communication network 130 of the mobile communication system.
  • FIG. 2 is a diagram illustrating the overall structure of a system for remote profile installation and management of eUICC.
  • the eUICC 232 is a UICC card or chip of a type embedded in or detachable from the terminal 230.
  • the eUICC 232 may have a form factor of 2FF, 3FF, 4FF, MFF1, or MFF2, or may have various other physical sizes.
  • the eUICC may be implemented as a device separate from the terminal and attached to the terminal, but may be integrated and implemented in a communication chip (for example, a communication processor (CP) or a baseband modem) of the terminal. It may be.
  • CP communication processor
  • the profile provider server (PP) 200 may perform a function of generating a profile or encrypting the generated profile.
  • the profile provision server 200 may be referred to as SM-DP +.
  • the profile management server (eUICC Manager; EM) 202 may transfer the profile received from the SM-DP + to the Local Profile Assistant (LPA) of the terminal 230 and may manage the profile.
  • the profile management server 202 may be referred to as SM-SR +.
  • the SM-SR + 202 may control a profile download or profile management operation between the SM-DP + 200 and the terminal 230 (ie, LPA).
  • the profile providing server 200 and the profile management server 202 may be implemented as one server, and the one server may be referred to as SM-DP + or SM +.
  • the profile information delivery server 204 (that is, the DPF) may receive the SM-SR + server address or event identifier from the SM-SR + and deliver it to the LPA 230.
  • system may further include a mobile network operator (MNO) 210, an eUICC manufacture (eUICC) 220, or a certificate issuer (CI).
  • MNO mobile network operator
  • eUICC eUICC manufacture
  • CI certificate issuer
  • the MNO 210 is involved in the process of downloading and managing profiles, and can provide mobile communication services by request from the eUICC where the profile is installed.
  • the eUICC manufacturer (EUM) 220 may issue an eUICC certificate by signing the certificate content with a private key.
  • Certificate issuer 240 may issue an EUM certificate, EM certificate, or PP certificate by signing the certificate content with a private key.
  • FIG. 2 shows an interface between a server and a server (for example, ES3), an interface between a terminal and a server (for example, ES9), an interface between the terminal and the eUICC (for example, ES10), and the like.
  • a server for example, ES3
  • a terminal for example, ES9
  • eUICC for example, ES10
  • 3 is a view for explaining the internal structure of the eUICC.
  • the eUICC 300 may basically be in the form of a card or a chip, but at least one profile 320 or 330 in a software format may be installed. Thus, the eUICC may operate on an eUICC operating system (OS) 302. 3 shows that two profiles 320 and 330 are mounted in the eUICC 300. Currently, one profile 320 is in an enable state, and the other profile 33 is in a disabled state. Indicates that
  • the terminal API function (TAF) 306 receives a remote management function (RMF) and a local management function (LMF) defined in the terminal (ie, LPA) and directly processes it, or another function (eg, for example) inside the eUICC 300. , CMF 308 or PEF 316).
  • the TAF 306 may be the same as or different from the Issuer Security Domain Root (ISD-R) of the eUICC.
  • ISD-R Issuer Security Domain Root
  • ISD-R 304 is a secure domain located at the base of eUICC 300.
  • Certificate Management Function (CMF) 308 may store the following data (or information) in the eUICC (300).
  • the CMF 308 may perform at least one of the following operations.
  • the Policy Enforcement Function (PEF) 316 serves to execute the Policy Rule 314 set in the eUICC 300.
  • the policy rule 314 includes a Profile Policy Rule (PPR) and an eUICC Policy Rule (EPR).
  • the Profile Policy Rule may be stored in a profile, controlled by an OTA key of an MNO, or controlled by a signature value of a specific SM-DP +.
  • the eUICC Policy Rule is stored outside the profile and can be controlled by a specific SM-DP + signature value or a specific SM-SR + signature value.
  • the eUICC Policy Rule may be composed of an owner ID for a policy rule and a rule to be set.
  • the owner ID may be an ID of a server that owns a valid certificate and private key of SM-DP + or SM-SR +.
  • PPI Profile Package Interpreter 310 is a function of interpreting the decoded profile information and installing it in an installable unit. PPI may also be referred to as Profile Interpreter Function (PIF).
  • PPI Profile Interpreter Function
  • the profile registry 312 may include individual profile information for managing individual profiles installed in the eUICC 300, that is, profile records.
  • the eUICC 300 may use the information received from the SM-DP + or SM-SR + to build a profile record as part of the profile registry, and then use the profile to manage the profile later.
  • Table 1 below shows an example of configuring information (ie, ProifileRegisty) of the profile registry 312.
  • ProfileRecord may include one or more of the following information.
  • ProfileRecord may be referred to as ProfileMetadata.
  • FIG. 4 is a diagram illustrating a configuration of a terminal according to a method in which an LPA function is implemented.
  • the terminal may include an LPA (Local Profile Assistant) that communicates with the server to support profile download, installation, and management operations of the eUICC.
  • the LPA may be implemented by an application processor (AP) and a communication processor (CP).
  • AP application processor
  • CP communication processor
  • the LPA function of the terminal may include at least one of a remote management function (RMF), a local management function (LMF), and a user interface function (UIF).
  • RMF remote management function
  • LMF local management function
  • UPF user interface function
  • RMF Remote Management Function
  • SM-SR + SM-SR +
  • SM-DP + SM-DS
  • LMF Layer Management Function
  • eUICC remote management Function
  • the RMF may support profile download / enable / disable / delete operations and policy rule download operations initiated by the network.
  • LMF Local Management Function
  • the LMF may support a profile enable / disable / delete operation or an eUICC reset operation initiated by the terminal.
  • the LMF may interface with the SM-SR + for result notification.
  • UIF User Interface Function
  • the UIF may include a UI for transmitting a user input to the LMF.
  • LPA 410 includes AP 412 and CP 414, but RMF, LMF, UIF are all implemented by AP 412 in LPA 410.
  • the AP 412 may interface with the SM-DS 400, the SM-SR + 402, and a user to perform a management event of the eUICC 420.
  • LPA 440 includes AP 442 and CP 444, but both RMF and LMF are implemented by CP 444 within LPA 440.
  • the CP 444 may interface with the SM-DS 430 and the SM-SR + 432 to perform a management event of the eUICC 450.
  • FIG. 4 (c) illustrates a case where the function of the LPA is implemented in a hybrid manner.
  • RMF LMF is implemented by CP 474 in LPA 470
  • UIF is implemented by AP 472 in LPA 470.
  • the UIF may interface with the LMF in the user 464 and the CP 474 to perform a management event of the eUICC 480
  • the RMF in the CP 474 may be SM-DS 460 or SM-SR +
  • the management event of the eUICC 480 may be performed by interfacing with 462.
  • 5A and 5B are diagrams illustrating how an eUICC of a terminal downloads a profile in a communication system.
  • the SM-DP + 500 may communicate with the LPA 502 directly using the IP-based HTTPS without the SM-SR +.
  • SM-DP + uses SM-DP + 's certificate for DP used for digital signature verification (SK.DP.ECDSA) and private key of DP for digital signature verification (SK.DP.ECDSA). Can be stored in internal storage.
  • the SM-DP + 500 is a server certificate (TLT.DP.TLS; certificate of DP used for TLS) and a private key (SK.DP.TLS; private key of DP for TLS) for HTTPS. ) Can also be stored in internal storage.
  • the internal storage in which the certificates CERT.DP.ECDSA, SK.DP.ECDSA, CERT.DP.TLS, and SK.DP.TLS are stored may be physically the same storage device or different storage devices.
  • the eUICC 504 can store eUICC's certificate for signing (CERT.EUICC.ECDSA; certificate of eUICC used for digital signature verification) and private key (SK.eUICC.ECDSA; private key of eUICC for digital signature verification) in its internal storage. have.
  • CERT.EUICC.ECDSA certificate of eUICC used for digital signature verification
  • SK.eUICC.ECDSA private key of eUICC for digital signature verification
  • the profile download process of the terminal is as follows.
  • the eUICC 504 may return the eUICC certificate CERT.eUICC.ECDSA to the LPA 502. (512). In this case, the eUICC 504 may return not only the eUICC certificate but also an EUM certificate CERT.EUM.ECDSA (: certificate of EUM used for digital signature verification). Alternatively, if the eUICC certificate or the EUM certificate were stored in the LPA 502, the operations 510 and 512 may not be performed.
  • the LPA 502 may request the signature value generation by sending an ES10b.GetSignature message to the eUICC 504.
  • the parameters included in the signature are values passed by the LPA 502.
  • the values include EventID (identifier that identifies a specific profile download event), NotificationID (similar to EventID), MatchingID (similar to EventID), and Activation Code Token (Similar to EventID), and a random value generated by the terminal.
  • the LPA 502 may request the eUICC information (eUICC Info) by transmitting an ES10b.GetEUICCInfo message to the eUICC 504 (514). .
  • the eUICC 504 generates 516 an eUICC challenge in response to the request 514 of the LPA 502.
  • the eUICC challenge is a random value generated by the eUICC 504 to later authenticate the SM-DP + 500.
  • the eUICC 504 may return 518 eUICC_Info to the LPA 502.
  • the eUICC_Info may include an eUICC challenge or version information of an eUICC.
  • the LPA 502 may call the ES9 + .InitiateDownload message to the SM-DP + 500 (520).
  • An HTTPS session connection may be established between the LPA and the SM-DP + before the call of the ES9 + .InitiateDownload message.
  • the same session may be used in the entire profile download process, or a different session may be used for each process.
  • the ES9 + .InitiateDownload may be ES9.InitiateAuthentication or ES9.EventRequest.
  • the ES9 + .InitiateDownload message may include eUICC Info, and may include, for example, an eUICC Challenge generated by the eUICC 504.
  • the ES9 + .InitiateDownload message may include an eUICC certificate or an EUM certificate.
  • the SM-DP + 500 uses a CI certificate or a public key of CI used for digital signature verification (PK.CI.ECDSA). EUM certificate can be verified.
  • the SM-DP + 500 may verify an eUICC certificate by using the verified EUM certificate and verify an eUICC signature value by using the eUICC certificate.
  • the certificate verification and signature verification may be omitted.
  • the SM-DP + 500 may check the eligibility of the eUICC 504 based on the eUICC_Info (522). In this case, the SM-DP + 500 may check suitability of the eUICC 504 by using eUICC version information of eUICC_Info.
  • the SM-DP + 500 may generate a random value DP challenge (522).
  • the DP Challenge is a value generated later by the SM-DP + 500 to authenticate the eUICC 504.
  • the SM-DP + 500 may generate a TransactionID (522).
  • the TransactionID is an identifier for distinguishing a specific profile download session so that the SM-DP + 500 can process a plurality of terminal requests at the same time. If not distinguished by the TransactionID, the SM-DP + 500 can download a profile for only one terminal at a time. You will not be able to. In order to solve such a download failure, the SM-DP + 500 may delete a session after a certain time by applying a lifetime of a specific session, but in this case, the SM-DP + 500 may process the session. There is still a limit to the performance that can be achieved. However, according to the TransactionID, a plurality of sessions can be distinguished, and thus the SM-DP + 500 can process requests from a plurality of terminals.
  • the SM-DP + 500 may check whether there is a download target profile corresponding to the MatchingID or the EID. .
  • the SM-DP + 500 uses a private key SK.DP.ECDSA (: Private Key of DP used for digital signature verification) to signify data including eUICC Challenge, DP Challenge, and TransactionID values.
  • SK.DP.ECDSA Private Key of DP used for digital signature verification
  • DP Signature can be generated (522).
  • the DP signature value is a signature value for authenticating the SM-DP + 500 in the eUICC 504.
  • the SM-DP + 500 may transmit a signature certificate CERT.DP.ECDSA, DP Challenge, TransactionID, and DP Signature of the SM-DP + 500 in response to the ES9 + .InitiateDownload 520 (524).
  • the LPA 502 may deliver an ES10b.PrepareDownload message to the eUICC 504 (526).
  • the ES10b.PrepareDownload may be ES10.GetAuthDataRequest.
  • the ES10b.PrepareDownload message may include CERT.DP.ECDSA, DP Challenge, TransactionID, and DP Signature.
  • the eUICC 504 may verify the DP certificate CERT.DP.ECDSA using the CI certificate stored in the eUICC 504 or the public key of the CI (528).
  • the eUICC may verify the signature value DP Signature of the SM-DP + 500 (528). Verification of the DP Signature of the eUICC 504 includes the DP Challenge, TransactionID received from the LPA 502, the eUICC Challenge that the eUICC 504 delivered to the LPA 502, and CERT.DP.ECDSA.
  • the public key PK.DP.ECDSA of the SM-DP + 500 can be used.
  • the eUICC 504 may generate a disposable asymmetric key pair (otPK.EUICC.ECKA, otSK.EUICC.ECKA) (528).
  • a disposable asymmetric key pair otPK.EUICC.ECKA, otSK.EUICC.ECKA
  • the eUICC 504 Can also be used by loading a one-time generated asymmetric key pair without generating one-time asymmetric key pair.
  • the disposable asymmetric key pair of the eUICC 504 may be used to generate an encryption key between the SM-DP + 500 and the eUICC 504 together with the disposable asymmetric key pair of the SM-DP + 500.
  • the encryption key is generated by combining the one-time private key of the SM-DP + 500 and the one-time private key of the eUICC 504 by the SM-DP + 500, or the eUICC 504 by the eUICC 504. It can be generated by combining the one-time private key with the one-time public key of the SM-DP + 500.
  • the additional factor necessary for generating the encryption key may be transmitted by the SM-DP + 500 to the eUICC through the LPA 502 in a later step.
  • the eUICC 504 uses the eUICC's signature private key (SK.eUICC.ECDSA) for data including the one-time public key (otPK.EUICC.ECKA) and the DP Challenge among the generated one-time asymmetric key pairs to sign the eUICC.
  • the value eUICC_Sign2 may be calculated (528). Since the eUICC_Sign2 calculation includes the DP Challenge generated by the SM-DP + 500, the eUICC_Sign2 may be used for the SM-DP + 500 to authenticate the eUICC 504 in a later step. In addition, the eUICC_Sign2 may serve to transfer the otPK.EUICC.ECKA value generated by the eUICC to the SM-DP + 500 without being modulated.
  • the eUICC 504 may transmit the generated public key otPK.EUICC.ECKA of the generated eUICC and the generated eUICC signature value eUICC_Sign2 to the LPA 502 (530).
  • the LPA 502 may deliver the profile package request message ES9 + GetBoundProfilePackage to the SM-DP + 500 (532).
  • the ES9 + GetBoundProfilePackage 532 may be named as eUICCManagementRequest or ProfileRequest.
  • the ES9 + GetBoundProfilePackage 532 may include a disposable eUICC public key and the eUICC signature.
  • the ES9 + GetBoundProfilePackage 532 may also receive an eUICC signing certificate (CERT.EUICC.ECDSA) for verifying the eUICC signature value and an EUM certificate (CERT.EUICC.ECDSA) for verifying the eUICC signing certificate.
  • the Event9, MatchingID, NotificationID, or Activation Code Token which can be used as a separator for downloading a specific profile, may be included in the ES9 + GetBoundProfilePackage 532.
  • the SM-DP + 500 may verify the EUM certificate using the CI certificate or the public key for authentication (PK.CI.ECDSA).
  • the SM-DP + 500 may verify an eUICC certificate by using the verified EUM certificate and verify an eUICC signature value by using the eUICC certificate.
  • the certificate verification and signature verification may be omitted.
  • the SM-DP + 500 uses the one-time eUICC public key received from the LPA 502 in operation 532 and the public key included in the DP Challenge and the eUICC certificate transferred to the LPA 502 in operation 524.
  • the signature ie, eUICC_Sign2
  • eUICC_Sign2 may be verified (534). If the verification of the eUICC_Sign2 passes, the SM-DP + 500 authenticates the eUICC 504. If the verification fails, the SM-DP + 500 may stop the operation for the session and return an error to the LPA 502.
  • the SM-DP + 500 may map a profile to download using the EventID (or NotificationID, MatchingID, and Activation Code Token) values received in step 532. If there is no profile to download, it can return an error and terminate the session.
  • EventID or NotificationID, MatchingID, and Activation Code Token
  • the SM-DP + 500 may generate a disposable DP asymmetric key pair (otPK.DP.ECKA, otSK.DP.ECKA) (534).
  • the SM-DP + 500 may generate an encryption key between the eUICC 504 and the SM-DP + 500 using the disposable DP asymmetric key pair (534).
  • the encryption key generation method is as follows.
  • -SM-DP + (500) generates an encryption key by combining the one-time private key of SM-DP + and the one-time private key of eUICC
  • -eUICC 504 generates an encryption key by combining the one-time private key of the eUICC 504 and the one-time public key of SM-DP +
  • the SM-DP + 500 may calculate the SM-DP + signature value DP Signature2 (534).
  • the signature value DP Signature2 is a signature private key (SK.DP.ECDSA) of SM-DP + for data including a control reference template (CRT), a one-time public key of SM-DP +, a one-time public key of eUICC, and a TransactionID. Calculated using The CRT may be used as a factor of encryption key generation.
  • the SM-DP + 500 may generate a profile package (BPP) coupled to a specific eUICC (534).
  • the BPP may include a CRT, a one-time public key of SM-DP + 500, and DP Signature2.
  • the BPP may include ProfileInfo (or MetaData) encrypted with the encryption key.
  • the BPP may include an encrypted PPK by encrypting a Profile Protection Key (PPK) with the generated encryption key.
  • the BPP may include Profile Package Blocks (PPBs) encrypted with the generated encryption key or the PPK.
  • the encrypted PPBs are divided into profile elements (PEs), in which entire profile data can be installed, and then the PPBs divided into encryptable size units are encrypted.
  • the encryption of the PPB may use the SCP03t protocol.
  • SM-DP + 500 may return BPP to LPA 502 in response to ES9 + GetBoundProfilePackage 532 (536).
  • the LPA 502 may deliver ES8 + .InitializeSecureChannel information included in the BPP to the eUICC 504 by performing ES10b.LoadBoundProfilePackage a plurality (N) times (538).
  • the ES8 + .InitializeSecureChannel information may include a CRT, a disposable public key of SM-DP +, and DP Signature2.
  • the ES8 + .InitializeSecureChannel may refer to an EstablishSecureChannel.
  • the ES10b.LoadBoundProfilePackage may be to transmit a "StoreData" command.
  • the eUICC 504 is the public key PK.DP.ECDSA of the DP signing certificate CERT.DP.ECDSA received in step 526, the CRT received in step 538, the one time public key of SM-DP + and the LPA in step 530.
  • the eUICC's one-time public key passed to 502 may be used to verify the DP signature (DP Signature2) (540).
  • the eUICC 504 If the verification 540 fails, the eUICC 504 returns an error to the LPA 502 and does not perform any further processing. Upon passing the verification 540, the eUICC 504 can generate an encryption key using a CRT, a one time private key of eUICC, and a one time public key of SM-DP +. Optionally, the eUICC 504 may deliver 542 APDUs to the LPA 502 in response to the ES10b.LoadBoundProfilePackage 538.
  • the LPA 502 may deliver ES8 + SetProfileInfo information included in the BPP to the eUICC 504 by performing ES10b.LoadBoundProfilePackage a plurality of times (544).
  • the ES8 + SetProfileInfo may also be referred to as ES8 + .StoreMetadata or InstallProfileRecord.
  • the ES8 + SetProfileInfo may include ProfileInfo (or Metadata or ProfileRecord).
  • the eUICC 504 may deliver 546 APDUs to the LPA 502 in response to the ES10b.LoadBoundProfilePackage 544.
  • the LPA 502 may deliver ES8 + .ReplaceSessionKey information to the eUICC 504 by performing ES10b.LoadBoundProfilePackage a plurality of times (548). That is, when the LPA 502 includes ES8 + .ReplaceSessionKey in the BPP received from the SM-DP + 500, the LPA 502 executes ES10b.LoadBoundProfilePackage N times to display the ES8 + ReplaceSessionKeys information included in the BPP. Can be passed to eUICC.
  • the ES8 + ReplaceSessionKeys may be referred to as UpdateSessionKeyRequest.
  • the ES8 + ReplaceSessionKeys may include a ProfileProtectionKey (PPK) encrypted with the encryption key of step 534.
  • the eUICC 504 may deliver 550 APDUs to the LPA 502 in response to the ES10b.LoadBoundProfilePackage 548.
  • the LPA 502 may perform ES10b.LoadBoundProfilePackage a plurality of times (N) to deliver encrypted PPB (Profile Package Block) or Profile Segments included in the BPP to the eUICC 504 (552). Each Profile Segment may be decrypted with the encryption key or PPK and processed by the eUICC 504 in order.
  • N EncryptedBoundProfilePackage a plurality of times
  • PPB Profile Package Block
  • Profile Segments included in the BPP to the eUICC 504 (552).
  • Each Profile Segment may be decrypted with the encryption key or PPK and processed by the eUICC 504 in order.
  • the eUICC 504 may calculate and pass the eUICC signature value to the LPA 502 (554). At this time, the LPA 502 may inform the profile installation result by transmitting the eUICC signature value to the SM-DP + 500 through ES9 + .SendResult (556), and the SM-DP + 500 transmits an OK. May be 558.
  • 6A and 6B are diagrams illustrating another method of profile installation according to the present disclosure.
  • the signature of the eUICC is omitted in the initial round in FIGS. 6A and 6B, and the operation after the initial round is described in more detail.
  • the LPA 620 may obtain profile information (640).
  • the LPA 620 may receive the address and profile installation key of the SM-DP + 610 from the SM-DS.
  • the profile installation key may be EventID, MatchingID, NotificationID, or Activation Code Token.
  • the eUICC 630 is inserted into or embedded in the LPA 620, and the operations of the LPA 620 and the eUICC 630 may be interpreted as internal operations of the terminal.
  • the LPA 620 may input a secret code using the obtained profile installation key information (642).
  • the operation 642 is not an essential operation and may be selectively performed when there is a secret code.
  • the LPA 620 may request the eUICC 630 to generate an eUICC Challenge (644).
  • the eUICC 630 may generate and store the eUICC Challenge (646).
  • the eUICC 630 may transfer the generated eUICC Challenge and certificate information (Certificate_Info) to the LPA 620 (648).
  • the certificate information (Certificate_Info) may include an eUICC certificate type and an available encryption key type.
  • the encryption key information may mean an elliptic curve parameter.
  • the encryption key information may be plural, and may include information used for signature generation and information used for signature verification. By transmitting the elliptic curve parameters, the SM-DP + may select elliptic curve parameters that are compatible with each other.
  • the LPA 620 may include the SM-DP + 610 address information included in the profile information in addition to the eUICC Challenge and Certificate_Info and transmit the information to the SM-DP + 610 corresponding to the address information (650).
  • the SM-DP + 610 may check whether the SM-DP + included in the received information is valid (652). The validity check may be verifying whether the received SM-DP + address information is the same as its own server address or checking whether the corresponding SM-DP + address information corresponds among a plurality of valid addresses. If the check fails, the SM-DP + 610 may transmit an error code to the LPA 620 and stop the profile download operation.
  • the SM-DP + 610 may check Certificate_Info (652). First, the SM-DP + 610 may check whether the certificate type is valid. In addition, it may be checked whether encryption key information is supported by the SM-DP + 610. The check determines whether encryption key information for signature of the eUICC 630 and encryption key information verifiable in the SM-DP + 610 match, encryption key information and SM-DP + 610 for verification in the EUICC 630. ) May compare the encryption key information used to generate the signature.
  • the SM-DP + 610 may generate a transaction ID after storing the certificate type and encryption key information to be used (652). Using the transaction ID, the SM-DP + 610 may check whether a subsequent request message from the LPA 620 is valid. In addition, the transaction ID may serve as a delimiter for one SM-DP + to process requests from a plurality of terminals at the same time.
  • the SM-DP + 610 may then generate a DP challenge (652).
  • the DP challenge may be a challenge of SM-DP + or a challenge of the profile provision server.
  • the DP challenge may be a random number of 16 bytes.
  • the SM-DP + 610 may generate a DP_Sign1 (652).
  • the DP_Sign1 may be a signature value generated by the SM-DP + 610 including eUICC_Challenge, DP_Challgene, and TransactionID.
  • the SM-DP + 610 may transmit authentication information to the LPA 620 (654).
  • the SM-DP + 610 may transmit the transaction ID, the DP Challenge, the DP_Sign1, the SM-DP_ Certificate, and the Cert_ToBe_Used information to the LPA 620.
  • the SM-DP + certificate may be an Elliptic Curved Digital Signature Algorithm (ECDSA) certificate.
  • the Cer_ToBe_Used may be information including a certificate type and encryption key information to be used and stored in the SM-DP + 610.
  • the LPA 620 may transmit the current time of the terminal, a profile providing server address, a profile installation key (AC_Token), terminal information, and a hashed confirmation code in addition to the received information, to the eUICC 630. (656).
  • the hashed secret code may be delivered when the 642 operation is performed.
  • the LPA 620 may map and store a transaction ID and the SM-DP + address together.
  • the eUICC 630 may verify the SM-DP + 610 based on the information received in operation 656 (658).
  • the eUICC 630 first verifies the SM-DP + certificate CERT.DP.ECDSA (658).
  • the verification may be a signature verification method using a certificate issuer (CI) certificate stored in the EUICC 630 or a public key of the CI certificate.
  • the signature verification may be verification using a public key selected using information included in Cert_ToBe_use.
  • the eUICC 630 verifies the received DP_Sign1 (658).
  • the verification may be signature verification using a public key included in the SM-DP + certificate. If this verification passes, the eUICC 620 authenticates the SM-DP_610.
  • the eUICC 630 may then generate a one-time public and private key pair (658).
  • the public key and the private key pair are generated as separate values in the SM-DP + 610.
  • the public key and the private key can be combined to share the session key. .
  • the public key can be used only once, so that a new session key can be shared every time the profile is downloaded.
  • a signature value eUICC_Sign1 may be generated and transmitted using the public key (658).
  • the eUICC 630 may sign a signature using a private key previously stored in the eUICC 630 including the received DP Challenge together with the one-time public key of the eUICC 630.
  • the SM-DP + 610 may later authenticate the eUICC 630 by signing including the DP challenge.
  • the signature may include one or more of transaction ID, SM-DP + address, profile installation key, terminal information, eUICC information, and hashed secret code value, and the information additionally included in the signature is SM-DP + (610). ) Can be used for further verification.
  • the signature is called eUICC_Sign1.
  • a signature may be generated by selecting a private key of an eUICC corresponding to the certificate type and encryption key information used in the received Cert_ToBe_Used.
  • the eUICC 630 may transfer eUICC authentication information to the LPA 620 (660).
  • the eUICC authentication information includes at least one of a one-time public key of the eUICC, an SM-DP + address, a profile installation key, terminal information, eUICC information, a hashed secret code value, eUICC_Sign1, an eUICC certificate, and an EUI certificate that issued an eUICC certificate. It may include.
  • the LPA 620 may transmit a profile request message to the SM-DP + 610 (662).
  • the profile request message may transmit the eUICC authentication information received from the eUICC 630 to the SM-DP 610.
  • LPA 620 is the SM-DP + address corresponding to the transaction ID stored before the operation 656, the transaction ID, one-time eUICC public key, SM-DP + address, profile installation key, terminal information, eUICC information, hashed secret
  • One or more of code information, eUICC_Sign1, eUICC certificate, and EUM certificate that issued an eUICC certificate may be transmitted to the SM-DP + 610.
  • the SM-DP + 610 may check the transaction ID received in operation 662 to check whether there is a valid transaction ID, and if not, return the error code to the LPA 620 and terminate the download process.
  • a valid transaction ID means that the transaction ID is stored in the storage or memory of the SM-DP + and can be inquired.
  • the SM-DP + corresponding to the transaction ID performs the operation 654 but performs the message corresponding to the operation 662 for the first time. For example, received. However, if a message of operation 662 has already been received and a message of operation 662 is received with the same transaction ID, an error code may not be returned in some cases. For example, if the second profile request message is transmitted while the operation 664 described later is performed on the message received first in operation 662, the second message is not returned and the second message is discarded without returning an error code for the second profile request message. It may be.
  • the SM-DP + 610 may verify the eUICC (664).
  • SM-DP + 610 may verify the EUM (eUICC manufacturer) certificate (664).
  • the verification may be a method of verifying the signature of the eUICC manufacturer certificate by first extracting the public key from the CI certificate stored in the SM-DP + 610 or directly using the stored public key.
  • the SM-DP + 610 may verify the eUICC certificate by verifying a signature value included in the received eUICC certificate using the public key of the certificate extracted from the EUM certificate (664).
  • the SM-DP + 610 may verify the eUICC_Sign1 value using the public key included in the verified eUICC certificate (664). If the verification passes, the SM-DP + 610 authenticates the eUICC 630.
  • the SM-DP + 610 may verify whether the profile installation key AC_Token is valid (664). This may be a process of checking whether the corresponding profile installation key is included in a value stored in the storage of SM-DP + and whether there is a downloadable profile corresponding to the stored profile installation key.
  • SM-DP + 610 may verify the hashed secret code (664). This may be a simple comparison with the stored hashed secret code, or a method of calculating and comparing the newly hashed secret code.
  • the SM-DP + 610 may further perform an eligibility determination on whether profile installation is possible by comparing the terminal information and the eUICC information (664).
  • the information may include network type accessible and memory area information that can be installed.
  • the SM-DP + 610 may proceed with the subsequent process after approving the profile download. If the verification fails, the SM-DP + 610 may return an error code to the LPA 620 and terminate the profile download process. In this case, delete the transaction ID and DP challenge that you saved before ending the download process. If the verification passes, as described above, the SM-DP + 610 may generate a one-time profile provision server public and private key pair (664).
  • the encryption key information used to generate the disposable asymmetric key pair may be information of an encryption key included in Cert_ToBe_Used delivered in operation 654.
  • the SM-DP + 610 may generate a session key using the secret key and the received disposable eUICC public key (664).
  • CRT information and EID information may be used to generate the session key.
  • the SM-DP + 610 may generate a DP_Sign2 (664).
  • the DP_Sign2 is a signature value using a pre-stored private key of SM-DP +, and may be a signature value calculation for a value including a CRT, a one-time DP public key, and a one-time eUICC public key.
  • the SM-DP + 610 may generate an encrypted profile package using the generated session key (664).
  • the encrypted profile package may be generated in one of two ways.
  • Method 2 The combination of a randomly generated profile key encrypted with a random key previously generated for an unencrypted profile package, and an encrypted random key encrypted with the generated session key.
  • the encrypted profile package may further include a CRT that can be used to generate a session key in the eUICC, a disposable profile providing server public key, and the generated DP_Sign2.
  • SM-DP + 610 may forward the encrypted profile package to LPA 620 (666).
  • the LPA 620 may deliver the profile package to the eUICC 630 (668). In this case, the LPA 620 may deliver unencrypted data in the profile package.
  • the LPA 620 distinguishes the unencrypted data and the plurality of encrypted data among the encrypted profile packages, first divides the unencrypted data into a size that can be transmitted to the eUICC 630, and the eUICC 630. Can be delivered to.
  • the delivery method may be a method using a "STORE DATA" APDU.
  • the classification of the unencrypted data may be a method of distinguishing a tag value included in the encrypted profile package.
  • the Tag value may be the first 1 byte or 2 bytes of data of the encrypted profile package, and the subsequent length byte may be identified and the boundary of the end of the unencrypted data may be distinguished and transmitted.
  • the unencrypted data may include the CRT, a disposable DP public key, and a DP_Sign2 value.
  • the eUICC 630 may verify the signature and generate a decryption key (670).
  • the eUICC 630 may verify DP_Sign2. This may be a signature verification method using the public key of the previously verified SM-DP + certificate. If the verification passes, the eUICC 630 generates a session key for decrypting the encrypted profile package by using the received CRT, a one-time SM-DP + public key value, an EID value, and a one-time eUICC private key value stored only in the eUICC. can do.
  • the LPA 620 may carry encrypted data (672).
  • the LPA 620 checks after the boundary of the unencrypted data as encrypted data, which is distinguished when the operation 668 is performed, and checks whether a specific tag exists to find a tag that represents encrypted data.
  • the size of the encrypted data may be checked by checking the byte, and the encrypted data may be transmitted to the EUICC 630. In this case, the encrypted data may be divided and transmitted to the eUICC 630 using a "STORE DATA" APDU command.
  • the LPA 620 may then perform a process similar to operation 672 on the encrypted data and transmit it (674).
  • the transmitted data may be an encryption random key when the package encrypted by the method 2 is generated in operation 664.
  • the eUICC 630 uses the encryption random key for subsequent encrypted data. After decrypting the session key to extract a random key, the random key may be used as a session key for decrypting subsequent encrypted data.
  • the LPA 620 may distinguish a plurality of encrypted data by checking another Tag value and a length byte for classifying the encrypted data, and use the plurality of "STORE DATA" commands for each encrypted data to eUICC 630. May be passed to 676.
  • the eUICC 630 decodes each encrypted data using the session key or the decrypted random key and installs the profile as an installable unit using the profile installable unit information included therein.
  • the installable unit information can be installed to decrypt the encrypted data.
  • the LPA 620 and the eUICC 630 have been described separately, but the eUICC is included in or inserted into the terminal. Therefore, in the embodiment of the present disclosure, the operation between the LPA and the eUICC may be interpreted as an internal operation of the terminal including the eUICC.
  • authentication, verification, profile package download, profile package delivery, and profile installation operation for eUICC and SM-DP + may be performed.
  • the LPA 620 may activate the profile by transmitting an enable command of the profile to the eUICC 630, and authenticate with the mobile communication system using the activated profile. After performing the mobile communication network can be used.
  • 7A, 7B, and 7C illustrate a method of provisioning bulk profiles for multiple terminals at once.
  • the bulk profile installation process may include an eUICC delivery phase 720, a device production preparation phase 730, and a device production phase for convenience of description. 740).
  • the SM-SR + (or Production Server) 704 may receive a ProductionInfoNotifyRequest message from the eUICC manufacturer (EUM) 700 to receive product information about N eUICCs (722).
  • the MS-SR + 704 may send a ProductionInfoNotifyResponse (ACK) message to the EUM (724).
  • EUM eUICC manufacturer
  • ACK ProductionInfoNotifyResponse
  • the eUICC 714 may be configured to perform the following operations only for a specific SM-SR +. There are two methods for specifying the SM-SR +.
  • the separator of SM-SR + is preset by EUM when manufacturing eUICC
  • -EUICC performs specific operation only when requesting using Credential by delivering specific Credential to SM-SR +
  • the product information for the eUICC N pieces may include an eUICC Info, an eUICC certificate, a pre-generated one-time public key, and an EUM certificate.
  • the product information may further include the credential.
  • the pre-generated one-time public key can only be used in eUICC via a specific SM-SR +.
  • the SM-SR + 704 may send a BulkProfileRequest to the SM-DP + 702 to request preparation for downloading a plurality of profiles (732).
  • the BulkProfileRequest may include the following information.
  • N eUICC certificates one-time public key for N eUICCs
  • N eUICC information one-time public key for N eUICCs
  • the N pieces of information may be delivered in a form that can be mapped to the eUICC in the SM-DP + 702.
  • the signature value may be a signature value for a value including a disposable public key.
  • SM-DP + 702 may verify the certificate and signature value SRToken0 of SM-SR + (734).
  • the SM-DP + 702 If the verification passes, the SM-DP + 702 generates an disposable asymmetric key pair (ie, public key and private key), and receives the disposable asymmetric key pair in operation 732.
  • the encryption key can be used in conjunction with the public key to generate an encryption key (734).
  • the encryption key may be used to encrypt a profile or to encrypt a symmetric key that encrypts the profile.
  • the SM-DP + 702 may generate N data, that is, ProfileInstallPackages including the encrypted profile, the one-time public key generated by the SM-DP +, and the signature value of the SM-DP + (734).
  • the SM-DP + 702 may deliver the ProfileInstallPackage generated by delivering a BulkProfileResponse message to the SM-SR + 704 (736).
  • the SM-SR + 704 may calculate a signature value SRToken1 of the SM-SR + 704 with respect to a value including some or all of the data received from the SM-DP + (738).
  • the signature value may be a value previously owned by the SM-SR + 704 or may be a signature value using “specific Credential” received from the EUM in step 722.
  • the individual terminal 710 is described as being composed of the LPA 712 and eUICC 714 for convenience of description.
  • the LPA 712 may request a profile installation by transmitting a FactoryEventRequest (EID) message to the SM-SR + 704 when a specific condition is met (742).
  • EID FactoryEventRequest
  • the specific condition is applied in the production stage of the terminal (for example, in the manufacturing plant of the terminal), for example, may be as follows.
  • the LPA 712 may receive an eUICC Challenge value from the eUICC 714.
  • the FactoryEventRequest 742 may include one or more of EID and eUICC Challenge.
  • the signature value SRToken1 of the SM-SR + in step 728 may be calculated including the eUICC Challenge.
  • SM-SR + 704 may forward a response including the signature value of SM-DP + 702 and the signature value of SM-SR + 704 to the LPA (744).
  • the LPA 712 may transmit a Profile installation preparation message GetAuthDataRequest including the SM-DP + 702 signature value and the SM-SR + 704 signature value to the eUICC 714 (746).
  • the eUICC 714 verifies the SM-SR + 704 signature, and if it passes the verification, verifies the SM-DP + 702 signature (748). If any of the validations fail, return an error and exit without executing any further steps.
  • the eUICC 714 can verify that the SM-SR + 704 is a particular server.
  • the checking method may be a method of verifying an ID of the SM-SR + 704 or a method of verifying a signature value. If the SM-SR + 704 is not an authorized server (i.e. a specific server), the eUICC 714 creates a new one-time asymmetric key pair, but the SM-SR + 704 is an authorized server (i.e. a specific server). In this case, the eUICC 714 may use a previously generated disposable asymmetric key pair without generating a new disposable asymmetric key pair.
  • the eUICC 714 may generate an eUICC signature value eUICCToken using a signature private key set in the eUICC with respect to data including a disposable public key and parameters received from the LPA (748).
  • the eUICC 714 may deliver a GetAuthDataResponse message to the LPA 712 to deliver data including the eUICC signature value and the disposable public key (750).
  • the LPA 714 may transmit a profile download request to the SM-SR + 704 by delivering an eUICCManagementRequest message including the received eUICC signature value and a disposable public key (752).
  • SM-SR + 704 verifies the eUICC signature value (754). If the verification fails, the SM-SR + 704 may return an error and then stop the profile installation process of the corresponding terminal. In addition, the SM-SR + 704 may sign a portion or all of the encrypted profile received in step 736 using the signature private key of the SM-SR + 704 (754). The encrypted profile may include another signature value of SM-DP + 702.
  • the SM-SR + 704 may transmit an eUICCManagementResponse message to the LPA 712 in response to the step 752 to deliver an encrypted profile, the signature value of the SM-SR + 704 (756).
  • the LPA 712 passes the EstablishSecureChannelRequest message to the eUICC 714, including the SM-SR + 704 signature value SRToken2, the one-time public key of the SM-DP + 702, and the one-time public key of the SM-DP + 702.
  • the signature value DPToken2 signed with the signature private key of SM-DP + may be delivered to the data (758).
  • the eUICC 714 may verify the signature value of the SM-SR + 704 (760). If the verification fails, the eUICC 714 may return an error to the LPA 712 and terminate the subsequent profile installation process.
  • the eUICC 714 may verify the signature value of the SM-DP + 702 (760). If the verification fails, the eUICC 714 may return an error and terminate the subsequent profile installation process.
  • the eUICC 714 Upon successful verification of the SM-DP + 702 signature value, the eUICC 714 uses the one-time public key of the SM-DP + 702 received from the LPA 712 and the one-time private key of the eUICC 714. An encryption key may be generated (760).
  • the eUICC 714 may transmit an EstablishSecureChannelResponse message to the LPA 712 in response to the message received in step 758 (762).
  • the LPA 712 may deliver an InstallProfileRecordRequest message to the eUICC 714 to deliver encrypted ProfileRecord information (ie, metadata) (764).
  • the eUICC 714 may install after decrypting the encrypted ProfileRecord with the encryption key generated in step 760.
  • the eUICC 714 may deliver an InstallProfileRecordResponse message to the LPA 712 in response to the message received in step 764.
  • LPA 712 may pass 768 an encrypted Profile Protection Key (PPK) to eUICC 714. Then, the eUICC 714 may decrypt the encrypted PPK with the encryption key generated in step 760 and then transmit a response message to the LPA 712 (770).
  • PPK Profile Protection Key
  • the LPA 712 may then transmit the encrypted PPB (Profile Package Block) to the eUICC 714 (772).
  • PPB Profile Package Block
  • the eUICC 714 may decrypt the encrypted PPB using the encryption key of step 760 or the PPK of step 770. If the decryption fails, the eUICC 714 error code may be returned and the subsequent profile installation process may be terminated. If decryption is successful, the eUICC 714 installs profile elements that can be installed by confirming whether one or more profile elements, which are installable units, are configured by decoded PPB alone or in combination with some or all of the previously delivered PPBs. If some or all of the elements are not used to construct the Profile Element, then they can be combined with some or all of the other PPBs and stored in a buffer to form the Profile Element.
  • the eUICC 714 may transmit a response to the message of step 772 to the LPA 712 (774).
  • the operations 772, 773, and 774 may be repeated M times.
  • the eUICC 714 can forward the installation complete message to the LPA 712 with the profile containing the eUICC signature.
  • the LPA 712 may forward the installation completion notification message NotifyResultRequest including the eUICC signature to the SM-SR + 704 after the profile installation is completed (776) and receive a response to the NotifyResultRequest message (778).
  • the LPA 712 may additionally enable the profile installed by the eUICC 714 (780).
  • the operations 742 to 780 operate on individual terminals, the operations may be repeatedly performed on N terminals.
  • SM-SR + 704 may notify SM-DP + 702 of the bulk profile provisioning result (792) and receive a response.
  • operations 792 and 794 may be referred to as bulk provisioning result notification step 790.
  • an interface between an entity in a system providing a profile to an eUICC of a terminal, a function, and a message for the function are defined.
  • Table 2 illustrates the functions and protocols of the terminal (LPA) -server or server-server interface in the system.
  • Table 3 illustrates the function and protocol of the terminal (LPA) -eUICC interface in the system.
  • the terminal-server and server-server interface functions illustrated in Table 2 may be communicated using a data object in JSON (JavaScript Object Notation) format through a hyper text transfer protocol over secure socket layer (HTTPS) protocol.
  • JSON JavaScript Object Notation
  • HTTPS secure socket layer
  • the HTPP header includes a header for an HTTP request and a header for an HTTP response.
  • the HTTP request header may have the format shown in Table 4 below.
  • the method of the HTTP request may be an HTTP post method.
  • the resource " ⁇ uri>” (: uniform resource identifier) of the HTTP request may be set as " ⁇ query path>” (: query path), for example, "/ v1 / es9 / euicc-mgmt ".
  • the HTTP request header may include, for example, fields of "Content-type”, “Content-length”, “Host”, and "X-Admin-Protocol", each of which uses the following table. It can be defined as 5.
  • MOC Modandatory / Optional / Conditional
  • O optional
  • C conditional
  • the HTTP response header may have the format shown in Table 6 below.
  • ES1_ProductInfoNotifyRequest a feature of the ES1 interface (e.g., the interface between EUM and SM-SR +), provides SM-SR + with a list of pre-generated public public keys (ePKs) created by EUM for bulk profile provisioning. This is a message to convey.
  • Bulk profile provisioning can be multiple profile provisioning, such as, for example, a factory production scenario.
  • ⁇ Query path> of the ES1_ProductInfoNotifyRequest message may be, for example, "/ v1 / es1 / product-info-notify”.
  • JSON body schema corresponding to the request message of the ES1_ProductInfoNotifyRequest message is shown in Table 7 below.
  • the JSON body schema corresponding to the response message of the ES1_ProductInfoNotifyRequest message is shown in Table 8, for example.
  • ES2_DownloadProfileRequest a function of the ES2 interface (an interface between the MNO and the SM-DP +), is a message for the MNO to request a download of a profile from the SM-DP +.
  • ⁇ Query path> of the ES2_DownloadProfileRequest message may be, for example, "/ v1 / es2 / download-profile”.
  • the JSON body schema corresponding to the request message of the ES2_DownloadProfileRequest message is shown in Table 9 below, for example.
  • the JSON body schema corresponding to the response message of the ES2_DownloadProfileRequest message is shown in Table 10, for example.
  • ES2_ActivationVoucherRequest which is a function of the ES2 interface (interface between MNO and SM-DP +), is a message that the MNO requests SM-DP + to activate a voucher.
  • ⁇ Query path> of the ES2_ActivationVoucherRequest message may be, for example, "/ v1 / es2 / activation-voucher”.
  • JSON body schema corresponding to the request message of the ES2_ActivationVoucherRequest message is shown in Table 11 below.
  • JSON body schema corresponding to the response message of the ES2_ActivationVoucherRequest message is shown in Table 12 below.
  • ES2_NotifyResultRequest a feature of the ES2 interface, is a message that SM-DP + requests the MNO to notify of the result of an event.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es2 / notify-result".
  • the JSON body schema corresponding to the request message of the ES2_NotifyResultRequest message is shown in Table 13 below, for example.
  • the JSON body schema corresponding to the response message of the ES2_NotifyResultRequest message is shown in Table 14, for example.
  • ES3_eUICCManagementRequest a function of the ES3 interface (e.g., the interface between SM-DP + and SM-SR +), is a message that SM-DP + requests SM-SR + to download a remote profile to the eUICC.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es3 / euicc-mgmt".
  • the JSON body schema corresponding to the request message of the ES3_eUICCManagementRequest message is shown in Table 15, for example.
  • the JSON body schema corresponding to the response message of the ES3_eUICCManagementRequest message is shown in Table 16, for example.
  • ES3_DownloadProfileRequest a feature of the ES3 interface, is a message that SM-SR + requests SM-DP + to download a profile.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es3 / download-profile”.
  • the JSON body schema corresponding to the request message of the ES3_DownloadProfileRequest message is shown in Table 17, for example.
  • JSON body schema corresponding to the response message of the ES3_DownloadProfileRequest message is shown in Table 18 below.
  • ES3_ProfileRequest a function of the ES3 interface, is a message that SM-SR + requests SM-DP + to create a profile for.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es3 / profile”.
  • JSON body schema corresponding to the request message of the ES3_ProfileRequest message is shown in Table 19 below.
  • JSON body schema corresponding to the response message of the ES3_ProfileRequest message is shown in Table 20 below.
  • ES3_NotifyResultRequest a function of the ES3 interface, is a message that SM-SR + requests SM-DP + to notify of the event result.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es3 / notify-result".
  • the JSON body schema corresponding to the request message of the ES3_NotifyResultRequest message is shown in Table 21, for example.
  • the JSON body schema corresponding to the response message of the ES3_NotifyResultRequest message is shown in Table 22, for example.
  • the ES3_BulkProfileRequest a feature of the ES3 interface, is a message that the SM-SR + requests one or more profiles from the SM-DP +.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es3 / bulk-profile”.
  • JSON body schema corresponding to the request message of the ES3_BulkProfileRequest message is shown in Table 23 below.
  • JSON body schema corresponding to the response message of the ES3_BulkProfileRequest message is shown in Table 24 below.
  • ES3_NotifyResultBulkRequest a feature of the ES3 interface, is a message that SM-SR + requests SM-DP + to notify of the result of a bulk profile provisioning event.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es3 / notify-result-bulk”.
  • the JSON body schema corresponding to the request message of the ES3_NotifyResultBulkRequest message is shown in Table 25, for example.
  • the JSON body schema corresponding to the response message of the ES3_NotifyResultBulkRequest message is shown in Table 26, for example.
  • ES4_eUICCManagementRequest a function of the ES4 interface (interface between MNO and SM-SR +), is a message that MNO requests SM-SR + to remote platform / profile management of eUICC.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es4 / euicc-mgmt".
  • JSON body schema corresponding to the request message of the ES4_eUICCManagementRequest message is shown in Table 27 below.
  • JSON body schema corresponding to the response message of the ES4_eUICCManagementRequest message is shown in Table 28, for example.
  • ES4_TerminalRequest a feature of the ES4 interface, is a message that SM-SR + requests the MNO to return the authorization result for device swap or local delete.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es4 / terminal".
  • the JSON body schema corresponding to the request message of the ES4_TerminalRequest message is shown in Table 29, for example.
  • the JSON body schema corresponding to the response message of the ES4_TerminalRequest message is shown in Table 30, for example.
  • ES4_NotifyResultRequest a feature of the ES4 interface, is a message that SM-SR + requests the MNO to notify of event results.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es4 / notify-result".
  • the JSON body schema corresponding to the request message of the ES4_NotifyResultRequest message is shown in Table 31, for example.
  • JSON body schema corresponding to the response message of the ES4_NotifyResultRequest message is shown in Table 32, for example.
  • ES9_EventRequest a function of the ES9 interface (the interface between the LPA and the SM-SR +), is a message for the LPA to request an event corresponding to a specific event ID from the SM-SR +.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es9 / event”.
  • the JSON body schema corresponding to the request message of the ES9_EventRequest message is shown in Table 33, for example.
  • JSON body schema corresponding to the response message of the ES9_EventRequest message is shown in Table 34 below.
  • ES9_eUICCManagementRequest a feature of the ES9 interface, is a message that the LPA requests SM-SR + to remote platform / profile management of eUICC.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es9 / euicc-mgmt".
  • the JSON body schema corresponding to the request message of the ES9_eUICCManagementRequest message is shown in Table 35, for example.
  • JSON body schema corresponding to the response message of the ES9_eUICCManagementRequest message is shown in Table 36, for example.
  • the ES9_TerminalRequest is a message that the LPA requests SM-SR + to download a profile, swap a device, or delete a profile locally.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es9 / terminal".
  • the JSON body schema corresponding to the request message of the ES9_TerminalRequest message is shown in Table 37, for example.
  • the JSON body schema corresponding to the response message of the ES9_TerminalRequest message is shown in Table 38, for example.
  • ES9_TerminalAuthRequest a feature of the ES9 interface, is a message that the LPA requests SM-SR + to authorize local profile management.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es9 / terminal-auth".
  • the JSON body schema corresponding to the request message of the ES9_TerminalAuthRequest message is shown in Table 39, for example.
  • the JSON body schema corresponding to the response message of the ES9_TerminalAuthRequest message is shown in Table 40 below, for example.
  • ES9_NotifyResultRequest a feature of the ES9 interface, is a message that the LPA requests SM-SR + to notify of the event result.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es9 / notify-result".
  • JSON body schema corresponding to the request message of the ES9_NotifyResultRequest message is shown in Table 41 below.
  • JSON body schema corresponding to the response message of the ES9_NotifyResultRequest message is shown in Table 42 below.
  • the ES9_FactoryEventRequest is a message that the LPA requests SM-SR + for profile download events for a particular eUICC in bulk profile provisioning.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es9 / factory-event”.
  • the JSON body schema corresponding to the request message of the ES9_FactoryEventRequest message is shown in Table 43, for example.
  • JSON body schema corresponding to the response message of the ES9_FactoryEventRequest message is shown in Table 44 below.
  • ES9 + .InitiateAuthentication a feature of the ES9 + interface (the interface between LPA and SM-DP +), is a message that the LPA requests SM-DP + to initiate authentication.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es9 / init-auth”.
  • the JSON body schema corresponding to the request message of the ES9 + .InitiateAuthentication message is shown in Table 45, for example.
  • the JSON body schema corresponding to the response message of the ES9 + .InitiateAuthentication message is shown in Table 46, for example.
  • ES9.GetBoundProfilePackage a feature of the ES9 + interface, is a message for LPA to request a profile package (BPP) combined with SM-DP +.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es9 / get-bound”.
  • the JSON body schema corresponding to the request message of the ES9.GetBoundProfilePackage message is shown in Table 49, for example.
  • JSON body schema corresponding to the response message of the ES9.GetBoundProfilePackage message is shown in Table 50 below.
  • ES11_PSRequest or "ES11_PSListRequest", which is a function of the ES11 interface (the interface between the LPA and the SM-DS), is a message for the LPA to request a push service or a list of push services from the SM-DS.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es11 / push-service”.
  • the JSON body schema corresponding to the request message of the ES11_PSRequest or ES11_PSListRequest message is shown in Table 51, for example.
  • JSON body schema corresponding to the response message of the ES11_PSRequest or ES11_PSListRequest message is shown in Table 52, for example.
  • ES11_PSRegistrationRequest which is a function of the ES11 interface, is a message that the LPA requests the SM-DS to register the LPA for push notification.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es11 / push-service / registration”.
  • the JSON body schema corresponding to the request message of the ES11_PSRegistrationRequest message is shown in Table 53, for example.
  • JSON body schema corresponding to the response message of the ES11_PSRegistrationRequest message is shown in Table 54, for example.
  • ES11_PSConfirmRequest a function of the ES11 interface, is a message that the LPA requests the SM-DS to return the registration result of the push service.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es11 / push-service / confirm”.
  • the JSON body schema corresponding to the request message of the ES11_PSConfirmRequest message is shown in Table 55, for example.
  • the JSON body schema corresponding to the response message of the ES11_PSConfirmRequest message is shown in Table 56, for example.
  • the ES11_EventIDRequest is a message that the LPA requests to return to the SM-DS one or more pending event IDs associated with a particular EID.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es11 / event-id”.
  • the JSON body schema corresponding to the request message of the ES11_EventIDRequest message is shown in Table 57, for example.
  • JSON body schema corresponding to the response message of the ES11_EventIDRequest message is shown in Table 58, for example.
  • ES11_DeleteEventRequest a function of the ES11 interface, is a message that the LPA requests SM-DS to delete a specific event.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es11 / delete-event”.
  • JSON body schema corresponding to the request message of the ES11_DeleteEventRequest message is shown in Table 59 below.
  • the JSON body schema corresponding to the response message of the ES11_DeleteEventRequest message is shown in Table 60, for example.
  • ES12_RegisterEventRequest which is a function of the ES12 interface (e.g., the interface between SM-SR + and SM-DS), is a message that SM-SR + requests SM-DS to insert an event. If a push token is registered for the EID, the SM-DS sends a push token to the corresponding push server.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es12 / register-event”.
  • the JSON body schema corresponding to the request message of the ES12_RegisterEventRequest message is shown in Table 61, for example.
  • JSON body schema corresponding to the response message of the ES12_RegisterEventRequest message is shown in Table 62, for example.
  • ES12_DeleteEventRequest a function of the ES12 interface, is a message that SM-SR + requests SM-DS to delete a specific event.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es12 / delete-event”.
  • the JSON body schema corresponding to the request message of the ES12_DeleteEventRequest message is shown in Table 63, for example.
  • JSON body schema corresponding to the response message of the ES12_DeleteEventRequest message is shown in Table 64, for example.
  • ES13_URLRequest which is a function of the ES13 interface (the interface between the LPA and the MNO), is a message that the LPA requests the MNO to return a URL for processing a subscription request or activation voucher validation.
  • ⁇ Query path> of the message may be, for example, "/ v1 / es13 / url”.
  • JSON body schema corresponding to the request message of the ES13_URLRequest message is shown in Table 65 below.
  • the JSON body schema corresponding to the response message of the ES13_URLRequest message is shown in Table 66, for example.
  • Functions of the UE-eUICC interface (ie, ES10) illustrated in Table 3 may be communicated using a data length in a TLV (tag length value) format through an application protocol data unit (APDU) protocol.
  • APDU application protocol data unit
  • the ES10 interface between the terminal and the eUICC may satisfy the following requirements.
  • the requirement is that, before transmitting the APDU, the terminal (i.e., LPA) opens the logical channel using the "MANAGE CHANNEL” command, selects the TAF application using the "SELECT" command, and selects the TAF.
  • the AID has a value such as "A0 00 00 05 59 10 10 FF FF FF FF 89 00 00 03 00".
  • the functions for the ES10 interface between the terminal and the eUICC include a Remote Management Function (RMF) and a Local Management Function (LMF).
  • RMF Remote Management Function
  • LMF Local Management Function
  • the LPA can call the RMF of the eUICC by sending a "STORE DATA" command.
  • the data field of the "STORE DATA" command may be coded according to Table 67.
  • the data may be split and transmitted through a plurality of "STORE DATA" commands.
  • Response data of the “STORE DATA” command may be coded according to the following Table 68.
  • response data size is larger than 255 bytes, chaining of instructions may be performed. That is, the response data may be retrieved by the LPA by using a plurality of "GetResponse" commands.
  • the tag value of the data field may be automatically assigned through the AUTOMATIC TAG option of Abstract Syntax Notation One (ASN.1).
  • the RMF may include a Remote Management Request TLV and a Remote Management Response TLV.
  • the remote management request TLV can be passed from the LPA to the eUIICC by using the "STORE DATA" command.
  • the eUICC may transmit a remote management response TLV using a "STORE DATA APDU” response or a "GET RESPONSE APDU” response as a response to the delivered remote management request TLV.
  • the LPA may send a "GetAuthData" request message to trigger the eUICC to prepare for authentication of the SM-SR +, SM-DP + or SM-SR +, and may receive a response message from the eUICC.
  • the schema of the request message of the GetAuthData message is shown in Table 69, for example.
  • the schema of the response message of the GetAuthData message is shown in Table 70, for example.
  • the LPA may send an "EstablishSecureChannel" request message to the eUICC to convey parameters for session key agreement, and receive a response message from the eUICC.
  • the schema of the request message of the EstablishSecureChannel message is shown in Table 71, for example.
  • the schema of the response message of the EstablishSecureChannel message is shown in Table 72, for example.
  • the LPA may send an eUICC a "InstallProfileRecord" request message to receive ProfileRecordPart2 protected by the established secure channel SCP03t and receive a response message from the eUICC.
  • the eUICC If the eUICC receives the InstallProfileRecord request message and a valid SCP03t channel is established, the eUICC treats "SCP03tCommandTLV" in the request TLV as the session key SCP03 of the secure channel indicated. On the other hand, if there is no valid channel SCP03t, the eUICC will return a response TLV indicating failure.
  • the schema of the response message of the InstallProfileRecord message is shown in Table 74, for example.
  • the LPA may send an eUICC a "UpdateSessionKey" request message passing the profileProtectionKey to replace the session key established with the profileProtectionKey previously created and used to protect the profile package, and receive a response message from the eUICC.
  • the schema of the request message of the UpdateSessionKey message is shown in Table 75, for example.
  • the schema of the response message of the UpdateSessionKey message is shown in Table 76, for example.
  • the LPA may send an eUICC a "InstallProfilePackageBlock" request message that conveys the data SecuredProfilePackageBlock received from SM-SR + or SM-DP +, and receive a response message from the eUICC.
  • the LPA may send a "ReleaseSecureChannel" request message to the eUICC to release the secure channel and associated session key, and receive a response message from the eUICC.
  • the eUICC may remove the stored SCP03t secure channel session key set.
  • the LPA may send an eUICC "eUICCManagement" request message to deliver an event with srToken2 included in the ES9_eUICCManagementResponse message delivered from SM-SR +, and receive a response message from the eUICC.
  • the schema of the request message of the eUICCManagement message is shown in Table 81 below, for example.
  • the schema of the response message of the eUICCManagement message is shown in Table 82, for example.
  • the LPA may send a "TerminalAuth" request message to the eUICC to trigger the eUICC to prepare for authentication of SM-SR + for device swap authentication or local erase authentication, and receive a response message from the eUICC.
  • the schema of the request message of the TerminalAuth message is shown in Table 83, for example.
  • the scheme of the response message of the TerminalAuth message is shown in Table 84, for example.
  • the LPA can invoke the LMF of the eUICC by sending the "STORE DATA" command.
  • the data field of the "STORE DATA" command may be coded according to Table 85.
  • the data may be split and transmitted through a plurality of "STORE DATA" commands.
  • the response data of the "STORE DATA" command may be coded according to the following Table 86.
  • response data size is larger than 255 bytes, chaining of instructions may be performed. That is, the response data can be queried by the LPA by using a plurality of "GetResponse" commands.
  • the tag value of the data field may be automatically assigned through the AUTOMATIC TAG option of ASN.1.
  • the LMF may include a Local Management Request TLV and a Local Management Response TLV.
  • the local management request TLV can be passed from the LPA to the eUIICC by using the "LOCAL STORE DATA" command.
  • the eUICC may transmit a local management response TLV using a "STORE DATA APDU” response or a "GET RESPONSE APDU” response as a response to the delivered local management request TLV.
  • the LPA may send a "LocalManagement" request message to the eUICC to deliver a localEvent containing detailed information about the local management event, and receive a response message from the eUICC.
  • the schema of the request message of the LocalManagement message is shown in Table 87, for example.
  • the schema of the response message of the message is shown in Table 88, for example.
  • eUICC can deliver ProfileRegistry to LPA through ES10_eUICCManagementResponse.
  • the ProfileRegistry in the eventResult may include the ProfileRecord of the profile. If the event.profileID is NULL, ProfileRegistry may include ProfileRecords of all profiles, and authorizedSR of the profile may include the SRID of the requesting SM-SR +.
  • the localEventResult, defaultSR, and ownerMNO TLVs are present in the LocalManagementResponse when localEventType has a value of one of ⁇ enableProfile, disableProfile, or deleteProfile ⁇ and PPRLocalMgmtNotification.notiEventList contains the corresponding EventToBeNotified.
  • sign_Result may be calculated using SK_eUICC_ECDSA for all value data in LocalEventResult except itself (sign_Result). For example, when eventType is 'disableProfile', the sign_Result may be calculated for resultCode
  • Certificate CERT_ECDSA for signature verification used in the present disclosure may have a format as shown in Table 89 below.
  • the private key used to calculate the signature '5F37' in the certificate CERT_ECDSA is as follows.
  • SK.CI.ECDSA used for CERT_CI_ECDSA, CERT_DP_ECDSA, CERT_SR_ECDSA, CERT_EUM_ECDSA
  • the data to be signed are the tags '93', '42', '5F20', '95', '5F25', '5F24', '73', 'TBD' (if any), and '7F49'.
  • the tag 'TBD' (ie, the list of PLMNIDs) is present when the value of the tag 'C8' in the tag '73' (ie, Discretionary data) indicates '01 SM-DP + Certificate '.
  • Discretionary Data (: free data), which is a data object that may be included in the format of the certificate, may have a format as shown in Table 90 below.
  • the Discretionary Data includes a delimiter for distinguishing between EUM certificate recognition (eg, '04', '03') and CI certificate recognition (eg, '05').
  • EUM certificate recognition eg, '04', '03'
  • CI certificate recognition eg, '05'
  • the eUICC or SM-SR + can transmit the EUM certificate together with the eUICC certificate.
  • SM-DP + does not need to acquire the EUM certificate separately, and the eUICC can be authenticated through the CI certificate, thereby increasing the interoperability.
  • List of PLMNIDs (a list of PLMNIDs), which are data objects that may be included in the format of the certificate, may have a format as shown in Table 91 below.
  • the 'List of PLMNIDs' TLV exists when the value of the tag' C8 'in the data object Discretionary data indicates '01 SM-DP + Certificate'.
  • the value of the 'List of PLMNIDs' TLV is a series of PLMN IDs, which are distinguished by a delimiter '%'. For example, when the 'List of PLMNIDs' TLV indicates two PLMN IDs '45008' and '310280', the value may be equal to '45008% 310280'.
  • the format according to ASN.1 notation of the 'List of PLMNIDs' TLV is VisibleString.
  • the PLMN ID included in the 'List of PLMNIDs' TLV indicates a PLMN ID of a profile allowed to be provisioned by SM-DP +, and the SM-DP + may be identified by a 'D1' tag in the data object Discretionary data. .
  • a public key (: public key) that is a data object that may be included in the format of the certificate may have a format as shown in Table 92 below.
  • the certificate CERT_ECKA for key approval used in the present disclosure may have a format as shown in Table 93 below.
  • the private key used to calculate the signature '5F37' in the certificate CERT_ECKA is as follows.
  • the data to be signed are the tags '93', '42', '5F20', '95', '5F25', '5F24', '73', and '7F49'.
  • the certificate CERT_TLS used for mutual authentication of a TLS connection in the present disclosure may be as disclosed in RFC 5280.
  • the common name (CN) of the TLS certificate is DPID.
  • the Common Name (CN) of the TLS certificate is SRID.
  • the TLS certificate is issued for SM-DS, the Common Name (CN) of the TLS certificate is a DSID.
  • TLV structure used in the present disclosure is defined according to the ASN.1 notation.
  • the TLV structure may be encoded using Distinguished Encoding Rule (DER) encoding.
  • DER Distinguished Encoding Rule
  • the TLV of the ES10 interface (e.g., the interface between the eUICC and the LPA) may have a data structure as shown in Table 94 below.
  • the TLV of the ES11c interface (the interface between the push client and the RMF) may have a data structure as shown in Table 95 below.
  • the TLV of Profile, Profile Policy and Profile Management may have a data structure as shown in Table 96 below.
  • the TLV of eUICC Policy and Management may have a data structure as shown in Table 97 below.
  • the TLV for the entity and the ID may have a data structure as shown in Table 98 below.
  • the TLV for the event may have a data structure as shown in Table 99 below.
  • the TLV for the token may have a data structure as shown in Table 100 below.
  • the TLV for Local Managements may have a data structure as shown in Table 101 below.
  • the TLV for security may have a data structure as shown in Table 102 below.
  • TLVs may have a data structure as shown in Table 103 below.
  • FIG. 8 is a diagram illustrating a configuration of a terminal device of the present disclosure.
  • the terminal 800 receives profile information from a profile information delivery server, and receives the profile from a transceiver (or communication unit) 810 that receives a profile from a profile providing server using the profile information.
  • the controller 820 may be connected to a communication service.
  • the terminal 800 may further include a removable or fixed eUICC.
  • the APs 412, 442, and 472 of FIG. 4 may be implemented by the controller 820, and the CPs 414, 444, and 474 may be implemented by the transceiver 810.
  • the transceiver 810 and the controller 820 are illustrated as separate components, but may be implemented as one component.
  • the terminal may also be called an electronic device.
  • FIG. 9 is a diagram illustrating a configuration of a server device according to the present disclosure.
  • SM-DP + SM-DS
  • SM-SR + etc.
  • the SM-DP + 900 includes a controller 920 for generating and encrypting a profile, transferring profile information to the SM-DS, and converting the encrypted profile into the SM-DP +. It may include a transceiver 910 for transmitting to the terminal using the eUICC.
  • the controller 920 may receive a profile download request from the electronic device and control the electronic device to transmit a profile installable on a universal integrated circuit card (UICC) of the electronic device.
  • the profile information may be used for a profile download request of the electronic device.
  • the SM-DS 900 When the server 900 is an SM-DS, the SM-DS 900 includes a transceiver 910 for receiving profile information from the SM-DP_ and transferring profile information to a terminal. It may include a control unit 920 to control the (910). The SM-DS 900 may further include a storage unit capable of storing profile information (temporarily storing profile information). The controller 920 may register the profile information received from the SM-DP + and control the transfer of the profile information to the electronic device corresponding to the profile information. The profile information may be used by the electronic device to download a profile installable in the UICC of the electronic device from the SM-DP +.
  • the SM-SR + 900 transmits profile information and transmits and receives the encrypted profile to the terminal using the eUICC and the transceiver 910 and the transceiver 910 May include a control unit 920.
  • the controller 920 may receive a profile download request from the electronic device and control the electronic device to transmit a profile installable on a universal integrated circuit card (UICC) of the electronic device.
  • the profile information may be used for a profile download request of the electronic device.
  • FIGS. 1 to 9 are not intended to limit the scope of the present disclosure. That is, all of the components, or steps of the operations described in FIGS. 1 to 9 should not be interpreted as essential components for the implementation of the present disclosure, and a range that does not impair the essence of the present disclosure even if only some of the components are included. It can be implemented within.
  • the above-described operations can be realized by providing a memory device storing the corresponding program code to an entity, a function, a base station, or any component in the terminal device of the communication system. That is, the controller of an entity, a function, a base station, or a terminal device can execute the above-described operations by reading and executing a program code stored in a memory device by a processor or a central processing unit (CPU).
  • a processor or a central processing unit (CPU).
  • Various components of an entity, function, base station, or terminal device, module, and the like described in the present disclosure may be a hardware circuit, for example, a complementary metal oxide semiconductor based logic circuit. And hardware circuitry such as firmware and a combination of software and / or hardware and software embedded in firmware and / or machine readable media.
  • various electrical structures and methods may be implemented using transistors, logic gates, and electrical circuits such as application specific semiconductors.

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 이동통신 시스템에서 eUICC(embed universal integrated circuit card)를 구비하는 단말의 프로파일 설치 방법에 있어서, eUICC에게 eUICC 인증서를 요청하여 상기 eUICC 인증서를 수신하는 동작; 및 프로파일 패키지를 eUICC에게 전달하여 상기 프로파일을 설치하는 동작을 포함하되, 상기 수신되는 eUICC 인증서는 EUM(eUICC manufacturer) 인증서를 더 포함함을 특징으로 하는 방법을 제공한다.

Description

통신 시스템에서 프로파일을 관리하는 기법
본 개시는 통신 시스템에서 단말에 통신 서비스를 다운로드 및 설치하여 통신 연결을 하기 위한 방법 및 장치에 관한 것으로써, 통신 시스템에서 실시간으로 프로파일을 다운로드하고 설치하는 방법 및 장치에 관한 것이다.
4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE 시스템 이후 (Post LTE) 이후의 시스템이라 불리어지고 있다. 높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파 (mmWave) 대역 (예를 들어, 60기가 (60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍 (beamforming), 거대 배열 다중 입출력 (massive MIMO), 전차원 다중입출력 (Full Dimensional MIMO: FD-MIMO), 어레이 안테나 (array antenna), 아날로그 빔형성 (analog beam-forming), 및 대규모 안테나 (large scale antenna) 기술들이 논의되고 있다. 또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀 (advanced small cell), 클라우드 무선 액세스 네트워크 (cloud radio access network: cloud RAN), 초고밀도 네트워크 (ultra-dense network), 기기 간 통신 (Device to Device communication: D2D), 무선 백홀 (wireless backhaul), 이동 네트워크 (moving network), 협력 통신 (cooperative communication), CoMP (Coordinated Multi-Points), 및 수신 간섭제거 (interference cancellation) 등의 기술 개발이 이루어지고 있다. 이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM (Hybrid FSK and QAM Modulation) 및 SWSC (Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC (Filter Bank Multi Carrier), NOMA (non orthogonal multiple access), 및 SCMA (sparse code multiple access) 등이 개발되고 있다.
한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT (Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터 (Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크 (sensor network), 사물 통신 (Machine to Machine, M2M), MTC (Machine Type Communication) 등의 기술이 연구되고 있다. IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT (Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT (information technology) 기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크 (sensor network), 사물 통신 (Machine to Machine, M2M), MTC (Machine Type Communication) 등의 기술이 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크 (cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.
UICC(Universal Integrated Circuit Card)는 이동 통신 단말기 등에 삽입하여 사용되는 스마트카드(smart card)인데 'UICC 카드'라고도 부른다. 상기 UICC에는 이동통신사업자(MNO; mobile network operator)의 망에 접속하기 위한 접속 제어 모듈이 포함될 수 있다. 이러한 접속 제어 모듈의 예로는 USIM (Universal Subscriber Identity Module), SIM (Subscriber Identity Module), ISIM (IP Multimedia Service Identity Module) 등이 있다. USIM이 포함된 UICC를 통상 USIM 카드라고 부르기도 한다. 마찬가지로 SIM 모듈이 포함된 UICC를 통상적으로 SIM카드라고 부르기도 한다.
본 개시의 이후 설명에서 UICC 카드라 함은 SIM 카드, USIM 카드, ISIM이 포함된 UICC 등을 포함하는 통상의 의미로 사용될 수 있다. 즉, UICC 카드로써 설명된 기술적 내용은, USIM 카드 또는 ISIM 카드 또는 일반적인 SIM 카드에도 동일하게 적용될 수 있다.
UICC 카드는 이동 통신 가입자의 개인정보를 저장하고, 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽(traffic) 보안 키(secure key) 생성을 수행하여 안전한 이동통신 이용을 가능하게 한다. 상기 UICC 카드는 본 개시를 제안하는 시점에서 일반적으로 카드 제조 시 특정 이동통신사업자(즉, MNO)의 요청에 의해 해당 MNO를 위한 전용 카드로 제조되며, 해당 MNO 의 네트워크 접속을 위한 인증 정보 예를 들어, USIM (Universal Subscriber Identity Module) 어플리케이션 및 IMSI (International Mobile Subscriber Identity), K 값, OPc 값 등이 사전에 카드에 탑재되어 출고될 수 있다.
따라서 제조된 UICC 카드는 해당 이동통신사업자가 납품받아 가입자에게 제공되며, 이후 필요시에는 OTA(Over The Air) 등의 기술을 활용하여 상기 UICC 내 어플리케이션의 설치, 수정, 삭제 등의 관리도 수행할 수 있다. 가입자는 소유한 이동통신 단말기에 상기 UICC 카드를 삽입하여 해당 이동통신 사업자의 네트워크 및 응용 서비스의 이용이 가능하며, 단말기 교체 시 상기 UICC 카드를 기존 단말기에서 새로운 단말기로 이동 삽입함으로써 상기 UICC 카드에 저장된 인증정보, 이동통신 전화번호, 개인 전화번호부 등을 새로운 단말기에서 그대로 사용이 가능하다.
그러나 상기 UICC 카드는 이동통신 단말기 사용자가 다른 이동통신사의 서비스를 제공받는데 있어 불편한 점이 있다. 이동통신 단말기 사용자는 이동통신사업자로부터 서비스를 받기 위해 UICC 카드를 물리적으로 획득해야 되는 불편함이 있다. 예를 들면, 사용자가 다른 나라로 여행을 했을 때 현지 이동통신 서비스를 받기 위해서는 현지 UICC 카드를 구해야 하는 불편함이 있다. 로밍 서비스의 경우 상기 불편함을 어느 정도 해결해 주지만, 비싼 요금 및 통신사간 계약이 되어 있지 않은 경우 서비스를 받을 수 없는 문제도 있다.
한편, UICC 카드에 SIM 모듈을 원격으로 다운로드 받아서 설치할 경우, 이러한 불편함을 상당부분 해결할 수 있다. 즉 사용자가 원하는 시점에 사용하고자 하는 이동통신 서비스의 SIM 모듈을 UICC 카드에 다운로드 받을 수 있다. 이러한 UICC 카드는 또한 복수 개의 SIM 모듈을 다운로드 받아서 설치하고 그 중의 한 개의 SIM 모듈만을 선택하여 사용할 수 있다.
이러한 UICC 카드는 단말에 고정하거나 고정하지 않을 수 있다. 특히 단말에 고정하여 사용하는 UICC를 eUICC (embedded UICC)라고 하는데, 통상적으로 eUICC는 단말에 고정하여 사용되고, 서버로부터 원격으로 SIM 모듈을 다운로드 받아서 선택할 수 있는 UICC 카드를 의미한다.
이러한 eUICC의 사용을 위해서는 프로파일이 eUICC 에서 다운로드 및 설치되어야 한다. 따라서, eUICC 의 프로파일 관리 기법이 요구된다.
본 개시는 통신 시스템에서 단말이 통신 연결을 하기 위한 프로파일을 실시간으로 다운로드 하는 방법 및 장치를 제공한다.
또한, 본 개시는 통신 시스템에서 단말에 프로파일을 제공하는 장치 및 방법을 제공한다.
본 개시는 이동통신 시스템에서 eUICC(embed universal integrated circuit card)를 구비하는 단말의 프로파일 설치 방법에 있어서, eUICC에게 eUICC 인증서를 요청하여 상기 eUICC 인증서를 수신하는 동작; 상기 eUICC에게 상기 eUICC 정보를 요청하여 상기 eUICC 정보를 수신하는 동작; 상기 eUICC 정보를 포함하는 다운로드 초기화 메시지를 프로파일 제공서버에게 전송하는 동작; 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 포함하는 상기 다운로드 초기화 메시지에 대한 응답 메시지를 수신하는 동작; 상기 응답 메시지에 포함된 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 상기 eUICC에게 전달하는 동작; 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 상기 eUICC로부터 수신하는 동작; 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 포함하는 프로파일패키지 요청 메시지를 상기 프로파일 제공서버에게 전송하는 동작; 및 상기 프로파일패키지 요청 메시지에 대한 응답으로 수신한 프로파일 패키지를 eUICC에게 전달하여 상기 프로파일을 설치하는 동작을 포함하되, 상기 수신되는 eUICC 인증서는 EUM(eUICC manufacturer) 인증서를 더 포함함을 특징으로 하는 방법을 제안한다.
본 개시는 이동통신 시스템에서 eUICC(embed universal integrated circuit card)를 구비하는 단말 장치에 있어서, eUICC에게 eUICC 인증서를 요청하여 상기 eUICC 인증서를 수신하고, 상기 eUICC에게 상기 eUICC 정보를 요청하여 상기 eUICC 정보를 수신하고, 상기 eUICC 정보를 포함하는 다운로드 초기화 메시지를 프로파일 제공서버에게 전송하고, 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 포함하는 상기 다운로드 초기화 메시지에 대한 응답 메시지를 수신하고, 상기 응답 메시지에 포함된 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 상기 eUICC에게 전달하고, 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 상기 eUICC로부터 수신하고, 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 포함하는 프로파일패키지 요청 메시지를 상기 프로파일 제공서버에게 전송하고, 상기 프로파일패키지 요청 메시지에 대한 응답으로 수신한 프로파일 패키지를 eUICC에게 전달하여 상기 프로파일을 설치하도록 제어하는 제어부; 및 상기 제어부의 제어에 의해 상기 수신 또는 전송동작을 수행하는 송수신부를 포함하되, 상기 수신되는 eUICC 인증서는 EUM(eUICC manufacturer) 인증서를 더 포함함을 특징으로 하는 단말을 제안한다.
본 개시에 따르면, 통신 시스템에서 프로파일을 다운로드 및 설치하여 통신 연결을 하기 위한 장치 및 그 방법이 제공된다. 또한, 상기 장치에서 프로파일을 다운로드 할 수 있도록 프로파일을 전송하는 장치 및 프로파일 정보를 전달하는 장치 및 그의 동작 방법이 제공된다.
본 개시에 따르면 무선 통신 시스템에서, 통신 서비스를 이용할 수 있는 프로파일이 이동통신 단말에 설치될 수 있다.
도 1은 단말에 고정된 프로파일이 탑재된 UICC를 이용한 단말의 이동통신 네트워크 연결방법을 도시하는 도면;
도 2는 eUICC의 원격 프로파일 설치 및 관리를 위한 시스템의 전체 구조를 예시하는 도면;
도 3은 eUICC의 내부 구조을 설명하는 도면;
도 4는 LPA 기능이 구현되는 방식에 따라서 단말의 구성을 예시하는 도면;
도 5a, 5b는 통신 시스템에서 단말의 eUICC가 프로파일을 다운로드하는 방법을 예시하는 도면;
도 6a, 6b는 본 개시에 따른 프로파일 설치 다른 방법을 예시하는 도면;
도 7a, 7b, 7c은 복수 단말을 위한 벌크 프로파일을 한번에 프로비져닝 하는 방법을 예시하는 도면;
도 8은 본 개시의 단말 장치의 구성을 예시하는 도면;
도 9는 본 개시에 따른 서버 장치의 구성을 예시하는 도면이다.
이하, 첨부된 도면들을 참조하여 본 개시의 실시예를 상세하게 설명한다. 하기에서 본 개시를 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로써 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 개시 전반에 걸친 내용을 토대로 내려져야 할 것이다.
본 개시의 자세한 설명에 앞서, 본 개시에서 사용되는 몇 가지 용어들에 대해 해석 가능한 의미의 예를 제시한다. 하지만, 아래 제시하는 해석 예로 한정되는 것은 아님을 주의하여야 한다.
본 개시에서는 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드를 eUICC로 통칭한다. 즉, 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하거나 고정하지 않는 UICC 카드를 eUICC로 통칭한다. 또한 eUICC에 다운로드되는 SIM 모듈정보를 통칭하여 eUICC 프로파일(profile)이라는 용어로 호칭한다.
본 개시에서 UICC는 이동통신 단말기에 삽입하여 사용하는 스마트카드로서 이동통신 가입자의 네트워크 접속 인증 정보, 전화번호부, SMS(short message service)와 같은 개인정보가 저장되어 GSM(global system for mobile communication), WCDMA(wideband code division multiple access), LTE(long term evolution) 등과 같은 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽 보안 키 생성을 수행하여 안전한 이동통신 이용을 가능케 하는 칩을 의미한다. UICC에는 가입자가 접속하는 이동통신 네트워크의 종류에 따라 SIM(Subscriber Identification Module), USIM(Universal SIM), ISIM(IP Multimedia SIM)등의 통신 어플리케이션이 탑재되며, 또한 전자 지갑, 티켓팅, 전자 여권 등과 같은 다양한 응용 어플리케이션의 탑재를 위한 상위 레벨의 보안 기능을 제공할 수 있다.
본 개시에서 eUICC(embedded UICC)는 단말에 삽입 및 탈거가 가능한 탈착식이 아니고 단말에 내장된 칩 형태의 보안 모듈일 수 있다. eUICC는 OTA(Over The Air)기술을 이용하여 프로파일을 다운받아 설치할 수 있다. eUICC는 프로파일 다운로드 및 설치가 가능한 UICC로 명명될 수 있다.
본 개시에서 eUICC에 OTA 기술을 이용하여 프로파일을 다운받아 설치하는 방법은 단말에 삽입 및 탈거가 가능한 탈착식 UICC에도 적용될 수 있다. 즉, 본 개시의 실시예에는 OTA 기술을 이용하여 프로파일을 다운받아 설치 가능한 UICC에 적용될 수 있다.
본 개시에서 용어 UICC는 SIM과 혼용될 수 있고, 용어 eUICC는 eSIM과 혼용될 수 있다.
본 개시에서 프로파일(profile)은 UICC내에 저장되는 어플리케이션, 파일시스템, 인증키 값 등을 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.
본 개시에서 'USIM 프로파일'은 '프로파일'과 동일한 의미 또는 프로파일 내 USIM 어플리케이션에 포함된 정보를 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.
본 개시에서 '프로비져닝 프로파일'은 'USIM 프로파일'과 같은 다른 프로파일을 다운로드하기 위한 프로파일이며, 생산 단계에서 eUICC 내에 미리 탑재되어 있을 수 있다.
본 개시에서 프로파일 제공서버는 SM-DP(Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation plus), 프로파일 도메인의 off-card 엔티티(off-card entity of Profile Domain), 프로파일 암호화 서버, 프로파일 생성서버, 프로파일 제공자(Profile Provisioner; PP), 프로파일 공급자(Profile Provider), PPC holder(Profile Provisioning Credentials holder) 로 표현될 수 있다.
본 개시에서 프로파일정보 전달서버는 DPF (Discovery and Push Function), 또는 SM-DS (Subscription Manager Discovery Service)로 표현될 수 있다.
본 개시에서 프로파일 관리서버는 SM-SR(Subscription Manager Secure Routing), SM-SR+ (Subscription Manager Secure Routing Plus), eUICC 프로파일 관리자의 off-card 엔티티 (off-card entity of eUICC Profile Manager) 또는 PMC holder (Profile Management Credentials holder), EM(eUICC Manager)로 표현될 수 있다.
본 개시에서 프로파일 제공서버(또는 SM-DP+)는 프로파일 제공서버와 프로파일 관리서버의 기능을 합친 것을 통칭하는 것일 수도 있다. 즉, 이후의 기술에서 프로파일 제공서버의 동작은 프로파일 관리서버에서 이루어질 수 있음을 유의하여야 한다. 마찬가지로, 프로파일 관리서버(또는 SM-SR+)에 대하여 기술하는 동작은 프로파일 제공서버에서 수행될 수도 있음은 물론이다.
본 개시에서 사용하는 용어 '단말'은 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(Access Terminal), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말은 예를 들어, 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악 저장 및 음악 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기일 수 있다. 또한, 단말은 M2M(Machine to Machine) 단말, MTC(Machine Type Communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 개시에서 상기 단말은 전자 장치라 지칭될 수도 있다.
본 개시에서 전자 장치는 프로파일을 다운로드하여 설치 가능한 UICC가 내장될 수 있다. UICC가 전자 장치에 내장되지 않은 경우, 물리적으로 전자 장치와 분리된 UICC는 전자 장치에 삽입되어 전자 장치와 연결될 수 있다. 예를 들어, 카드 형태로 UICC는 전자 장치에 삽입될 수 있다. 상기 전자 장치는 상기 단말을 포함할 수 있고, 이때, 단말은 프로파일을 다운로드하여 설치 가능한 UICC를 포함하는 단말일 수 있다. 상기 단말에 UICC는 내장될 수 있을 뿐만 아니라, 단말과 UICC가 분리된 경우 UICC는 단말에 삽입될 수 있고, 단말에 삽입되어 단말과 연결될 수 있다. 프로파일을 다운로드하여 설치 가능한 UICC는 예를 들어 eUICC라 지칭할 수 있다.
본 개시에서 프로파일 구분자는 프로파일 식별자(Profile ID), ICCID (Integrated Circuit Card ID), ISD-P(Issuer Security Domain Profile) 또는 프로파일 도메인(Profile Domain, PD)와 매칭되는 인자로 지칭될 수 있다. 프로파일 ID는 각 프로파일의 고유 식별자를 나타낼 수 있다.
본 개시에서 eUICC 식별자(eUICC ID)는, 단말에 내장된 eUICC의 고유 식별자일 수 있고, EID로 지칭될 수 있다. 또한 eUICC에 프로비져닝 프로파일 (Provisioning Profile)이 미리 탑재되어 있는 경우, eUICC 식별자(eUICC ID)는 상기 프로비져닝 프로파일의 식별자 (Provisioning Profile의 Profile ID)일 수 있다. 또한 본 개시의 실시예에서와 같이 단말과 eUICC 칩이 분리되지 않을 경우, eUICC 식별자(eUICC ID)는 단말 ID일 수도 있다. 또한, eUICC 식별자(eUICC ID)는 eUICC칩의 특정 보안 도메인 (Secure Domain)을 지칭할 수도 있다.
본 개시에서 프로파일 컨테이너(Profile Container)는 프로파일 도메인(Profile Domain)으로 명명될 수 있다. 프로파일 컨테이너는 보안 도메인 (Security Domain) 일 수 있다.
본 개시에서 APDU(application protocol data unit)는 단말이 eUICC와 연동하기 위한 메시지일 수 있다. 또한 APDU는 프로파일 제공서버 또는 프로파일 관리서버가 eUICC와 연동하기 위한 메시지일 수도 있다.
본 개시에서 PPC (Profile Provisioning Credentials)는 프로파일 제공서버와 eUICC 간 상호 인증 및 프로파일 암호화, 서명을 하는데 이용되는 수단일 수 있다. PPC는 대칭키, RSA(rivest shamir adleman) 인증서(certificate)와 개인 키(private key), ECC(elliptic curved cryptography) 인증서와 개인 키, 최상위 인증 기관(Root certification authority(CA)) 및 인증서 체인(chain) 중 하나 이상을 포함할 수 있다. 또한 프로파일 제공서버가 복수 개인 경우에는 복수 개의 프로파일 제공서버별로 다른 PPC를 eUICC에 저장하거나 사용할 수 있다.
본 개시에서 PMC (Profile Management Credentials)는 프로파일 관리서버와 eUICC 간 상호 인증 및 전송 데이터 암호화, 서명을 하는데 이용되는 수단일 수 있다. PMC는 대칭키, RSA 인증서와 개인 키, ECC 인증서와 개인 키, Root CA 및 인증서 체인 중 하나 이상을 포함할 수 있다. 또한 프로파일 관리서버가 복수 개인 경우에는 복수 개의 프로파일 관리서버별로 다른 PMC를 eUICC에 저장하거나 사용할 수 있다.
본 개시에서 AID는 어플리케이션 식별자 (Application Identifier)이며, eUICC 내에서 서로 다른 어플리케이션을 구분해줄 수 있다.
본 개시에서 프로파일 패키지 TLV(Profile Package TLV)는 Profile TLV 로 명명될 수 있다. Profile Package TLV는 TLV (Tag, Length, Value) 형식으로 프로파일을 구성하는 정보를 표현하는 데이터 세트(data set)일 수 있다.
본 개시에서 AKA(Authentication and Key agreement)는 인증 및 키 승인을 나타낼 수 있으며, 3GPP(3rd generation partnership project) 및 3GPP2 망에 접속하기 위한 인증 알고리즘을 나타낼 수 있다.
본 개시에서 K 는 AKA 인증 알고리즘에 사용되며 eUICC에 저장되는 암호화 키(encryption key) 값이다.
본 개시에서 OPc는 AKA 인증 알고리즘에 사용되며 eUICC에 저장될 수 있는 파라미터 값이다.
본 개시에서 NAA(Network Access Application)는 네트워크 접속 어플리케이션으로, UICC에 저장되어 망에 접속하기 위한 USIM 또는 ISIM과 같은 응용프로그램일 수 있다. NAA는 망접속 모듈일 수 있다.
도 1은 단말에 고정된 프로파일이 탑재된 UICC를 이용한 단말의 이동통신 네트워크 연결방법을 도시하는 도면이다.
도 1을 참조하면, 단말(110)에 UICC(120)가 삽입될 수 있다. 이때, 상기 UICC(120)는 탈착형 일 수도 있고 단말에 미리 내장된 것일 수도 있다. 고정된 프로파일이 탑재된 UICC의 상기 고정된 프로파일은 특정 통신사에 접속할 수 있는 '접속정보'가 고정되어 있음을 의미한다. 상기 접속정보는 예를 들어, 가입자 구분자인 IMSI(International Mobile Subscriber Identity), 상기 가입자 구분자와 함께 망 인증에 필요한 K 또는 Ki 값일 수 있다.
그러면 상기 단말은 상기 UICC를 이용하여 이동통신사의 인증처리시스템 (예를 들어, HLR(home location register) 이나 AuC(Authentication Center))과 인증을 수행할 수 있다. 상기 인증의 과정은 AKA(Authentication and Key Agreement; 인증 및 승인) 과정일 수 있다. 인증에 성공하면 단말은 상기 이동통신시스템의 이동통신네트워크(130)를 이용하여 전화나 모바일 데이터 이용 등의 이동통신 서비스를 이용할 수 있게 된다.
도 2는 eUICC의 원격 프로파일 설치 및 관리를 위한 시스템의 전체 구조를 예시하는 도면이다.
eUICC(232)는 단말(230) 내에 내장되거나 탈착이 가능한 형태의 UICC카드 또는 칩이다. 상기 eUICC(232)는 폼 팩터(Form Factor) 2FF, 3FF, 4FF 또는 MFF1, MFF2 의 크기를 가질 수도 있고, 이와 다른 다양한 물리적인 크기를 가질 수도 있다. 상기 eUICC는 단말과 별개의 장치로 구현되어 상기 단말에 부착될 수도 있지만, 상기 단말의 통신 칩(예를 들어, CP(communication processor) 또는 기저대역(baseband) 모뎀)에 집적(Integrate)되어 구현될 수도 있다.
프로파일 제공서버(Profile Provider; PP)(200)는 프로파일을 생성하거나 생성된 프로파일을 암호화 하는 기능을 수행할 수 있다. 상기 프로파일 제공서버(200)는 SM-DP+로 지칭될 수도 있다.
프로파일 관리서버(eUICC Manager; EM)(202)는 SM-DP+로부터 전달받은 프로파일을 단말(230)의 LPA(Local Profile Assistant)에 전달할 수 있고 상기 프로파일의 관리를 수행할 수 있다. 상기 프로파일 관리서버(202)는 SM-SR+ 로 지칭될 수도 있다. 상기 SM-SR+(202)은 SM-DP+(200)와 단말(230)(즉, LPA) 사이에서 프로파일 다운로드 또는 프로파일 관리 동작을 제어할 수 있다.
상기 프로파일 제공서버(200) 및 프로파일 관리서버(202)는 하나의 서버로 구현될 수 있고, 상기 하나의 서버는 SM-DP+ 또는 SM+ 로 지칭될 수도 있다.
프로파일정보 전달서버(204) (즉, DPF) 는 SM-SR+ 로부터 SM-SR+ 서버 주소 또는 이벤트 구분자를 전달받아 LPA(230)에게 전달할 수 있다.
이밖에도, 상기 시스템에는 이동망사업자(MNO; mobile network operator)(210), eUICC 제조사(eUICC manufacture)(220), 또는 인증서 발행기관(CI; certificate issuer)이 더 포함될 수 있다.
MNO(210)은 프로파일의 다운로드 및 관리 프로세스에 관여하며, 프로파일이 설치된 eUICC로부터의 요청에 의해 이동통신 서비스를 제공할 수 있다.
eUICC 제조사(EUM; eUICC manufacturer)(220)은 인증서 컨텐츠를 개인 키로 서명함으로써 eUICC 인증서를 발행할 수 있다.
인증서 발행기관(240)은 인증서 컨텐츠를 개인 키로 서명함으로써 EUM 인증서, EM 인증서 또는 PP 인증서를 발행할 수 있다.
또한, 도 2는 서버와 서버 간 인터페이스(예를 들어, ES3), 단말과 서버간 인터페이스(예를 들어, ES9), 단말과 eUICC 간 인터페이스 (예를 들어, ES10) 등을 표시하고 있다. 상기 인터페이스 및 상기 인터페이스에 의해 제공되는 기능에 대해서는 나중에 자세히 설명될 것이다.
도 3은 eUICC의 내부 구조을 설명하는 도면이다.
eUICC(300)는 기본적으로 카드 또는 칩과 같은 형태일 수 있지만, 소프트웨어 형식인 적어도 하나의 프로파일(320, 330)이 설치될 수 있다. 이에, 상기 eUICC는 eUICC OS(operating system)(302) 상에서 동작할 수 있다. 도 3은 eUICC(300) 내에 두개의 프로파일(320, 330)이 탑재되어 있으며, 현재는 하나의 프로파일(320)이 인에이블(enable) 상태에 있고, 다른 하나의 프로파일(33)은 디스에이블 상태에 있음을 나타내고 있다.
TAF(Terminal API function)(306)는 단말(즉, LPA)에 정의된 RMF(Remote Management Function) 및 LMF(Local Management Function)을 전달받아 직접 처리하거나 eUICC(300) 내부의 다른 기능 (예를 들어, CMF(308) 또는 PEF(316)) 에서 처리할 수 있도록 하는 기능이다. TAF(306)는 eUICC의 ISD-R(Issuer Security Domain Root)과 동일하거나 다를 수도 있다.
ISD-R(304)는 eUICC(300)의 바닥(base)에 위치하는 보안 도메인이다.
CMF(Certificate Management Function)(308)는 eUICC(300) 내부에서 다음의 데이터(또는 정보)를 저장할 수 있다.
- 하나 이상의 eUICC 인증서 및 연관된 개인 키
- eUICC 인증서를 서명한 EUM (eUICC Manufacture)의 인증서
- 하나 이상의 CI (Certificate Issuer)인증서
eUICC(300)의 내부 요청에 따라 상기 CMF(308)는 다음의 동작 중 적어도 하나를 수행할 수 있다.
- eUICC 인증서 또는 EUM 인증서를 제공
- EM 인증서를 CI 인증서의 공개 키(public key)로 검증
- EM 개인 키로 서명된 서명값(signature)을 EM 인증서의 공개 키로 검증
- PP 인증서를 CI 인증서의 공개 키로 검증
- PP 개인 키로 서명된 서명값을 EM 인증서의 공개 키로 검증
PEF(Policy Enforcement Function)(316)는 eUICC(300)에 설정된 정책 룰 (Policy Rule)(314)을 실행하는 역할을 한다. 상기 정책 룰(314)에는 프로파일 정책 룰(Profile Policy Rule; PPR)과 eUICC 정책 룰 (eUICC Policy Rule; EPR)이 있다.
상기 Profile Policy Rule (PPR)은 프로파일 내부에 저장되고, MNO의 OTA 키(key)에 의해 제어되거나, 특정 SM-DP+ 의 서명값에 의해 제어 될수 있다.
상기 eUICC Policy Rule (EPR)은 프로파일 외부에 저장되고, 특정 SM-DP+ 서명값이나 특정 SM-SR+의 서명값에 의해 제어될 수 있다.
상기 eUICC Policy Rule (EPR)은 정책 룰에 대한 소유자 ID (owner ID) 및 설정하고자 하는 룰로 구성될 수 있다. 상기 소유자 ID는 SM-DP+ 또는 SM-SR+의 유효한 인증서 및 개인 키를 소유한 서버의 ID일 수 있다.
PPI(Profile Package Interpreter)(310)은 복호화된 프로파일 정보를 해석하여 설치가능한 단위로 설치하는 기능이다. PPI는 PIF(Profile Interpreter Function)로 지칭될 수도 있다.
프로파일 레지스트리(Profile Registry)(312)는 eUICC(300)에 설치된 개별 프로파일을 관리하기 위한 개별 프로파일별 정보 즉, 프로파일 레코드(Profile Record)를 포함할 수 있다. eUICC(300)는 프로파일이 설치될 때, SM-DP+ 또는 SM-SR+에서 전달받은 정보를 이용하여 프로파일 레코드를 프로파일 레지스트리의 일부로 구축하고, 추후 프로파일을 관리하는데 이용할 수 있다.
다음 표 1은 상기 프로파일 레지스트리(312)의 정보(즉, ProifileRegisty) 구성의 일 예를 보여준다.
Figure PCTKR2016003858-appb-T000001
표 1을 참고하면, ProfileRecord는 다음의 정보 중 하나 이상을 포함할 수 있다. ProfileRecord는 ProfileMetadata라고 지칭될 수도 있다.
- 프로파일ID 또는 ICCID
- 프로파일 제공 MNO의 PLMNID
- 프로파일 설명 (예를 들면, 전화번호)
- 프로파일 타입
- Notification(통지)을 받을 서버ID (SM-DP+ 주소 또는 SM-SR+ 주소)
- Notification을 받을 서버ID (MNO 서버 주소)
- ProfileRecord를 수정할 수 있는 서버ID (SM-DP+ 주소 또는 SM-SR+ 주소)
도 4는 LPA 기능이 구현되는 방식에 따라서 단말의 구성을 예시하는 도면이다.
단말은 eUICC의 프로파일 다운로드, 설치, 관리 동작을 지원하기 위해 서버와 통신을 수행하는 LPA(Local Profile Assistant)를 포함할 수 있다. 상기 LPA는 AP(application processor)와 CP(communication processor)에 의해 구현될 수 있다.
단말의 LPA 기능은 RMF(Remote Management Function), LMF(Local Management Function), UIF(User Interface Function) 중 적어도 하나를 포함할 수 있다.
RMF (Remote Management Function)은 SM-SR+, SM-DP+, SM-DS, LMF, eUICC중 하나 이상과 직접 또는 간접적으로 연동하여, eUICC의 원격 관리 이벤트를 수행할 수 있다. 예를 들어, 상기 RMF는 네트워크에 의해 시작되는(initiated) 프로파일 다운로드/인에블/디스에이블/삭제 동작과 정책 룰 다운로드 동작을 지원할 수 있다.
LMF (Local Management Function)은 UIF, RMF, eUICC중 하나 이상과 직접 또는 간접적으로 연동하여 eUICC의 로컬 관리 이벤트를 수행할 수 있다. 예를 들어, 상기 LMF는 단말에 의해 시작되는 프로파일 인에이블/디스에이블/삭제 동작 또는 eUICC 리셋(reset) 동작을 지원할 수 있다. 상기 LMF는 결과 통보(result notification)를 위해 SM-SR+와 인터페이스 할 수도 있다.
UIF (User Interface Function)은 RMF/LMF 와 사용자 사이의 데이터 교환을 지원할 수 있다. 상기 UIF는 사용자의 입력을 LMF에 전달하는 UI를 포함할 수 있다.
도 4(a)는 LPA의 기능이 AP 중심적(AP centric)으로 구현되는 경우를 예시한다. LPA(410)는 AP(412) 및 CP(414)를 포함하지만, RMF, LMF, UIF는 모두 LPA(410) 내의 AP(412)에 의해 구현된다. 상기 AP(412)는 SM-DS(400), SM-SR+(402), 및 사용자와 인터페이스하여 eUICC(420)의 관리 이벤트를 수행할 수 있다.
도 4(b)는 LPA의 기능이 CP 중심적(CP centric)으로 구현되는 경우를 예시한다. LPA(440)는 AP(442) 및 CP(444)를 포함하지만, RMF, LMF 는 모두 LPA(440) 내의 CP(444)에 의해 구현된다. 상기 CP(444)는 SM-DS(430), SM-SR+(432)와 인터페이스하여 eUICC(450)의 관리 이벤트를 수행할 수 있다.
도 4(c)는 LPA의 기능이 하이브리드(hybrid) 방식으로 구현되는 경우를 예시한다. RMF, LMF 는 LPA(470) 내의 CP(474)에 의해 구현되지만, UIF는 상기 LPA(470) 내의 AP(472)에 의해 구현된다. 상기 UIF는 사용자(464) 및 상기 CP(474) 내의 LMF와 인터페이스 하여 eUICC(480)의 관리 이벤트를 수행할 수 있고, 상기 CP(474) 내의 RMF는 SM-DS(460), SM-SR+(462)와 인터페이스하여 eUICC(480)의 관리 이벤트를 수행할 수 있다.
도 5a, 5b는 통신 시스템에서 단말의 eUICC가 프로파일을 다운로드하는 방법을 예시하는 도면이다.
도 5를 참고하면 SM-DP+(500)는 SM-SR+ 없이 LPA(502)와 직접 IP 기반의 HTTPS 를 이용하여 통신할 수 있다.
SM-DP+(500)는 SM-DP+의 서명용 인증서 (CERT.DP.ECDSA; certificate of DP used for digital signature verification) 및 서명용 개인 키 (SK.DP.ECDSA; private key of DP for digital signature verification)를 내부 저장소에 보관할 수 있다. 상기 SM-DP+(500)는 HTTPS 를 위한 TLS(Transport Layer Security)용 서버 인증서 (CERT.DP.TLS; certificate of DP used for TLS) 및 개인 키 (SK.DP.TLS; private key of DP for TLS)도 내부 저장소에 보관할 수 있다. 상기 인증서 CERT.DP.ECDSA, SK.DP.ECDSA, CERT.DP.TLS, 및 SK.DP.TLS 가 저장되는 내부 저장소는 물리적으로 같은 저장장치이거나 다른 저장장치일 수 있다.
eUICC(504)는 eUICC의 서명용 인증서 (CERT.EUICC.ECDSA; certificate of eUICC used for digital signature verification) 및 개인 키 (SK.eUICC.ECDSA; private key of eUICC for digital signature verification)를 내부 저장소에 보관할 수 있다.
상기 단말의 프로파일 다운로드 과정은 다음과 같다.
LPA(502)가 eUICC(504)에 ES10b.GetCertificate 메시지를 전송하여 eUICC 인증서를 요청하면(510), 상기 eUICC(504)는 상기 LPA(502)에게 eUICC 인증서 CERT.eUICC.ECDSA를 반환할 수 있다(512). 이때, 상기 eUICC(504)는 상기 eUICC 인증서뿐만 아니라 EUM 인증서 CERT.EUM.ECDSA(: certificate of EUM used for digital signature verification)도 함께 반환할 수 있다. 대안적으로, 상기 eUICC 인증서나 EUM 인증서가 상기 LPA(502)에 저장되어 있었다면, 상기 510, 512 동작은 수행되지 않을 수도 있을 것이다.
만약 LPA(502)가 eUICC의 서명값을 SM-DP+(500)에 전달해야 한다면, 상기 LPA(502)는 eUICC(504)에게 ES10b.GetSignature 메시지를 전송하여 서명값 생성을 요청할 수 있다. 이때 서명에 들어가는 인자는 LPA(502)에서 전달해 주는 값이며, 상기 값은 EventID (특정 프로파일 다운로드 이벤트를 구분하는 구분자), NotificationID (EventID와 유사함), MatchingID (EventID와 유사함), Activation Code Token (EventID와 유사함), 및 단말에서 생성한 랜덤값 중 적어도 하나를 포함할 수 있다.
만약 상기 LPA(502)가 상기 eUICC의 서명값이 필요없는 경우, 상기 LPA(502)는 상기 eUICC(504)에게 ES10b.GetEUICCInfo 메시지를 전송하여 eUICC의 정보(eUICC Info)를 요청할 수 있다(514).
상기 eUICC(504)는 상기 LPA(502)의 요청(514)에 대응하여, eUICC challenge를 생성한다(516). 상기 eUICC challenge는 상기 eUICC(504)가 추후 상기 SM-DP+(500)를 인증하기 위해 생성하는 랜덤 값이다.
eUICC(504) 는 LPA(502)에 eUICC_Info 를 반환할 수 있다(518). 상기 eUICC_Info는 eUICC challenge 또는 eUICC의 버전 정보 등을 포함할 수 있다.
LPA(502)는 SM-DP+(500)에 ES9+.InitiateDownload 메시지를 호출할 수 있다(520). 상기 ES9+.InitiateDownload 메시지의 호출전 LPA와 SM-DP+ 사이에 HTTPS 세션 연결이 수립될 수 있다. 상기 HTTPS 세션 연결은 프로파일 다운로드 전과정에서 같은 세션이 이용될 수도 있고, 과정별로 다른 세션이 이용될 수도 있다. 선택적으로, 상기 ES9+.InitiateDownload는 ES9.InitiateAuthentication 또는 ES9.EventRequest 일 수도 있다.
상기 ES9+.InitiateDownload 메시지에는 eUICC Info가 포함될 수 있고, 예를 들어, 상기 eUICC(504)에서 생성된 eUICC Challenge가 포함될 수 있다. 또한 상기 ES9+.InitiateDownload 메시지에는 eUICC 인증서 또는 EUM 인증서가 포함될 수도 있다.
SM-DP+(500)가 eUICC 인증서를 전달받은 경우에는, 상기 SM-DP+(500)는 CI 인증서 또는 CI 인증용 공개 키(PK.CI.ECDSA; public key of CI used for digital signature verification)를 이용하여 EUM 인증서를 검증할 수 있다. 상기 SM-DP+(500)는 상기 검증된 EUM 인증서를 이용하여 eUICC 인증서를 검증하고, 상기 eUICC 인증서를 이용하여 eUICC 서명값을 검증할 수 있다. 선택적으로, 상기 인증서 검증 및 서명 검증은 생략될 수도 있다.
상기 SM-DP+(500)는 eUICC_Info 를 기반으로 eUICC(504)의 적합성(eligibility)을 체크할 수 있다(522). 이때, 상기 SM-DP+(500)는 eUICC_Info의 eUICC 버전 정보를 이용하여 상기 eUICC(504)의 적합성을 체크할 수 있다.
그리고 상기 SM-DP+(500)는 랜덤값 DP Challenge를 생성할 수 있다(522). 상기 DP Challenge는 추후 SM-DP+(500)가 eUICC(504)를 인증하기 위해 생성하는 값이다.
그리고 SM-DP+(500)는 TransactionID를 생성할 수 있다(522). 상기 TransactionID는 SM-DP+(500)가 복수개의 단말 요청들을 동시에 처리할 수 있도록 특정 프로파일 다운로드 세션을 구분해주는 구분자이다. 이와 같은 TransactionID로 구분하지 않을 경우, SM-DP+(500)는 한번에 하나의 단말에 대해서만 프로파일을 다운로드 할 수 있고, 만약 특정 단말이 SM-DP+와 연동중 응답을 지연한다면, 다른 단말이 프로파일을 다운로드 할 수 없을 것이다. 이러한 다운로드 불능을 해결하기 위해, SM-DP+(500)가 특정 세션의 라이프타임(lifetime)을 적용하여 일정 시간이 경과한 세션을 삭제할 수도 있지만, 이 경우에는 상기 SM-DP+(500)가 처리할 수 있는 성능에는 여전히 한계가 존재한다. 그러나, 상기 TransactionID 에 의하면 복수 개의 세션 구분이 가능하고, 따라서 SM-DP+(500)는 복수 개의 단말로부터의 요청을 처리할 수 있게 된다.
만약 SM-DP+(500)가 LPA(502)로부터 MatchingID를 전달받았거나, EID 를 전달받은 경우, SM-DP+(500)는 상기 MatchingID에 대응되거나 상기 EID에 대응되는 다운로드 대상 프로파일이 있는지 확인할 수도 있다.
그리고, SM-DP+(500)는 eUICC Challenge, DP Challenge, TransactionID 값을 포함하는 데이터에 대하여 서명용 개인키 SK.DP.ECDSA(: Private Key of DP used for digital signature verification) 를 이용하여 DP 서명값 (DP Signature)을 생성할 수 있다(522).
상기 DP 서명값은 eUICC(504)에서 SM-DP+(500)를 인증하기 위한 서명값이다.
SM-DP+(500)는 상기 ES9+.InitiateDownload(520)에 대한 응답으로써 SM-DP+(500)의 서명용 인증서 CERT.DP.ECDSA, DP Challenge, TransactionID, DP Signature를 전달할 수 있다(524).
LPA(502)는 상기 응답(524)를 받으면, eUICC(504)에게 ES10b.PrepareDownload 메시지를 전달할 수 있다(526). 상기 ES10b.PrepareDownload는 ES10.GetAuthDataRequest 일 수도 있다. 상기 ES10b.PrepareDownload 메시지는 CERT.DP.ECDSA, DP Challenge, TransactionID, DP Signature를 포함할 수 있다.
eUICC(504)는 DP 인증서 CERT.DP.ECDSA 를 상기 eUICC(504)에 저장된 CI 인증서 또는 CI의 공개 키를 이용하여 검증할 수 있다(528).
상기 인증서 CERT.DP.ECDSA 의 검증에 성공하면 eUICC는 SM-DP+(500)의 서명값 DP Signature를 검증할 수 있다(528). 상기 eUICC(504)의 상기 DP Signature의 검증에는, LPA(502)로부터 전달받은 DP Challenge, TransactionID, 상기 eUICC(504)가 상기 LPA(502)에 전달했던 eUICC Challenge, 그리고 CERT.DP.ECDSA에 포함되어 있는 SM-DP+(500)의 공개 키 PK.DP.ECDSA가 이용될 수 있다.
상기 DP Signature의 검증이 통과되면, 상기 eUICC(504)는 1회용 비대칭키 쌍(otPK.EUICC.ECKA, otSK.EUICC.ECKA)을 생성할 수 있다(528). 대안적으로, 상기 ES10b.PrepareDownload(526)이 특정 SM-DP+ 로부터 트리거된 경우이거나, LPA(502)가 별도의 지시자(indicator)로 상기 ES10b.PrepareDownload(526)를 요청한 경우에는, 상기 eUICC(504)는 1회용 비대칭키 쌍을 생성하지 않고 사전에 생성했던 1회용 비대칭키 쌍을 로드하여 사용할 수도 있다.
상기 eUICC(504)의 1회용 비대칭키 쌍은 SM-DP+(500)의 1회용 비대칭키 쌍과 함께 상기 SM-DP+(500)와 eUICC(504)간의 암호화 키를 생성하는데 사용될 수 있다. 상기 암호화 키는, SM-DP+(500)에 의해서 SM-DP+(500)의 1회용 개인 키와 eUICC(504)의 1회용 개인 키 결합으로 생성되거나, eUICC(504)에 의해 eUICC(504)의 1회용 개인 키와 SM-DP+(500)의 1회용 공개 키 결합으로 생성될 수 있다. 상기 암호화 키 생성에 추가로 필요한 인자는 SM-DP+(500)가 이후의 단계에서 LPA(502)를 통해 eUICC에 전달할 수 있다.
eUICC(504)는 상기 생성한 1회용 비대칭키 쌍중 1회용 공개 키 (otPK.EUICC.ECKA) 및 DP Challenge 를 포함하는 데이터에 대하여 eUICC의 서명용 개인 키 (SK.eUICC.ECDSA)를 이용하여 eUICC 서명값(eUICC_Sign2)을 계산할 수 있다(528). 상기 eUICC_Sign2 계산에 SM-DP+(500)가 생성한 DP Challenge를 포함했기 때문에 상기 eUICC_Sign2 은 이후 스텝에서 SM-DP+(500)가 eUICC(504)를 인증하는 용도로 사용될 수 있다. 또한 상기 eUICC_Sign2는 eUICC가 생성한 otPK.EUICC.ECKA 값을 SM-DP+(500)에게 변조되지 않고 전달하는 역할을 할 수 있다.
eUICC(504)는 상기 생성한 eUICC의 1회용 공개 키 otPK.EUICC.ECKA 및 생성한 eUICC 서명값 eUICC_Sign2을 LPA(502)에 전달할 수 있다(530).
LPA(502)는 SM-DP+(500)에게 프로파일패키지 요청 메시지 ES9+GetBoundProfilePackage 를 전달할 수 있다(532). 상기 ES9+GetBoundProfilePackage(532)는 eUICCManagementRequest 또는 ProfileRequest와 같이 명명될 수도 있다.
상기 ES9+GetBoundProfilePackage(532)는 1회용 eUICC 공개 키 및 상기 eUICC 서명이 포함될 수 있다. 추가적으로, 상기 ES9+GetBoundProfilePackage(532)에는 eUICC 서명값 검증을 위한 eUICC 서명용 인증서 (CERT.EUICC.ECDSA) 및 eUICC 서명용 인증서 검증을 위한 EUM 인증서 (CERT.EUICC.ECDSA)도 전달될 수 있다. 추가적으로, 특정 프로파일을 다운로드하는데 구분자로 활용될 수 있는 EventID, MatchingID, NotificationID 또는 Activation Code Token 이 상기 ES9+GetBoundProfilePackage(532)에 포함될 수도 있다.
SM-DP+(500)가 eUICC 인증서를 전달받은 경우에는, 상기 SM-DP+(500)는 CI 인증서 또는 CI 인증용 공개 키(PK.CI.ECDSA)를 이용하여 EUM 인증서를 검증할 수 있다. 상기 SM-DP+(500)는 상기 검증된 EUM 인증서를 이용하여 eUICC 인증서를 검증하고, 상기 eUICC 인증서를 이용하여 eUICC 서명값을 검증할 수 있다. 선택적으로, 상기 인증서 검증 및 서명 검증은 생략될 수도 있다.
그리고 SM-DP+(500)는 상기 532 동작에서 LPA(502)로부터 전달받은 1회용 eUICC 공개 키 및 상기 524 동작에서 LPA(502)에 전달했던 DP Challenge 와 eUICC 인증서에 포함된 공개 키를 이용하여 eUICC 서명 (즉, eUICC_Sign2)를 검증할 수 있다(534). 상기 eUICC_Sign2의 검증이 통과한 경우 SM-DP+(500)는 eUICC(504)를 인증한 것이 된다. 만약 상기 검증에 실패한 경우 SM-DP+(500)는 해당 세션에 대한 동작을 멈추고 LPA(502)에게 에러를 리턴할 수 있다.
SM-DP+(500)는 상기 532 단계에서 전달받은 EventID (또는 NotificationID, MatchingID, Activation Code Token)값을 이용하여 다운로드할 프로파일을 매핑할 수 있다. 만약 다운로드할 프로파일이 없는 경우 에러를 리턴하고 해당 세션을 종료할 수 있다.
SM-DP+(500)는 1회용 DP 비대칭키 쌍(otPK.DP.ECKA, otSK.DP.ECKA)을 생성할 수 있다(534). 상기 SM-DP+(500)는 상기 1회용 DP 비대칭키 쌍을 이용하여 eUICC(504)와 SM-DP+(500) 간의 암호화 키를 생성할 수 있다(534). 상기 암호화 키 생성 방식은 다음과 같다.
- SM-DP+(500)가 SM-DP+의 1회용 개인 키와 eUICC의 1회용 개인 키를 결합하여 암호화 키 생성하는 방식
- eUICC(504)가 eUICC(504)의 1회용 개인 키와 SM-DP+의 1회용 공개 키를 결합하여 암호화 키 생성하는 방식
그리고 SM-DP+(500)는 SM-DP+ 서명값 (DP Signature2)을 계산할 수 있다(534). 상기 서명값 DP Signature2은 CRT(control reference template), SM-DP+의 1회용 공개 키, eUICC의 1회용 공개 키, TransactionID를 포함하는 데이터에 대하여 SM-DP+의 서명용 개인 키(SK.DP.ECDSA)를 이용하여 계산한 값이다. 상기 CRT는 암호화 키 생성의 인자로 사용할 수 있다.
SM-DP+(500)는 특정 eUICC에 결합된 프로파일 패키지(Bound Profile Package; BPP)를 생성할 수 있다(534). 상기 BPP는 CRT, SM-DP+(500)의 1회용 공개 키, DP Signature2 를 포함할 수 있다. 또한 상기 BPP는 상기 암호화 키로 암호화된 ProfileInfo (또는 MetaData)를 포함할 수 있다. 또한 상기 BPP는, 프로파일 보호 키(Profile Protection Key; PPK)를 상기 생성한 암호화 키로 암호화한, 암호화된 PPK를 포함할 수 있다. 또한 상기 BPP는 상기 생성한 암호화 키 또는 상기 PPK로 암호화된 프로파일 패키지 블록(Profile Package Block; PPB) 들을 포함할 수 있다. 상기 암호화된 PPB들은, 전체 프로파일 데이터가 설치 가능한 단위인 프로파일 엘리먼트(Profile Element; PE)로 쪼개진 후, 암호화 가능 크기 단위로 나뉘어진 상기 PPB가 암호화된 것이다. 상기 PPB의 암호화에는 SCP03t 프로토콜이 사용될 수 있다.
SM-DP+(500)는 상기 ES9+GetBoundProfilePackage(532)에 대한 응답으로 LPA(502)에게 BPP를 반환할 수 있다(536).
LPA(502)는 ES10b.LoadBoundProfilePackage 를 복수(N) 회 수행하여 상기 BPP에 포함된 ES8+.InitializeSecureChannel 정보를 eUICC(504)에 전달할 수 있다(538). 상기 ES8+.InitializeSecureChannel 정보는 CRT, SM-DP+의 1회용 공개 키, DP Signature2 를 포함할 수 있다. 상기 ES8+.InitializeSecureChannel 는 EstablishSecureChannel 를 지칭할 수도 있다. 상기 ES10b.LoadBoundProfilePackage 는 "StoreData" 명령어를 전송하는 것일 수 있다.
eUICC(504)는 상기 526 단계에서 전달받은 DP 서명용 인증서 CERT.DP.ECDSA의 공개 키 PK.DP.ECDSA, 상기 538 단계에서 전달받은 CRT, SM-DP+의 1회용 공개 키 및 상기 530 단계에서 LPA(502)에 전달했던 eUICC의 1회용 공개 키를 이용하여 DP 서명 (DP Signature2)를 검증할 수 있다(540).
상기 검증(540)에 실패하면, 상기 eUICC(504)는 에러를 LPA(502)에게 리턴하고 이후 과정을 수행하지 않는다. 상기 검증(540)에 통과하면, eUICC(504)는 CRT, eUICC의 1회용 개인 키, SM-DP+의 1회용 공개 키를 이용하여 암호화 키를 생성할 수 있다. 선택적으로, 상기 eUICC(504)는 N 회의 APDU를 상기 ES10b.LoadBoundProfilePackage(538)에 대한 응답으로써 상기 LPA(502)에게 전달할 수 있다(542).
LPA(502)는 ES10b.LoadBoundProfilePackage 를 복수(N) 회 수행하여 BPP에 포함된 ES8+SetProfileInfo 정보를 eUICC(504)에게 전달할 수 있다(544). 상기 ES8+SetProfileInfo는 ES8+.StoreMetadata 또는 InstallProfileRecord로 지칭할 수도 있다. 상기 ES8+SetProfileInfo에는 ProfileInfo (또는 Metadata 또는 ProfileRecord)가 포함될 수 있다. 선택적으로, 상기 eUICC(504)는 N 회의 APDU를 상기 ES10b.LoadBoundProfilePackage(544)에 대한 응답으로써 상기 LPA(502)에게 전달할 수 있다(546).
선택적으로, LPA(502)는 ES10b.LoadBoundProfilePackage 를 복수(N) 회 수행하여 ES8+.ReplaceSessionKey 정보를 eUICC(504)에게 전달할 수도 있다(548). 즉, LPA(502)가 SM-DP+(500)으로부터 전달받은 BPP에 ES8+.ReplaceSessionKey가 포함된 경우, 상기 LPA(502)는 ES10b.LoadBoundProfilePackage 를 N 회 수행하여 상기 BPP에 포함된 ES8+ReplaceSessionKeys 정보를 eUICC에 전달할 수 있다. 상기 ES8+ReplaceSessionKeys 는 UpdateSessionKeyRequest로 지칭될 수 있다. 상기 ES8+ReplaceSessionKeys 는 상기 534 단계의 암호화 키로 암호화한 ProfileProtectionKey(PPK)가 포함할 수 있다. 선택적으로, 상기 eUICC(504)는 N 회의 APDU를 상기 ES10b.LoadBoundProfilePackage(548)에 대한 응답으로써 상기 LPA(502)에게 전달할 수 있다(550).
이후 LPA(502)는 ES10b.LoadBoundProfilePackage 를 복수(N) 회 수행하여 상기 BPP에 포함된 암호화된 PPB(Profile Package Block) 또는 프로파일 세그먼트(Profile Segment) 들을 eUICC(504)에게 전달할 수 있다(552). 상기 각 Profile Segment는 상기 암호화 키 또는 PPK로 복호화되어 순서대로 eUICC(504)에서 처리될 수 있다.
모든 Profile Segment 처리후 eUICC(504)는 eUICC 서명값을 계산하여 LPA(502)에게 전달할 수 있다(554). 이때 LPA(502)는 ES9+.SendResult를 통해 상기 eUICC 서명값을 SM-DP+(500)에게 전달함으로써 프로파일 설치 결과를 알려줄 수 있고(556), 상기 SM-DP+(500)은 확인(OK)을 전송할 수 있다(558).
도 6a, 6b는 본 개시에 따른 프로파일 설치의 다른 방법을 예시하는 도면이다.
도 5a, 5b와 비교할 때, 도 6a, 6b에서는 초기 라운드에서 eUICC의 Signature가 생략되며, 초기 라운드 이후의 동작이 보다 자세히 설명된다.
도 6a, 6b를 참조하면, LPA(620)은 프로파일 정보를 획득할 수 있다(640). 예를 들어, 상기 LPA(620)은 SM-DS로부터 SM-DP+(610)의 주소 및 프로파일 설치 키를 전달받을 수 있다. 상기 프로파일 설치 키는 EventID, MatchingID, NotificationID 또는 Activation Code Token 일 수 있다. 여기서, eUICC(630)는 LPA(620)에 삽입되거나, 내장되어 있는 것으로 LPA(620)과 eUICC(630)의 동작은 단말의 내부 동작으로 해석될 수 있다.
LPA(620)은 상기 획득한 프로파일 설치 키 정보를 이용하여 비밀코드를 입력할 수 있다(642). 상기 642 동작은 필수 동작은 아니며, 비밀코드가 있는 경우 선택적으로 수행될 수 있다.
LPA(620)은 eUICC(630)에 eUICC 챌린지(eUICC Challenge) 생성을 요청할 수 있다(644).
eUICC(630)는 LPA(620)이 eUICC Challenge 생성을 요청하면, eUICC Challenge를 생성 후 저장할 수 있다(646).
eUICC(630)는 생성된 eUICC Challenge 및 인증서 정보(Certificate_Info)를 LPA(620)에 전달할 수 있다(648). 상기 인증서 정보(Certificate_Info)는 eUICC 인증서 종류 및 사용 가능한 암호화 키 종류를 포함할 수 있다. 상기 암호화 키 정보는 타원 곡선 파라미터(Elliptic Curver Parameter)를 의미할 수 있다. 상기 암호화 키 정보는 복수 개일 수 있으며, 서명 생성에 사용할 정보와 서명 검증에 사용되는 정보를 구분하여 포함할 수 있다. 상기 타원 곡선 파라미터가 전달됨으로써, 서로 호환되는 타원곡선 파라미터를 SM-DP+가 선택할 수 있다.
LPA(620)은 eUICC Challenge, Certificate_Info에 추가로 상기 프로파일 정보에 포함된 SM-DP+(610) 주소 정보를 포함하여 상기 주소 정보에 해당하는 SM-DP+(610)에게 전달할 수 있다(650).
SM-DP+(610)는 상기 전달받은 정보에 포함된 SM-DP+가 유효한지 체크할 수 있다(652). 상기 유효한지 체크는 전달받은 SM-DP+ 주소 정보가 자신의 서버 주소와 동일한지를 검증하거나, 또는 복수 개의 유효한 주소 중에 대응되는지를 확인하는 것 일수 있다. 만약 상기 유효한지의 체크가 실패하면 상기 SM-DP+(610)는 에러코드를 LPA(620)에 전달하고 프로파일 다운로드 동작을 멈출 수 있다.
또한 SM-DP+(610)는 Certificate_Info를 체크할 수 있다(652). 우선 상기 SM-DP+(610)는 인증서 타입이 유효한지 체크할 수 있다. 그리고 암호화 키 정보가 SM-DP+(610)에서 지원 가능한 것인지 체크할 수 있다. 상기 체크는, eUICC(630)의 서명을 위한 암호화 키 정보와 SM-DP+(610)에서 검증 가능한 암호화 키 정보가 일치하는지와, EUICC(630)에서 검증을 위한 암호화 키 정보와 SM-DP+(610)에서 서명을 생성하는데 사용하는 암호화 키 정보가 일치하는지 비교하는 과정일 수 있다.
상기 체크 과정이 유효하면 SM-DP+(610)는 사용할 인증서 타입 및 암호화 키 정보를 저장한 후 트랜잭션ID(transactionID)를 생성할 수 있다(652). 상기 트랜잭션 ID를 이용하여 SM-DP+(610)는 이후의 LPA(620)로부터의 요청 메시지가 유효한지 확인할 수 있다. 또한 상기 트랜잭션ID는 하나의 SM-DP+가 동시에 복수 개의 단말로부터의 요청을 처리할 수 있는 구분자 역할도 할 수 있다.
이후 SM-DP+(610)는 DP 챌린지(DP Challenge)를 생성할 수 있다(652). DP 챌린지는 SM-DP+의 챌린지 또는 프로파일제공서버의 챌린지일 수 있다. 상기 DP Challenge는 16 바이트의 랜덤 번호일 수 있다.
이후 SM-DP+(610)는 DP_Sign1을 생성할 수 있다(652). 상기 DP_Sign1은 SM-DP+(610)가 eUICC_Challenge, DP_Challgene, TransactionID를 포함하여 생성한 서명값일 수 있다.
상기 652 동작이 정상적으로 수행되면, SM-DP+(610)는 LPA(620)에 인증 정보를 전달할 수 있다(654). SM-DP+(610)는 LPA(620)에 상기 트랜잭션ID, DP Challenge, DP_Sign1, SM-DP_ 인증서, Cert_ToBe_Used 정보를 전달할 수 있다. 상기 SM-DP+ 인증서는 ECDSA (Elliptic Curved Digital Signature Algorithm) 인증서일 수 있다. 상기 Cer_ToBe_Used는 사용하기로 하고 SM-DP+(610)에 저장된 인증서 타입 및 암호화 키 정보를 포함하는 정보일 수 있다.
LPA(620)은 상기 전달받은 정보에 추가로 단말의 현재시간, 프로파일제공서버 주소, 프로파일 설치 키 (AC_Token), 단말 정보, 및 해쉬된 비밀코드(confirmation code)를 eUICC(630)에 전달할 수 있다(656). 상기 해쉬된 비밀코드는 상기 642 동작이 수행된 경우에 전달될 수 있다. 또한 상기 656 동작을 수행하기 전 LPA(620)은 트랜잭션ID와 상기 SM-DP+ 주소를 함께 매핑하여 저장할 수 있다.
eUICC(630)는 상기 656 동작에서 수신한 정보에 기반하여 SM-DP+(610)를 검증할 수 있다(658).
eUICC(630)는 먼저 SM-DP+ 인증서 CERT.DP.ECDSA 를 검증한다(658). 상기 검증은 EUICC(630)에 저장되어 있는 CI (Certificate Issuer) 인증서 또는 CI 인증서의 공개 키를 이용한 서명 검증 방식일 수 있다. 상기 서명 검증은 Cert_ToBe_use에 포함된 정보를 이용하여 선택한 공개 키를 이용한 검증일 수도 있다.
상기 검증이 통과하면 eUICC(630)는 전달받은 DP_Sign1을 검증한다(658). 상기 검증은 상기 SM-DP+ 인증서에 포함된 공개 키를 이용한 서명 검증일 수 있다. 만약 이 검증이 통과하면 eUICC(620)는 SM-DP_(610)를 인증한 것이 된다.
이후 eUICC(630)은 1회용 공개 키 및 개인 키 쌍을 생성할 수 있다(658). 상기 공개 키 및 개인 키 쌍은 SM-DP+(610)에서도 별도의 값으로 생성되는데, 이렇게 생성된 값 중 공개 키만을 서로 교환할 경우, 공개 키와 개인 키를 결합하여 세션 키를 공유할 수 있다. 이때 공개 키를 1회용으로 함으로써 매번 프로파일을 다운로드 할 때마다 새로운 세션키를 공유할 수 있다.
이때 상기 공개 키를 안전하게 전달하기 위해서는 상기 공개 키를 이용하여 서명 값(eUICC_Sign1)을 생성하고 전달할 수 있다(658). 이를 위해, eUICC(630)는 상기 eUICC(630)의 1회용 공개 키와 함께 상기 전달받은 DP Challenge를 포함하여 eUICC(630)에 사전에 저장되어 있는 개인 키를 이용하여 서명을 할 수 있다. 상기 DP Challenge를 포함하여 서명을 함으로써 추후 SM-DP+(610)는 eUICC(630)를 인증할 수 있다. 상기 서명에는 이외에도 Transaction ID, SM-DP+ 주소, 프로파일 설치 키, 단말 정보, eUICC 정보, 그리고 해쉬된 비밀코드 값 중 하나 이상의 정보를 포함될 수 있으며, 상기 서명에 추가적으로 포함되는 정보들은 SM-DP+(610)의 추가적인 검증에 사용될 수 있다. 편의상 상기 서명을 eUICC_Sign1이라 칭한다. 상기 서명 생성시 상기 전달받은 Cert_ToBe_Used에 사용된 인증서 Type 및 암호화 키 정보에 맞는 eUICC의 개인 키를 선택하여 서명을 생성할 수 있다.
eUICC(630)는 LPA(620)에 eUICC 인증 정보를 전달할 수 있다(660). 상기eUICC 인증 정보는 eUICC의 1회용 공개 키, SM-DP+ 주소, 프로파일 설치 키, 단말 정보, eUICC 정보, 해쉬된 비밀코드 값, eUICC_Sign1, eUICC의 인증서, eUICC 인증서를 발급한 EUM 인증서 중 적어도 하나를 포함할 수 있다.
LPA(620)은 SM-DP+(610)에게 프로파일 요청메시지를 전송할 수 있다(662). 상기 프로파일요청 메시지는 상기 eUICC(630)로부터 전달받은 eUICC 인증 정보를 SM-DP(610)에게 전달할 수 있다. LPA(620)은 상기 656 동작 수행 전 저장했던 트랜잭션ID와 대응되는 SM-DP+ 주소로 상기 트랜잭션ID, 1회용 eUICC 공개 키, SM-DP+ 주소, 프로파일 설치 키, 단말 정보, eUICC 정보, 해쉬된 비밀코드 정보, eUICC_Sign1, eUICC 인증서, eUICC 인증서를 발행한 EUM 인증서 중 하나 이상을 포함하여 SM-DP+(610)에 전달할 수 있다.
SM-DP+(610)는 상기 662 동작에서 수신한 트랜잭션 ID를 확인하여 유효한 트랜잭션 ID가 있는지 확인한 후 없으면 에러코드를 LPA(620)에 리턴하고 다운로드 과정을 종료할 수 있다. 유효한 트랜잭션 ID라 함은 SM-DP+의 저장소나 메모리에 상기 트랜잭션ID가 저장되어 조회가 가능하고, 상기 트랜잭션ID에 대응되는 SM-DP+가 상기 654 동작은 수행하였지만 662 동작에 대응하는 메시지를 처음으로 받은 것을 예로 들 수 있다. 다만 이미 662 동작의 메시지를 수신하였는데 같은 트랜잭션 ID로 662 동작의 메시지를 수신한 경우, 경우에 따라서 에러 코드를 리턴하지 않을 수도 있다. 예를 들면, 662동작에서 먼저 수신한 메시지에 대하여 이후 기술되는 664의 동작이 수행되는 도중에 두번째 프로파일 요청 메시지를 송신한 경우, 두번째 프로파일 요청 메시지에 대하여 에러코드를 리턴하지 않고, 상기 두번째 메시지를 버릴 수도 있다.
이후 유효한 트랜잭션으로 판단된 프로파일 요청에 대하여, SM-DP+(610)는 eUICC를 검증할 수 있다(664).
SM-DP+(610)는 상기 EUM(eUICC 제조사) 인증서를 검증할 수 있다(664). 상기 검증은 우선 SM-DP+(610)에 저장되어 있는 CI 인증서에서 공개 키를 추출하여 이용하거나 또는 저장되어 있는 공개 키를 직접 이용하여 상기 eUICC제조사 인증서의 서명을 검증하는 방식일 수 있다.
이후 SM-DP+(610)는 상기 EUM 인증서에서 추출한 인증서의 공개 키를 이용하여 상기 전달받은 eUICC 인증서에 포함된 서명값을 검증하여 상기 eUICC 인증서를 검증할 수 있다(664).
이후 SM-DP+(610)는 상기 검증된 eUICC 인증서에 포함된 공개 키를 이용하여 상기 eUICC_Sign1 값을 검증할 수 있다(664). 이때 검증에 통과하면 SM-DP+(610)는 eUICC(630)를 인증한 것이 된다.
이후 SM-DP+(610)는 프로파일 설치 키(AC_Token)이 유효한지 검증할 수 있다(664). 이는 해당 프로파일 설치 키가 SM-DP+의 저장소에 저장된 값에 포함되는지 및 저장된 프로파일 설치 키에 대응되는 다운로드 가능한 프로파일이 존재하는지를 확인하는 과정일 수 있다.
또한 선택적으로, SM-DP+(610)는 해쉬된 비밀코드를 검증할 수 있다(664). 이는 저장된 해쉬한 비밀코드와 단순한 비교하는 것일 수 있고, 새로 해쉬한 비밀코드를 계산하여 비교하는 방식일 수 있다.
이후 SM-DP+(610)는 단말정보, eUICC정보 등을 비교하여 프로파일 설치가 가능한지의 적격성 판단을 추가적으로 수행할 수 있다(664). 상기 정보에는 접속 가능한 망 종류 및 설치 가능한 메모리 영역 정보를 포함할 수도 있다.
이상과 같은 검증을 통과한 경우에만 SM-DP+(610)는 프로파일 다운로드를 승인한 후 이후의 과정을 진행할 수 있다. 만약 검증에 실패한 경우 SM-DP+(610)는 LPA(620)에 에러코드를 리턴하고 프로파일 다운로드 과정을 종료할 수 있다. 이 경우 다운로드 과정을 종료하기 전에 저장했던 트랜잭션 ID 및 DP Challenge를 삭제한다. 검증에 통과한 경우, 상술한 것처럼, SM-DP+(610)는 1회용 프로파일제공서버 공개 키 및 비밀키 쌍을 생성할 수 있다(664). 상기 1회용 비대칭키 쌍 생성에 사용하는 암호화 키 정보는 상기 654 동작에서 전달한 Cert_ToBe_Used에 포함되어 있는 암호화 키의 정보일 수 있다.
상술한 것처럼, SM-DP+(610)는 상기 비밀키 및 전달받은 1회용 eUICC 공개 키를 이용하여 세션키를 생성할 수 있다(664). 상기 세션키 생성에는 추가적으로 CRT 정보 및 EID 정보가 이용될 수 있다.
그리고 SM-DP+(610)는 DP_Sign2를 생성할 수 있다(664). 상기 DP_Sign2는 SM-DP+의 기 저장되어 있던 개인 키를 이용한 서명값이며, CRT, 1회용 DP 공개 키, 1회용 eUICC공개 키를 포함하는 값에 대한 서명값 계산일 수 있다.
또한, SM-DP+(610)는 상기 생성한 세션키를 이용하여 암호화된 프로파일 패키지를 생성할 수 있다(664). 상기 암호화된 프로파일 패키지라 함은 다음의 두 가지 방식 중 한가지 방식으로 생성될 수 있다.
- 방식1: 암호화되지 않은 프로파일 패키지에 대하여 생성한 세션키로 SCP03t 암호화 방식을 이용해서 암호화한 것
- 방식2: 암호화되지 않은 프로파일 패키지에 대하여 랜덤하게 기 생성한 랜덤키로 암호화된 프로파일 패키지와, 상기 랜덤키를 상기 생성한 세션키로 암호화한 암호랜덤키를 합친 것
상기 암호화된 프로파일 패키지에는 추가로 eUICC에서의 세션키 생성에 이용될 수 있는 CRT, 1회용 프로파일제공서버 공개 키 및 상기 생성한 DP_Sign2가 포함될 수 있다.
SM-DP+(610)는 LPA(620)에 상기 암호화된 프로파일 패키지를 전달할 수 있다(666).
LPA(620)은 eUICC(630)에게 프로파일 패키지를 전달할 수 있다(668). 이때, LPA(620)은 프로파일 패키지 중 비암호화 데이터를 전달할 수 있다. 상기 LPA(620)은 상기 암호화된 프로파일 패키지 중 암호화 되지 않은 데이터와 복수 개의 암호화된 데이터를 구분하고, 먼저 상기 암호화 되지 않은 데이터를 eUICC(630)에 전송할 수 있는 크기로 분할하여 상기 eUICC(630)에 전달할 수 있다. 상기 전달방법은 "STORE DATA" APDU를 이용한 방법일 수 있다.
또한, 상기 암호화 되지 않은 데이터의 구분은 상기 암호화된 프로파일 패키지에 포함된 태그(Tag) 값을 구분하는 방식일 수 있다. 상기 Tag 값은 암호화된 프로파일 패키지 중 첫 1 바이트(Byte) 또는 2 바이트 데이터이며, 이후의 길이 바이트 (Length Bytes)를 확인하여 상기 암호화되지 않은 데이터의 끝의 경계를 구분지어 전달할 수 있다.
상기 암호화되지 않은 데이터에는 상기 CRT, 1회용 DP 공개 키, DP_Sign2값이 포함될 수 있다.
eUICC(630)는 서명을 검증하고, 복호화키를 생성할 수 있다(670). 상기 eUICC(630)는 DP_Sign2를 검증할 수 있다. 이는 기 확인했던 SM-DP+ 인증서의 공개 키를 이용한 서명검증방식 일수 있다. 상기 검증에 통과하면 eUICC(630)는 상기 전달받은 CRT, 1회용 SM-DP+ 공개 키값, EID값, eUICC에만 저장된 1회용 eUICC 개인 키 값을 이용하여, 암호화된 프로파일 패키지 복호화를 위한 세션키를 생성할 수 있다.
LPA(620)는 암호화 데이터를 전달할 수 있다(672). 상기 LPA(620)는 상기 668 동작 수행 시 구분했던, 암호화되지 않은 데이터의 경계 다음부터를 암호화된 데이터로 확인하고, 특정 Tag가 있는지 확인하여 암호화된 데이터를 의미하는 Tag를 발견한 경우 그 다음 Length Byte를 확인하여 암호화된 데이터의 크기를 확인하며, 상기 암호화된 데이터만큼을 EUICC(630)에 전달할 수 있다. 이때, 상기 암호화된 데이터는 "STORE DATA" APDU 커맨드를 이용하여 eUICC(630)에 분할 전송될 수 있다.
LPA(620)는 그 다음 암호화된 데이터에 대하여 상기 672 동작과 유사한 과정을 수행하여 전송할 수 있다(674). 이때 전송되는 데이터는 상기 664 동작에서 방법2로 암호화된 패키지가 생성된 경우의 암호랜덤키일 수 있으며, eUICC(630)는 상기 암호랜덤키를 전달받은 경우 이후의 암호화 데이터에 대하여는 상기 암호랜덤키를 상기 세션키로 복호화하여 랜덤키를 추출한 후 상기 랜덤키를 이후의 암호화 데이터를 복호화하는 세션키로 사용할 수 있다.
LPA(620)은 암호화 데이터를 구분하는 또 다른 Tag값과 Length Byte를 확인하여 복수 개의 암호화 데이터를 구분지을 수 있고, 각각의 암호화 데이터에 대하여 복수 개의 "STORE DATA" 커맨드를 이용하여 eUICC(630)에 전달할 수 있다(676).
그러면 eUICC(630)는 각각의 암호화된 데이터에 대하여 상기 세션키 또는 복호화한 랜덤키를 이용하여 복호화를 수행한 후 내부에 포함된 프로파일 설치가능단위 정보를 이용하여 프로파일을 설치가능단위로 설치한다. 상기 설치가능단위 정보를 설치하여 그 다음 암호화된 데이터의 복호화를 수행할 수 있음은 물론이다. 이와 같은 동작을 반복하여 모든 암호화된 데이터의 전송, 복호화 및 모든 설치가능단위 정보의 설치가 완료되면 EUICC(630)는 해당 결과를 LPA(620)에 전달할 수 있고, 상기 결과는 SM-DP+(610)에도 전달 될 수 있다(678).
본 개시의 실시예에서 LPA(620)과 eUICC(630)를 분리하여 설명하였으나, eUICC는 단말의 내부에 포함되거나, 삽입된 것이다. 따라서 본 개시의 실시예에서 LPA와 eUICC 사이의 동작은 eUICC를 포함하는 단말의 내부 동작으로 해석할 수도 있다.
상기와 같은 동작에 따라서 eUICC와 SM-DP+에 대한 인증, 검증, 프로파일패키지 다운로드, 프로파일 패키지 전달, 프로파일 설치 동작이 수행될 수 있다.
상기 도 6의 프로파일 설치 동작이 완료되면, LPA(620)는 eUICC(630)에 프로파일의 활성화(Enable) 명령을 전달하여 프로파일을 활성화할 수 있고, 활성화된 프로파일을 이용하여 이동통신시스템과 인증을 수행한 후 이동통신망을 이용할 수 있다.
도 7a, 7b, 7c은 복수 단말을 위한 벌크 프로파일을 한번에 프로비져닝 하는 방법이다.
도 7을 참고하면, 상기 벌크 프로파일 설치과정은 설명의 편의상 eUICC 전달 단계(delivery phase)(720), 단말 생산 준비 단계(device production preparation phase)(730), 및 단말 생산 단계(device production phase)(740)로 구분될 수 있다.
먼저 eUICC 전달 단계 (eUICC Deliver Phase)(720)에 대해 설명한다.
SM-SR+(또는 Production Server)(704)는 eUICC 제조사 (EUM)(700)로부터 ProductionInfoNotifyRequest 메시지를 수신하여, eUICC N개에 대한 제품정보를 받을 수 있다(722). 상기 MS-SR+(704)는 상기 EUM에게 ProductionInfoNotifyResponse(ACK) 메시지를 송신할 수 있다(724).
eUICC(714)는 특정한 SM-SR+에 대해서만 이하의 동작을 수행하도록 설정될 수 있는데, SM-SR+을 특정하는 방법은 아래와 같은 두가지 방법이 있을수 있다.
- 상기 SM-SR+의 구분자를 EUM이 eUICC 제조시 사전 설정
- 특정 Credential을 SM-SR+에 전달하여 상기 Credential을 이용한 요청인 경우에만 eUICC가 특정 동작 수행
상기 eUICC N 개에 대한 제품정보는, eUICC Info, eUICC 인증서 및 미리 생성한 1회용 공개 키, EUM 인증서를 포함할 수 있다. 상기 제품정보는 추가로 상기 Credential을 포함할 수도 있다. 미리 생성한 1회용 공개 키는 오직 특정 SM-SR+를 통해서만 eUICC에서 사용될 수 있다.
이어서, 단말 생산 준비 단계 (Device Production Preparation Phase)(730)에 대해 설명한다.
SM-SR+(704)는 SM-DP+(702)에 BulkProfileRequest를 전달하여 복수 개의 프로파일을 다운로드 하기 위한 준비를 요청할 수 있다(732). 이때 상기 BulkProfileRequest는 다음 정보가 포함될 수 있다.
- 프로파일 타입 구분자
- SM-SR 인증서 및 서명값
- N개의 eUICC의 인증서, N개의 eUICC용 1회용 공개 키, N개의 eUICC 정보
상기 N개의 정보들은 SM-DP+(702)에서 eUICC에 매핑할 수 있는 형태로 전달될 수 있다.
상기 서명값은 1회용 공개 키를 포함하는 값에 대한 서명값일 수 있다.
SM-DP+(702)는 SM-SR+의 인증서 및 서명 값(SRToken0)을 검증할 수 있다(734).
상기 검증에 통과하면, SM-DP+(702) 는 1회용(ephemeral) 비대칭키 쌍(즉, 공개 키와 개인 키)을 생성하고, 상기 1회용 비대칭키 쌍을 상기 732 동작에서 전달받은 1회용 eUICC용 공개 키와 함께 사용하여 암호화 키를 생성할 수 있다(734). 상기 암호화 키는 프로파일을 암호화 하거나, 프로파일을 암호화한 대칭키를 암호화 하는데 사용될 수 있다.
SM-DP+(702)는 암호화한 프로파일, 상기 SM-DP+가 생성한 1회용 공개 키, SM-DP+의 서명값을 포함하는 Data 즉, ProfileInstallPackage를 N개 생성할 수 있다(734)
SM-DP+(702)는 SM-SR+(704)에게 BulkProfileResponse 메시지를 전달하여 상기 생성한 ProfileInstallPackage를 전달할 수 있다(736).
SM-SR+(704)는 SM-DP+로부터 받은 자료의 일부 혹은 전부를 포함한 값에 대하여, SM-SR+(704)의 서명값(SRToken1)을 계산할 수 있다(738). 상기 서명값은 SM-SR+(704)가 미리 가지고 있던 값일 수도 있고, 상기 722 단계에서 EUM으로부터 받은 "특정 Credential"을 이용한 서명값일 수도 있다.
이어서, 단말 생산 단계 (Device Production Phase)(740)에 대해 설명한다.
개별 단말(710)은 설명의 편의상 LPA(712)와 eUICC(714)로 구성된다고 설명된다. 상기 LPA(712)는 특정한 조건이 되면, SM-SR+(704)에게 FactoryEventRequest(EID) 메시지를 전송하여 프로파일 설치를 요청할 수 있다(742). 상기 특정한 조건은 단말의 생산 단계(예를 들어 단말의 제조 공장에서)에서 적용되는 것으로써, 예로써 다음과 같을 수 있다.
- 무선 통신, 유선 연결을 통해 명령 수신하면 수행
- 수동 조작을 통해 명령 수신하면 수행
- 특정 시간이 되면 수행
- 특정 위치를 통과하면 수행
이때 상기 FactoryEventRequest(742)를 보내기 전에 LPA(712)는 eUICC(714)로부터 eUICC Challenge 값을 수신할 수도 있다. 상기 FactoryEventRequest(742)는 EID, eUICC Challenge 중 하나 이상을 포함할 수 있다.
만약 상기 FactoryEventRequest(742)가 eUICC Challenge를 포함하는 경우, 상기 728 단계의 SM-SR+의 서명값 SRToken1은 eUICC Challenge를 포함하여 계산될 수도 있다.
SM-SR+(704)는 SM-DP+(702)의 서명 값, SM-SR+(704)의 서명값을 포함한 응답을 LPA에 전달할 수 있다(744).
LPA(712)는 eUICC(714)에게 SM-DP+(702) 서명 값, SM-SR+(704) 서명 값을 포함하는 Profile설치준비 메시지 GetAuthDataRequest를 전달할 수 있다(746).
eUICC(714)는 SM-SR+(704) 서명을 검증하고, 검증에 통과하면 SM-DP+(702) 서명을 검증한다(748). 만약 하나라도 검증에 실패하면, 에러를 리턴하고 이후 과정을 실행하지 않고 종료한다. 선택적으로, eUICC(714)는 SM-SR+(704)가 특정한 서버인지 확인할 수 있다. 상기 확인하는 방법은 SM-SR+(704)의 ID를 확인하는 방법 또는 서명값을 검증하는 방법일 수 있다. SM-SR+(704)이 권한있는 서버(즉, 특정한 서버)가 아니면 eUICC(714)는 1회용 비대칭키 쌍을 새로 생성하지만, SM-SR+(704)이 권한있는 서버(즉, 특정한 서버)인 경우 eUICC(714)는 1회용 비대칭키 쌍을 새로 생성하지 않고, 미리 생성한 1회용 비대칭키 쌍을 사용할 수 있다.
eUICC(714)는 1회용 공개 키 및 LPA로부터 전달받은 파라미터를 포함하는 데이터에 대하여 eUICC에 설정된 서명용 개인 키를 이용하여 eUICC 서명값 eUICCToken 을 생성할 수 있다(748).
이후 eUICC(714)는 LPA(712)에게 GetAuthDataResponse 메시지를 전달하여 상기 eUICC 서명값과 1회용 공개 키를 포함하는 데이터를 전달할 수 있다(750).
LPA(714)는 SM-SR+(704)에게 상기 전달받은 eUICC 서명값 및 1회용 공개 키를 포함하는 eUICCManagementRequest 메시지를 전달하여 프로파일 다운로드 요청할 수 있다(752).
SM-SR+(704)는 eUICC 서명값을 검증한다(754). 만약 검증에 실패하면, SM-SR+(704)는 에러를 리턴하고 이후 해당 단말의 프로파일 설치과정을 중단할 수 있다. 또한, 상기 SM-SR+(704)는 상기 736 단계에서 전달받은 암호화된 프로파일의 일부 또는 전체에 대해서 SM-SR+(704)의 서명용 개인 키를 이용하여 서명을 할 수 있다(754). 상기 암호화된 프로파일에는 SM-DP+(702)의 또다른 서명값이 포함될 수도 있다.
SM-SR+(704)는 LPA(712)에게 상기 752 단계의 응답으로 eUICCManagementResponse 메시지를 전달하여 암호화된 프로파일, SM-SR+(704)의 서명 값을 전달할 수 있다(756).
LPA(712)는 eUICC(714)에게 EstablishSecureChannelRequest 메시지를 전달하여 SM-SR+(704) 서명값 SRToken2, SM-DP+(702)의 1회용 공개 키, SM-DP+(702)의 1회용 공개 키를 포함한 데이터에 대하여 SM-DP+의 서명용 개인 키로 서명한 서명값 DPToken2을 전달할 수 있다(758).
eUICC(714)는 SM-SR+(704)의 서명값을 검증할 수 있다(760). 만약 검증에 실패하면, eUICC(714)는 LPA(712)에게 에러를 리턴하고, 이후의 프로파일 설치과정을 종료할 수 있다.
SM-SR+(704)의 서명값 검증에 성공하면, 상기 eUICC(714)는 SM-DP+(702) 서명값을 검증할 수 있다(760). 만약 검증에 실패하면, 상기 eUICC(714)는 에러를 리턴하고, 이후의 프로파일 설치과정을 종료할 수 있다.
SM-DP+(702) 서명값 검증에 성공하면, 상기 eUICC(714)는 LPA(712)로부터 전달받은 SM-DP+(702)의 1회용 공개 키와 eUICC(714)의 1회용 개인 키를 이용하여 암호화 키를 생성할 수 있다(760).
eUICC(714)는 상기 758 단계에서 수신한 메시지에 대한 응답으로 EstablishSecureChannelResponse 메시지를 LPA(712)에 전달할 수 있다(762).
LPA(712)는 eUICC(714)에게 InstallProfileRecordRequest 메시지를 전달하여 암호화된 ProfileRecord 정보(즉, 메타데이터)를 전달할 수 있다(764).
eUICC(714)는 암호화된 ProfileRecord 를 상기 760단계에서 생성한 암호화 키로 복호화 한후, 설치할 수 있다. 그리고 상기 eUICC(714)는 LPA(712)에게 상기 764 단계에서 수신한 메시지에 대한 응답으로 InstallProfileRecordResponse 메시지를 전달할 수 있다(766).
선택적으로, LPA(712)는 암호화된 프로파일 보호 키 (Profile Protection Key; PPK) 를 eUICC(714)에게 전달할 수 있다(768). 그러면 상기 eUICC(714)는 암호화된 PPK를 상기 760 단계에서 생성한 암호화 키로 복호화후, LPA(712)에게 응답 메시지를 전달할 수 있다(770).
이후 LPA(712)는 암호화된 PPB(Profile Package Block)을 eUICC(714)에 전달할 수 있다(772).
eUICC(714)는 암호화된 PPB을 상기 760단계의 암호화 키 또는 상기 770단계의 PPK를 이용하여 복호화 할 수 있다(773). 만약 복호화에 실패하면 상기 eUICC(714) 에러코드를 리턴하고 이후의 프로파일 설치과정을 종료할 수 있다. 복호화가 성공되면, 상기 eUICC(714)는 복호화된 PPB 단독으로 혹은 이전에 전달받은 PPB의 일부 또는 전체와 결합하여 설치가능단위인 Profile Element가 하나 이상 구성되는지 확인하여 설치 가능한 Profile Element 들을 설치하고, Profile Element 구성에 사용되지 않은 일부 또는 전체가 존재하면 그 뒤에 다른 PPB의 일부 또는 전체들과 합쳐져 Profile Element로 구성될 수 있도록 버퍼에 저장할 수 있다.
eUICC(714)는 LPA(712)에 상기 772 단계의 메시지에 대한 응답을 전달할 수 있다(774).
만약 암호화된 PPB가 M개 있다면, 상기 772, 773, 774 동작은 M번 반복될 수 있다.
마지막 PPB까지 잘 설치되면, eUICC(714)는 eUICC 서명이 포함된 프로파일이 설치 완료 메시지를 LPA(712)에 전달할 수 있다.
LPA(712)는 프로파일 설치가 완료된후 eUICC 서명을 포함한 설치완료알림 메시지 NotifyResultRequest 를 SM-SR+(704)에 전달할 수 있고(776), 상기NotifyResultRequest 메시지에 대한 응답을 수신할 수 있다(778).
LPA(712)는 추가적으로 eUICC(714)에서 설치한 프로파일을 인에이블할 수도 있다(780).
상기 742 내지 780 동작들은 개별 단말에 대하여 동작하는 것이므로, N개의 단말에 대하여 상기 동작이 반복 수행될 수 있다.
마지막으로, SM-SR+(704)는 SM-DP+(702)에게 벌프 프로파일 프로비져닝 결과를 통보하고(792), 응답을 수신할 수 있다. 설명의 편의상 상기 792, 794 동작은 벌크 프로비져닝 결과 통보 단계(790)로 지칭될 수 있다.
이하에서는 단말의 eUICC 에게 프로파일을 제공하는 시스템 내의 엔티티 간 인터페이스, 기능(function) 및 상기 기능을 위한 메시지를 정의한다.
표 2는 시스템 내의 단말(LPA)-서버간 또는 서버-서버간 인터페이스의 기능 및 프로토콜을 예시한다.
Figure PCTKR2016003858-appb-T000002
표 3은 시스템 내의 단말(LPA)-eUICC간 인터페이스의 기능 및 프로토콜을 예시한다.
Figure PCTKR2016003858-appb-T000003
먼저, 상기 표 2에서 예시된 기능(메시지)들에 대하여 자세히 설명한다.
상기 표 2에서 예시된 단말-서버간 및 서버-서버간 인터페이스 기능들은 HTTPS(hyper text transfer protocol over secure socket layer) 프로토콜을 통해 JSON(JavaScript Object Notation) 형식의 데이터 오브젝트를 이용하여 통신될 수 있다.
HTPP 헤더에는 HTTP 요청(Request)을 위한 헤더와 HTTP 응답(Response)를 위한 헤더가 있다.
HTTP 요청 헤더는 다음 표 4의 포맷을 가질 수 있다.
Figure PCTKR2016003858-appb-T000004
HTTP 요청의 방법(method)는 HTTP 포스트(POST) 방법일 수 있다. 상기 표 4을 참고하면, 상기 HTTP 요청의 리소스 "<uri>"(: uniform resource identifier)는 "<query path>"(: 쿼리 경로)로써 설정될 수 있고, 예를 들어 "/v1/es9/euicc-mgmt"와 같은 값을 가질 수 있다.
상기 HTTP 요청 헤더는 예를 들어, "Content-type", "Content-length", "Host", 및 "X-Admin-Protocol"의 필드(field)를 포함할 수 있고, 각각의 용도는 다음 표 5와 같이 정의될 수 있다.
Figure PCTKR2016003858-appb-T000005
상기 표 5에서 MOC(Mandatory / Optional / Conditional)의 값은 M(필수적), O(선택적), 또는 C(조건적)일 수 있다.
HTTP 응답 헤더는 다음 표 6의 포맷을 가질 수 있다.
Figure PCTKR2016003858-appb-T000006
이제, 상기 표 2에 예시된 기능들의 상세 메시지들을 설명한다.
ES1 인터페이스(: EUM과 SM-SR+간 인터페이스)의 기능인 "ES1_ProductInfoNotifyRequest"는, 벌크(bulk) 프로파일 프로비져닝을 위해, EUM이 미리 생성된 ePK(ephemeral public key; 1회용 공개 키) 리스트를 SM-SR+에게 전달하는 메시지이다. 벌크 프로파일 프로비져닝이란 예를 들어, 공장 생산 시나리오와 같이 다수의 프로파일 프로비져닝일 수 있다. 상기 ES1_ProductInfoNotifyRequest 메시지의 <query path>는 예를 들어, "/v1/es1/product-info-notify"일 수 있다.
상기 ES1_ProductInfoNotifyRequest 메시지의 요청(request) 메시지에 해당하는 JSON 바디(body) 스키마(schema)는 예를 들어 다음 표 7과 같다.
Figure PCTKR2016003858-appb-T000007
상기 ES1_ProductInfoNotifyRequest 메시지의 응답(response) 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 8과 같다.
Figure PCTKR2016003858-appb-T000008
ES2 인터페이스(: MNO와 SM-DP+간 인터페이스)의 기능인 "ES2_DownloadProfileRequest"는 MNO가 SM-DP+에게 프로파일의 다운로드를 요청하는 메시지이다. 상기 ES2_DownloadProfileRequest 메시지의 <query path>는 예를 들어, "/v1/es2/download-profile"일 수 있다.
상기 ES2_DownloadProfileRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 9과 같다.
Figure PCTKR2016003858-appb-T000009
Figure PCTKR2016003858-appb-I000001
Figure PCTKR2016003858-appb-I000002
Figure PCTKR2016003858-appb-I000003
Figure PCTKR2016003858-appb-I000004
상기 ES2_DownloadProfileRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 10과 같다.
Figure PCTKR2016003858-appb-T000010
ES2 인터페이스(: MNO와 SM-DP+간 인터페이스)의 기능인 "ES2_ActivationVoucherRequest"는 MNO가 SM-DP+에게 바우처(voucher)의 활성화를 요청하는 메시지이다. 상기 ES2_ActivationVoucherRequest 메시지의 <query path>는 예를 들어, "/v1/es2/activation-voucher"일 수 있다.
상기 ES2_ActivationVoucherRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 11과 같다.
Figure PCTKR2016003858-appb-T000011
상기 ES2_ActivationVoucherRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 12과 같다.
Figure PCTKR2016003858-appb-T000012
ES2 인터페이스의 기능인 "ES2_NotifyResultRequest"는 SM-DP+가 MNO에게 이벤트의 결과 통보(notify)를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es2/notify-result"일 수 있다.
상기 ES2_NotifyResultRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 13과 같다.
Figure PCTKR2016003858-appb-T000013
상기 ES2_NotifyResultRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 14과 같다.
Figure PCTKR2016003858-appb-T000014
ES3 인터페이스(: SM-DP+와 SM-SR+간 인터페이스)의 기능인 "ES3_eUICCManagementRequest"는 eUICC로의 원격 프로파일 다운로드를 SM-DP+가 SM-SR+에게 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/euicc-mgmt"일 수 있다.
상기 ES3_eUICCManagementRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 15과 같다.
Figure PCTKR2016003858-appb-T000015
상기 ES3_eUICCManagementRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 16과 같다.
Figure PCTKR2016003858-appb-T000016
ES3 인터페이스의 기능인 "ES3_DownloadProfileRequest"는 SM-SR+가 SM-DP+에게 프로파일의 다운로드를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/download-profile"일 수 있다.
상기 ES3_DownloadProfileRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 17과 같다.
Figure PCTKR2016003858-appb-T000017
상기 ES3_DownloadProfileRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 18과 같다.
Figure PCTKR2016003858-appb-T000018
ES3 인터페이스의 기능인 "ES3_ProfileRequest"는 SM-SR+가 SM-DP+에게 프로파일의 생성을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/profile"일 수 있다.
상기 ES3_ProfileRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 19과 같다.
Figure PCTKR2016003858-appb-T000019
상기 ES3_ProfileRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 20과 같다.
Figure PCTKR2016003858-appb-T000020
ES3 인터페이스의 기능인 "ES3_NotifyResultRequest"는 SM-SR+가 SM-DP+에게 이벤트 결과의 통보(notify)를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/notify-result"일 수 있다.
상기 ES3_NotifyResultRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 21과 같다.
Figure PCTKR2016003858-appb-T000021
상기 ES3_NotifyResultRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 22와 같다.
Figure PCTKR2016003858-appb-T000022
ES3 인터페이스의 기능인 "ES3_BulkProfileRequest"는 SM-SR+가 SM-DP+에게 하나 또는 그 이상의 프로파일을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/bulk-profile"일 수 있다.
상기 ES3_BulkProfileRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 23과 같다.
Figure PCTKR2016003858-appb-T000023
상기 ES3_BulkProfileRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 24와 같다.
Figure PCTKR2016003858-appb-T000024
ES3 인터페이스의 기능인 "ES3_NotifyResultBulkRequest"는 SM-SR+가 SM-DP+에게 벌크 프로파일 프로비져닝 이벤트의 결과 통보를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/notify-result-bulk"일 수 있다.
상기 ES3_NotifyResultBulkRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 25와 같다.
Figure PCTKR2016003858-appb-T000025
상기 ES3_NotifyResultBulkRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 26과 같다.
Figure PCTKR2016003858-appb-T000026
ES4 인터페이스(: MNO와 SM-SR+간 인터페이스)의 기능인 "ES4_eUICCManagementRequest"는 MNO가 SM-SR+에게 eUICC의 원격 플랫폼/프로파일 관리를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es4/euicc-mgmt"일 수 있다.
상기 ES4_eUICCManagementRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 27과 같다.
Figure PCTKR2016003858-appb-T000027
Figure PCTKR2016003858-appb-I000005
Figure PCTKR2016003858-appb-I000006
Figure PCTKR2016003858-appb-I000007
Figure PCTKR2016003858-appb-I000008
Figure PCTKR2016003858-appb-I000009
Figure PCTKR2016003858-appb-I000010
상기 ES4_eUICCManagementRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 28과 같다.
Figure PCTKR2016003858-appb-T000028
ES4 인터페이스의 기능인 "ES4_TerminalRequest"는 SM-SR+가 MNO에게 디바이스 스왑(swap) 또는 로컬 삭제(local delete)에 대한 인증(authorization) 결과 반환을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es4/terminal"일 수 있다.
상기 ES4_TerminalRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 29와 같다.
Figure PCTKR2016003858-appb-T000029
상기 ES4_TerminalRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 30과 같다.
Figure PCTKR2016003858-appb-T000030
ES4 인터페이스의 기능인 "ES4_NotifyResultRequest"는 SM-SR+가 MNO에게 이벤트 결과의 통보를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es4/notify-result"일 수 있다.
상기 ES4_NotifyResultRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 31과 같다.
Figure PCTKR2016003858-appb-T000031
상기 ES4_NotifyResultRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 32와 같다.
Figure PCTKR2016003858-appb-T000032
ES9 인터페이스(: LPA와 SM-SR+간 인터페이스)의 기능인 "ES9_EventRequest"는 LPA가 SM-SR+에게 특정 이벤트 ID에 해당하는 이벤트를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/event"일 수 있다.
상기 ES9_EventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 33과 같다.
Figure PCTKR2016003858-appb-T000033
상기 ES9_EventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 34과 같다.
Figure PCTKR2016003858-appb-T000034
ES9 인터페이스의 기능인 "ES9_eUICCManagementRequest"는 LPA가 SM-SR+에게 eUICC의 원격 플랫폼/프로파일 관리를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/euicc-mgmt"일 수 있다.
상기 ES9_eUICCManagementRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 35와 같다.
Figure PCTKR2016003858-appb-T000035
상기 ES9_eUICCManagementRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 36과 같다.
Figure PCTKR2016003858-appb-T000036
ES9 인터페이스의 기능인 "ES9_TerminalRequest"는 LPA가 SM-SR+에게 프로파일 다운로드, 디바이스 스왑 또는 프로파일의 로컬 삭제를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/terminal"일 수 있다.
상기 ES9_TerminalRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 37과 같다.
Figure PCTKR2016003858-appb-T000037
Figure PCTKR2016003858-appb-I000011
상기 ES9_TerminalRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 38과 같다.
Figure PCTKR2016003858-appb-T000038
ES9 인터페이스의 기능인 "ES9_TerminalAuthRequest"는 LPA가 SM-SR+에게 로컬 프로파일 관리의 권한인증(Authorization)을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/terminal-auth"일 수 있다.
상기 ES9_TerminalAuthRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 39와 같다.
Figure PCTKR2016003858-appb-T000039
상기 ES9_TerminalAuthRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 40과 같다.
Figure PCTKR2016003858-appb-T000040
ES9 인터페이스의 기능인 "ES9_NotifyResultRequest"는 LPA가 SM-SR+에게 이벤트 결과의 통보를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/notify-result"일 수 있다.
상기 ES9_NotifyResultRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 41와 같다.
Figure PCTKR2016003858-appb-T000041
Figure PCTKR2016003858-appb-I000012
Figure PCTKR2016003858-appb-I000013
Figure PCTKR2016003858-appb-I000014
Figure PCTKR2016003858-appb-I000015
Figure PCTKR2016003858-appb-I000016
상기 ES9_NotifyResultRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 42과 같다.
Figure PCTKR2016003858-appb-T000042
ES9 인터페이스의 기능인 "ES9_FactoryEventRequest"는 LPA가 SM-SR+에게 벌크 프로파일 프로비져닝에서 특정 eUICC를 위한 프로파일 다운로드 이벤트를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/factory-event"일 수 있다.
상기 ES9_FactoryEventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 43과 같다.
Figure PCTKR2016003858-appb-T000043
상기 ES9_FactoryEventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 44와 같다.
Figure PCTKR2016003858-appb-T000044
ES9+ 인터페이스(: LPA 와 SM-DP+ 사이의 인터페이스)의 기능인 "ES9+.InitiateAuthentication"는 LPA가 SM-DP+에게 인증 초기화를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/init-auth"일 수 있다.
상기 ES9+.InitiateAuthentication 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 45와 같다.
Figure PCTKR2016003858-appb-T000045
상기 ES9+.InitiateAuthentication 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 46과 같다.
Figure PCTKR2016003858-appb-T000046
LPA에서 SM-DP+로 전송되는 ES9+.InitiateAuthentication HTTP 요청 메시지의 일 예가 표 47에서 보여진다.
Figure PCTKR2016003858-appb-T000047
SM-DP+에서 LPA로 전송되는 ES9+.InitiateAuthentication HTTP 응답 메시지의 일 예가 표 48에서 보여진다.
Figure PCTKR2016003858-appb-T000048
ES9+ 인터페이스의 기능인 "ES9.GetBoundProfilePackage"는 LPA가 SM-DP+에게 결합된 프로파일 패키지(BPP)를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/get-bound"일 수 있다.
상기 ES9.GetBoundProfilePackage 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 49와 같다.
Figure PCTKR2016003858-appb-T000049
상기 ES9.GetBoundProfilePackage 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 50과 같다.
Figure PCTKR2016003858-appb-T000050
ES11 인터페이스(: LPA와 SM-DS 간 인터페이스)의 기능인 "ES11_PSRequest" 또는 "ES11_PSListRequest"는 LPA가 SM-DS에게 푸쉬(push) 서비스 또는 푸쉬 서비스의 리스트를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/push-service"일 수 있다.
상기 ES11_PSRequest 또는 ES11_PSListRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 51과 같다.
Figure PCTKR2016003858-appb-T000051
상기 ES11_PSRequest 또는 ES11_PSListRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 52와 같다.
Figure PCTKR2016003858-appb-T000052
ES11 인터페이스의 기능인 "ES11_PSRegistrationRequest"는 LPA가 SM-DS에게 상기 LPA를 푸쉬 통보(push notification)을 위해 등록 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/push-service/registration"일 수 있다.
상기 ES11_PSRegistrationRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 53과 같다.
Figure PCTKR2016003858-appb-T000053
상기 ES11_PSRegistrationRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 54과 같다.
Figure PCTKR2016003858-appb-T000054
ES11 인터페이스의 기능인 "ES11_PSConfirmRequest"는 LPA가 SM-DS에게 푸쉬 서비스의 등록 결과 반환을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/push-service/confirm"일 수 있다.
상기 ES11_PSConfirmRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 55와 같다.
Figure PCTKR2016003858-appb-T000055
상기 ES11_PSConfirmRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 56과 같다.
Figure PCTKR2016003858-appb-T000056
ES11 인터페이스의 기능인 "ES11_EventIDRequest"는 LPA가 SM-DS에게 특정 EID에 관련된 하나 이상의 펜딩(pending) 이벤트 ID를 반환 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/event-id"일 수 있다.
상기 ES11_EventIDRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 57과 같다.
Figure PCTKR2016003858-appb-T000057
상기 ES11_EventIDRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 58과 같다.
Figure PCTKR2016003858-appb-T000058
ES11 인터페이스의 기능인 "ES11_DeleteEventRequest"는 LPA가 SM-DS에게 특정 이벤트의 삭제를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/delete-event"일 수 있다.
상기 ES11_DeleteEventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 59와 같다.
Figure PCTKR2016003858-appb-T000059
상기 ES11_DeleteEventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 60과 같다.
Figure PCTKR2016003858-appb-T000060
ES12 인터페이스(: SM-SR+와 SM-DS 사이의 인터페이스)의 기능인 "ES12_RegisterEventRequest"는 SM-SR+가 SM-DS에게 이벤트의 삽입을 요청하는 메시지이다. 푸쉬 토큰(push token)이 EID를 위해 등록되면, SM-DS는 해당 푸쉬 서버로 푸쉬 토큰을 송신한다. 상기 메시지의 <query path>는 예를 들어, "/v1/es12/register-event"일 수 있다.
상기 ES12_RegisterEventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 61과 같다.
Figure PCTKR2016003858-appb-T000061
상기 ES12_RegisterEventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 62와 같다.
Figure PCTKR2016003858-appb-T000062
ES12 인터페이스의 기능인 "ES12_DeleteEventRequest"는 SM-SR+가 SM-DS에게 특정 이벤트의 삭제를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es12/delete-event"일 수 있다.
상기 ES12_DeleteEventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 63과 같다.
Figure PCTKR2016003858-appb-T000063
상기 ES12_DeleteEventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 64와 같다.
Figure PCTKR2016003858-appb-T000064
ES13 인터페이스(: LPA와 MNO 사이의 인터페이스)의 기능인 "ES13_URLRequest"는 LPA가 MNO에게 가입 요청(subscription request) 또는 활성 바우처(activation voucher) 검증(validation)을 처리하기 위한 URL 반환을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es13/url"일 수 있다.
상기 ES13_URLRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 65와 같다.
Figure PCTKR2016003858-appb-T000065
상기 ES13_URLRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 66과 같다.
Figure PCTKR2016003858-appb-T000066
이어서, 상기 표 3에서 예시된 기능(메시지)들에 대하여 자세히 설명한다.
상기 표 3에서 예시된 단말-eUICC 간 인터페이스(즉, ES10)의 기능들은 APDU(application protocol data unit) 프로토콜을 통해 TLV(tag length value) 형식의 데이터 오브젝트를 이용하여 통신될 수 있다.
단말-eUICC 간 ES10 인터페이스는 다음의 요구사항(requirement)를 만족시킬 수 있다. 상기 요구사항은, APDU를 송신하기 전에, 단말(즉, LPA)은 "MANAGE CHANNEL" 명령어(command)를 이용하여 논리 채널을 오픈하고, "SELECT" 명령을 이용하여 TAF 어플리케이션을 선택하고, TAF 를 위한 AID는 예를 들어, "A0 00 00 05 59 10 10 FF FF FF FF 89 00 00 03 00"와 같은 값을 갖는 것이다.
단말-eUICC 간 ES10 인터페이스를 위한 기능에는 RMF(Remote Management Function)와 LMF(Local Management Function)가 있다.
먼저, 상기 RMF에 대해 설명한다.
LPA는 "STORE DATA" 명령어를 전송함으로써 eUICC의 RMF를 호출(call)할 수 있다. 상기 "STORE DATA" 명령어의 데이터 필드는 표 67에 따라서 코딩될 수 있다.
Figure PCTKR2016003858-appb-T000067
상기 "STORE DATA" 명령어의 데이터 크기가 255 바이트보다 클 경우, 상기 데이터는 쪼개질(split) 수 있고, 다수의 "STORE DATA" 명령어를 통해 송신될 수 있다.
상기 "STORE DATA" 명령어의 응답 데이터는 다음 표 68에 따라서 코딩될 수 있다.
Figure PCTKR2016003858-appb-T000068
상기 응답 데이터 크기가 255 바이트보다 클 경우, 명령어의 연쇄(chaining)가 수행될 수 있다. 즉, 상기 응답 데이터는 다수의 "GetResponse" 명령어를 이용함으로써 LPA에 의해 조회(retrieve)될 수 있다. 상기 데이터 필드의 Tag의 값은 ASN.1(Abstract Syntax Notation One)의 AUTOMATIC TAG 옵션을 통해 자동적으로 할당될 수 있다.
RMF는 원격 관리 요청(Remote Management Request) TLV와 원격 관리 응답(Remote Management Response) TLV를 포함할 수 있다. 원격 관리 요청 TLV는, "STORE DATA" 명령어를 이용함으로써 LPA로부터 eUIICC로 전달될 수 있다. eUICC는 상기 전달된 원격 관리 요청 TLV에 대한 응답으로써, "STORE DATA APDU" 응답 또는 "GET RESPONSE APDU" 응답을 이용하여 원격 관리 응답 TLV를 전송할 수 있다.
상기 RMF의 예를 설명한다.
LPA는 eUICC에게 SM-SR+, SM-DP+ 또는 SM-SR+의 인증을 준비하도록 트리거(trigger)하기 위해 "GetAuthData" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 GetAuthData 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 69와 같다.
Figure PCTKR2016003858-appb-T000069
상기 GetAuthData 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 70과 같다.
Figure PCTKR2016003858-appb-T000070
LPA는 eUICC에게, 세션 키 승인(session key agreement)를 위한 파라메터를 전달하기 위해 "EstablishSecureChannel" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 EstablishSecureChannel 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 71과 같다.
Figure PCTKR2016003858-appb-T000071
상기 EstablishSecureChannel 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 72과 같다.
Figure PCTKR2016003858-appb-T000072
LPA는 eUICC에게, 수립된 보안 채널 SCP03t에 의해 보호되는 ProfileRecordPart2를 전달하기 위해 "InstallProfileRecord" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 InstallProfileRecord 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 73와 같다.
Figure PCTKR2016003858-appb-T000073
eUICC 가 상기 InstallProfileRecord 요청 메시지를 수신하고, 유효한 SCP03t 채널이 수립되어 있으면, 상기 eUICC는 상기 요청 TLV 내의 "SCP03tCommandTLV"를 지시되는 보안 채널의 세션 키 SCP03으로 처리한다. 반면, 유효한 채널 SCP03t가 없다면, 상기 eUICC는 실패를 지시하는 응답 TLV를 반환할 것이다.
상기 InstallProfileRecord 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 74과 같다.
Figure PCTKR2016003858-appb-T000074
LPA는 eUICC에게, 미리 생성되고 프로파일 패키지를 보호하는데 사용되는 profileProtectionKey로써 수립된 세션 키를 대체하기 위해 상기 profileProtectionKey를 전달하는 "UpdateSessionKey" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 UpdateSessionKey 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 75와 같다.
Figure PCTKR2016003858-appb-T000075
상기 UpdateSessionKey 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 76와 같다.
Figure PCTKR2016003858-appb-T000076
LPA는 eUICC에게, SM-SR+ 또는 SM-DP+ 로부터 수신한 데이터 SecuredProfilePackageBlock 를 전달하는 "InstallProfilePackageBlock" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 InstallProfilePackageBlock 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 77과 같다.
Figure PCTKR2016003858-appb-T000077
상기 InstallProfilePackageBlock 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 78과 같다.
Figure PCTKR2016003858-appb-T000078
여기서, sign_result는 자신(상기 sign_result)을 제외한 EventResult 내의 모든 값 데이터에 대해서 SK_eUICC_ECDSA을 이용하여 계산될 수 있다. 예를 들어, eventType = getProfileRegistry 인 경우 상기 sign_result는 resultCode|eID|eventID|profileRegistry에 대해 서명(sign)된 결과이다.
LPA는 eUICC에게, 보안 채널 및 관련된 세션 키를 해제하도록 "ReleaseSecureChannel" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 ReleaseSecureChannel 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 79과 같다.
Figure PCTKR2016003858-appb-T000079
eUICC가 상기 ReleaseSecureChannel 요청 메시지를 수신하면, 상기 eUICC 는 저장하고 있는 SCP03t 보안 채널 세션 키 셋트를 제거할 수 있다.
상기 ReleaseSecureChannel 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 80와 같다.
Figure PCTKR2016003858-appb-T000080
LPA는 eUICC에게, SM-SR+로부터 전달된 ES9_eUICCManagementResponse 메시지 내에 포함된 srToken2와 이벤트를 전달하기 위해 "eUICCManagement" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 eUICCManagement 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 81과 같다.
Figure PCTKR2016003858-appb-T000081
상기 eUICCManagement 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 82과 같다.
Figure PCTKR2016003858-appb-T000082
여기서, 이벤트 및 eventResult의 세부 구조는 더 정의될 수 있다.
LPA는 eUICC에게, 디바이스 스왑 인증 또는 로컬 삭제 인증을 위한 SM-SR+ 의 인증을 준비하도록 eUICC 를 트리거하기 위해 "TerminalAuth" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 TerminalAuth 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 83와 같다.
Figure PCTKR2016003858-appb-T000083
상기 TerminalAuth 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 84과 같다.
Figure PCTKR2016003858-appb-T000084
이어서, 상기 LMF에 대해 설명한다.
LPA는 "STORE DATA" 명령어를 전송함으로써 eUICC의 LMF를 호출할 수 있다. 상기 "STORE DATA" 명령어의 데이터 필드는 표 85에 따라서 코딩될 수 있다.
Figure PCTKR2016003858-appb-T000085
상기 "STORE DATA" 명령어의 데이터 크기가 255 바이트보다 클 경우, 상기 데이터는 쪼개질(split) 수 있고, 다수의 "STORE DATA" 명령어를 통해 송신될 수 있다.
상기 "STORE DATA" 명령어의 응답 데이터는 다음 표 86에 따라서 코딩될 수있다.
Figure PCTKR2016003858-appb-T000086
상기 응답 데이터 크기가 255 바이트보다 클 경우, 명령어의 연쇄가 수행될 수 있다. 즉, 상기 응답 데이터는 다수의 "GetResponse" 명령어를 이용함으로써 LPA에 의해 조회될 수 있다. 상기 데이터 필드의 Tag의 값은 ASN.1의 AUTOMATIC TAG 옵션을 통해 자동적으로 할당될 수 있다.
LMF는 로컬 관리 요청(Local Management Request) TLV와 로컬 관리 응답(Local Management Response) TLV를 포함할 수 있다. 로컬 관리 요청 TLV는, "LOCAL STORE DATA" 명령어를 이용함으로써 LPA로부터 eUIICC로 전달될 수 있다. eUICC는 상기 전달된 로컬 관리 요청 TLV에 대한 응답으로써, "STORE DATA APDU" 응답 또는 "GET RESPONSE APDU" 응답을 이용하여 로컬 관리 응답 TLV를 전송할 수 있다.
상기 LMF의 예를 설명한다.
LPA는 eUICC에게, 로컬 관리 이벤트에 대한 자세한 정보를 포함하는 localEvent를 전달하기 위해 "LocalManagement" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 LocalManagement 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 87과 같다.
Figure PCTKR2016003858-appb-T000087
상기 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 88과 같다.
Figure PCTKR2016003858-appb-T000088
만일, localEventType이 getProfileRegistry 이면, eUICC는 ES10_eUICCManagementResponse를 통해서 LPA에게 ProfileRegistry를 전달할 수 있다.
특정 프로파일이 event.profileID 에 의해 지시되는 경우, eventResult 내의 ProfileRegistry는 상기 프로파일의 ProfileRecord를 포함할 수 있다. 상기 event.profileID이 NULL인 경우, ProfileRegistry는 모든 프로파일의 ProfileRecords를 포함할 수 있고, 상기 프로파일의 authorizedSR 은 요청하는 SM-SR+의 SRID를 포함할 수 있다.
localEventResult, defaultSR, 그리고 ownerMNO TLV는, localEventType이 {enableProfile, disableProfile, 또는 deleteProfile} 중의 하나의 값을 가지고 PPRLocalMgmtNotification.notiEventList가 상응하는 EventToBeNotified 를 포함할 때에 LocalManagementResponse 내에 존재한다.
여기서, sign_Result는 자신(상기 sign_Result)을 제외한 LocalEventResult 내의 모든 값 데이터에 대해서 SK_eUICC_ECDSA을 이용하여 계산될 수 있다. 예를 들어, eventType이 'disableProfile'인 경우, 상기 sign_Result는 resultCode|localEventType|eID|profileID|timestamp에 대해서 계산될 수 있다.
본 개시에서 사용되는 서명 인증(signature verification)용 인증서(certificate) CERT_ECDSA는 다음 표 89과 같은 포맷을 가질 수 있다.
Figure PCTKR2016003858-appb-T000089
상기 인증서 CERT_ECDSA에서 서명(signature) '5F37'의 계산에 이용되는 개인 키(private key)는 다음과 같다.
- CERT_CI_ECDSA, CERT_DP_ECDSA, CERT_SR_ECDSA, CERT_EUM_ECDSA 에 사용되는 SK.CI.ECDSA
- CERT_EUICC_ECDSA 에 사용되는 SK.EUM.ECDSA
서명될 데이터는 태그(Tag) '93', '42', '5F20', '95', '5F25', '5F24', '73', 'TBD' (있다면), 및 '7F49' 이다.
태그 'TBD' (즉, PLMNID의 리스트)는, 태그 '73' (즉, Discretionary data) 내의 태그 'C8'의 값이 '01 SM-DP+ Certificate'를 지시할 경우에 존재한다.
상기 인증서의 포맷에 포함될 수 있는 데이터 오브젝트인 Discretionary Data (: 자유 데이터)는 다음 표 90와 같은 포맷을 가질 수 있다
Figure PCTKR2016003858-appb-T000090
상기 Discretionary Data는 EUM certificate 인지(예를 들어, '04', '03') CI certificate 인지(예를 들어, '05')를 구분하는 구분자가 포함되어 있음을 주목해야 한다. 상기 Discretionary Data 를 이용함으로써, eUICC 또는 SM-SR+는 eUICC 인증서와 함께 EUM 인증서를 전송하는 것이 가능해진다. 상기 전송된 EUM 인증서를 이용함으로써, SM-DP+는 별도로 상기 EUM 인증서를 획득할 필요가 없고, CI 인증서를 통해 상기 eUICC를 인증할 수 있어서 상호운용성(interoperability)이 증가하는 효과가 발생한다.
상기 인증서의 포맷에 포함될 수 있는 데이터 오브젝트인 List of PLMNIDs (: PLMNID의 리스트)는 다음 표 91과 같은 포맷을 가질 수 있다
Figure PCTKR2016003858-appb-T000091
상기 'List of PLMNIDs' TLV는, 상기 데이터 오브젝트 Discretionary data 내의 태그 'C8'의 값이 '01 SM-DP+ Certificate'를 지시할 경우에 존재한다. 상기 'List of PLMNIDs' TLV의 값은 일련의 PLMN ID인데, 구분자(delimiter) '%'에 의개 구분된다. 예를 들어, 상기 'List of PLMNIDs' TLV가 두개의 PLMN ID '45008' 및 '310280'을 나타낼 때, 값은 '45008%310280'와 같을 수 있다. 상기 'List of PLMNIDs' TLV 의 ASN.1 표기법에 따른 포맷은 VisibleString 이다. 상기 'List of PLMNIDs' TLV 에 포함되는 PLMN ID는 SM-DP+에 의해 프로비져닝되도록 허락된 프로파일의 PLMN ID를 나타내고, 상기 SM-DP+는 상기 데이터 오브젝트 Discretionary data 내의 'D1' 태그에 의해 식별될 수 있다.
상기 인증서의 포맷에 포함될 수 있는 데이터 오브젝트인 Public Key (: 공개 키)는 다음 표 92과 같은 포맷을 가질 수 있다
Figure PCTKR2016003858-appb-T000092
본 개시에서 사용되는 키 승인(key aggrement)용 인증서 CERT_ECKA는 다음 표 93과 같은 포맷을 가질 수 있다.
Figure PCTKR2016003858-appb-T000093
상기 인증서 CERT_ECKA 에서 서명 '5F37'의 계산에 이용되는 개인 키(private key)는 다음과 같다.
- CERT_DP_ECKA 에 사용되는 SK.CI.ECDSA
- CERT_EUICC_ECKA 에 사용되는 SK.EUM.ECDSA
서명될 데이터는 태그 '93', '42', '5F20', '95', '5F25', '5F24', '73', 및 '7F49' 이다.
본 개시에서 TLS 연결의 상호 인증(mutual authentication)을 위해 사용되는 인증서 CERT_TLS는 RFC 5280에 개시된 바를 따를 수 있다. 이때, 상기 TLS 인증서가 SM-DP+를 위해 발행되었다면 상기 TLS 인증서의 Common Name(CN)은 DPID이다. 상기 TLS 인증서가 SM-SR+를 위해 발행되었다면 상기 TLS 인증서의 Common Name(CN)은 SRID이다. 상기 TLS 인증서가 SM-DS를 위해 발행되었다면 상기 TLS 인증서의 Common Name(CN)은 DSID이다.
이하에서는 본 개시에서 사용되는 TLV 구조가 ASN.1 표기법(notation)에 따라 정의된다.
TLV 구조(structure)는 DER(Distinguished Encoding Rule) 인코딩을 이용하여 인코딩될 수 있다.
ES10 인터페이스(: eUICC 와 LPA 간 인터페이스)의 TLV는 다음 표 94과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000094
Figure PCTKR2016003858-appb-I000017
ES11c 인터페이스(: 푸시 클라이언트와 RMF 간 인터페이스)의 TLV는 다음 표 95과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000095
프로파일, 프로파일 정책(Profile Policy) 및 프로파일 관리(Profile Managements)의 TLV는 다음 표 96과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000096
Figure PCTKR2016003858-appb-I000018
eUICC 정책 및 관리(eUICC Policy and Managements)의 TLV는 다음 표 97과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000097
Figure PCTKR2016003858-appb-I000019
엔티티와 ID에 관한 TLV는 다음 표 98과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000098
Figure PCTKR2016003858-appb-I000020
이벤트에 관한 TLV는 다음 표 99과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000099
Figure PCTKR2016003858-appb-I000021
토큰에 관한 TLV는 다음 표 100과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000100
Figure PCTKR2016003858-appb-I000022
로컬 관리(Local managements)에 관한 TLV는 다음 표 101과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000101
보안(security)에 관한 TLV는 다음 표 102과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000102
기타 TLV는 다음 표 103과 같은 자료 구조를 가질 수 있다.
Figure PCTKR2016003858-appb-T000103
도 8은 본 개시의 단말 장치의 구성을 예시하는 도면이다.
본 개시에 따른 단말(800)은, 프로파일정보 전달서버로부터 프로파일정보를 수신하고, 상기 프로파일정보를 이용하여 프로파일 제공서버로부터 프로파일을 수신하는 송수신부(또는 통신부)(810)와 상기 프로파일을 수신하여 통신 서비스에 연결하는 제어부(820)를 포함할 수 있다. 상기 단말(800)은 탈착형 또는 고정형의 eUICC를 더 포함할 수 있다. 예를 들어, 도 4의 AP(412, 442, 472)는 상기 제어부(820)에 의해 구현될 수 있고, CP(414, 444, 474)는 상기 송수신부(810)에 의해 구현될 수 있다. 설명의 편의상 상기 송수신부(810)와 제어부(820)는 별개의 구성인 것처럼 도시되었으나, 하나의 구성요소로 구현될 수 있음은 물론이다. 상기 단말은 전자 장치로 호칭될 수도 있다.
도 9는 본 개시에 따른 서버 장치의 구성을 예시하는 도면이다.
본 개시에 따른 각종 서버 즉, SM-DP+, SM-DS, SM-SR+ 등은 도 9의 서버(900)처럼 구현될 수 있다.
상기 서버(900)가 SM-DP+인 경우, 상기 SM-DP+(900)는 프로파일을 생성하고 암호화하는 제어부(920)를 포함하고, SM-DS에 프로파일정보를 전달하고, 상기 암호화된 프로파일을 상기 eUICC를 사용하는 단말에게 전달하는 송수신부(910)를 포함할 수 있다. 상기 제어부(920)는 전자 장치로부터 프로파일 다운로드 요청을 수신하고, 상기 전자 장치로 상기 전자장치의 UICC(universal integrated circuit card)에 설치 가능한 프로파일을 전송하도록 제어할 수 있다. 상기 프로파일정보는 상기 전자 장치의 프로파일 다운로드 요청에 이용될 수 있다.
상기 서버(900)가 SM-DS인 경우, 상기 SM-DS(900)는, SM-DP_로부터 프로파일정보를 전달받고 단말에 프로파일정보를 전달하는 송수신부(910)를 포함하고, 상기 송수신부(910)을 제어하는 제어부(920)를 포함할 수 있다. 상기 SM-DS(900)는 프로파일정보를 저장할 수 있는 (프로파일 정보를 임시로 저장 가능한) 저장부를 더 포함할 수 있다. 상기 제어부(920)는 SM-DP+로부터 수신한 프로파일정보를 등록하며, 상기 프로파일정보에 대응하는 전자 장치로 상기 프로파일정보를 전달하도록 제어할 수 있다. 상기 프로파일정보는 상기 전자 장치가 상기 SM-DP+로부터 상기 전자 장치의 UICC에 설치 가능한 프로파일을 다운로드하는데 이용될 수 있다.
상기 서버(900)가 SM-SR+인 경우, 상기 SM-SR+(900)는 프로파일정보를 전달하고 상기 암호화된 프로파일을 상기 eUICC를 사용하는 단말에게 전달하는 송수신부(910)와 상기 송수신부(910)을 제어하는 제어부(920)을 포함할 수 있다. 상기 제어부(920)는 전자 장치로부터 프로파일 다운로드 요청을 수신하고, 상기 전자 장치로 상기 전자장치의 UICC(universal integrated circuit card)에 설치 가능한 프로파일을 전송하도록 제어할 수 있다. 상기 프로파일정보는 상기 전자 장치의 프로파일 다운로드 요청에 이용될 수 있다.
상기 도 1 내지 도 9가 예시하는 시스템의 구성도, 방법의 예시도, 장치 구성도는 본 개시의 권리범위를 한정하기 위한 의도가 없음을 유의하여야 한다. 즉, 상기 도 1 내지 도 9에 기재된 모든 구성부, 또는 동작의 단계가 본 개시의 실시를 위한 필수구성요소인 것으로 해석되어서는 안되며, 일부 구성요소 만을 포함하여도 본 개시의 본질을 해치지 않는 범위 내에서 구현될 수 있다.
앞서 설명한 동작들은 해당 프로그램 코드를 저장한 메모리 장치를 통신 시스템의 엔터티, 기능(Function), 기지국, 또는 단말 장치 내의 임의의 구성부에 구비함으로써 실현될 수 있다. 즉, 엔터티, 기능(Function), 기지국, 또는 단말 장치의 제어부는 메모리 장치 내에 저장된 프로그램 코드를 프로세서 혹은 CPU(Central Processing Unit)에 의해 읽어내어 실행함으로써 앞서 설명한 동작들을 실행할 수 있다.
본 개시에서 설명되는 엔터티, 기능(Function), 기지국, 또는 단말 장치의 다양한 구성부들과, 모듈(module)등은 하드웨어(hardware) 회로, 일 예로 상보성 금속 산화막 반도체(complementary metal oxide semiconductor) 기반 논리 회로와, 펌웨어(firmware)와, 소프트웨어(software) 및/혹은 하드웨어와 펌웨어 및/혹은 머신 판독 가능 매체에 삽입된 소프트웨어의 조합과 같은 하드웨어 회로를 사용하여 동작될 수도 있다. 일 예로, 다양한 전기 구조 및 방법들은 트랜지스터(transistor)들과, 논리 게이트(logic gate)들과, 주문형 반도체와 같은 전기 회로들을 사용하여 실시될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시예에 국한되어 정해져서는 안되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. 이동통신 시스템에서 eUICC(embed universal integrated circuit card)를 구비하는 단말의 프로파일 설치 방법에 있어서,
    eUICC에게 eUICC 인증서를 요청하여 상기 eUICC 인증서를 수신하는 동작;
    상기 eUICC에게 상기 eUICC 정보를 요청하여 상기 eUICC 정보를 수신하는 동작;
    상기 eUICC 정보를 포함하는 다운로드 초기화 메시지를 프로파일 제공서버에게 전송하는 동작;
    상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 포함하는 상기 다운로드 초기화 메시지에 대한 응답 메시지를 수신하는 동작;
    상기 응답 메시지에 포함된 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 상기 eUICC에게 전달하는 동작;
    상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 상기 eUICC로부터 수신하는 동작;
    상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 포함하는 프로파일패키지 요청 메시지를 상기 프로파일 제공서버에게 전송하는 동작; 및
    상기 프로파일패키지 요청 메시지에 대한 응답으로 수신한 프로파일 패키지를 eUICC에게 전달하여 상기 프로파일을 설치하는 동작을 포함하되,
    상기 수신되는 eUICC 인증서는 EUM(eUICC manufacturer) 인증서를 더 포함함을 특징으로 하는 방법.
  2. 제1항에 있어서,
    상기 EUM 인증서는 상기 프로파일 제공서버에 의해 상기 eUICC 인증서의 검증에 이용됨을 특징으로 하는 방법.
  3. 제1항에 있어서,
    상기 다운로드 초기화 메시지에 대한 응답 메시지는 프로파일 다운로드 세션을 구분하는 트랜잭션ID를 더 포함함을 특징으로 하는 방법.
  4. 제3항에 있어서,
    상기 트랜잭센ID는 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값과 함께 상기 eUICC에 전달됨을 특징으로 하는 방법.
  5. 제1항에 있어서,
    상기 eUICC에게 상기 eUICC 정보를 요청하는 동작은 eUICC 챌린지 생성 요청 메시지에 의해 전송됨을 특징으로 하는 방법.
  6. 제5항에 있어서,
    상기 eUICC 챌린지 생성 요청 메시지에 대한 응답으로써 상기 eUICC 챌린지 및 상기 eUICC 인증서에 대한 정보를 수신하는 동작을 더 포함함을 특징으로 하는 방법.
  7. 제1항에 있어서,
    상기 eUICC 인증서에 대한 정보는 암호화 키 정보로써 타원 곡선 파라미터(Elliptic Curver Parameter)를 포함함을 특징으로 하는 방법.
  8. 제1항에 있어서,
    상기 eUICC 인증서는, 인증서의 종류가 EUM 인증서 인지 CI(certificate issuer) 인증서인지를 지시하는 태그를 포함하는 포맷을 가짐을 특징으로 하는 방법.
  9. 이동통신 시스템에서 eUICC(embed universal integrated circuit card)를 구비하는 단말 장치에 있어서,
    eUICC에게 eUICC 인증서를 요청하여 상기 eUICC 인증서를 수신하고, 상기 eUICC에게 상기 eUICC 정보를 요청하여 상기 eUICC 정보를 수신하고, 상기 eUICC 정보를 포함하는 다운로드 초기화 메시지를 프로파일 제공서버에게 전송하고, 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 포함하는 상기 다운로드 초기화 메시지에 대한 응답 메시지를 수신하고, 상기 응답 메시지에 포함된 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 상기 eUICC에게 전달하고, 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 상기 eUICC로부터 수신하고, 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 포함하는 프로파일패키지 요청 메시지를 상기 프로파일 제공서버에게 전송하고, 상기 프로파일패키지 요청 메시지에 대한 응답으로 수신한 프로파일 패키지를 eUICC에게 전달하여 상기 프로파일을 설치하도록 제어하는 제어부; 및
    상기 제어부의 제어에 의해 상기 수신 또는 전송동작을 수행하는 송수신부를 포함하되,
    상기 수신되는 eUICC 인증서는 EUM(eUICC manufacturer) 인증서를 더 포함함을 특징으로 하는 단말.
  10. 제9항에 있어서,
    상기 EUM 인증서는 상기 프로파일 제공서버에 의해 상기 eUICC 인증서의 검증에 이용됨을 특징으로 하는 단말.
  11. 제9항에 있어서,
    상기 다운로드 초기화 메시지에 대한 응답 메시지는 프로파일 다운로드 세션을 구분하는 트랜잭션ID를 더 포함함을 특징으로 하는 단말.
  12. 제11항에 있어서,
    상기 트랜잭센ID는 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값과 함께 상기 eUICC에 전달됨을 특징으로 하는 단말.
  13. 제9항에 있어서,
    상기 제어부는, eUICC 챌린지 생성 요청 메시지에 의해 상기 eUICC에게 상기 eUICC 정보를 요청함을 특징으로 하는 단말.
  14. 제13항에 있어서,
    상기 제어부는, 상기 eUICC 챌린지 생성 요청 메시지에 대한 응답으로써 상기 eUICC 챌린지 및 상기 eUICC 인증서에 대한 정보를 수신하는 동작을 더 수행함을 특징으로 하는 단말.
  15. 제14항에 있어서,
    상기 eUICC 인증서에 대한 정보는 암호화 키 정보로써 타원 곡선 파라미터(Elliptic Curver Parameter)를 포함함을 특징으로 하는 단말.
PCT/KR2016/003858 2015-04-13 2016-04-12 통신 시스템에서 프로파일을 관리하는 기법 WO2016167551A1 (ko)

Priority Applications (7)

Application Number Priority Date Filing Date Title
EP19181026.6A EP3562184B1 (en) 2015-04-13 2016-04-12 Technique for managing profile in communication system
AU2016247689A AU2016247689B2 (en) 2015-04-13 2016-04-12 Technique for managing profile in communication system
KR1020177032815A KR102558361B1 (ko) 2015-04-13 2016-04-12 통신 시스템에서 프로파일을 관리하는 기법
US15/566,561 US10439823B2 (en) 2015-04-13 2016-04-12 Technique for managing profile in communication system
CN201680029919.0A CN107873137B (zh) 2015-04-13 2016-04-12 用于管理通信系统中的简档的技术
EP16780274.3A EP3297309B1 (en) 2015-04-13 2016-04-12 Technique for managing profile in communication system
US16/594,752 US10965470B2 (en) 2015-04-13 2019-10-07 Technique for managing profile in communication system

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201562146622P 2015-04-13 2015-04-13
US62/146,622 2015-04-13
US201562149732P 2015-04-20 2015-04-20
US62/149,732 2015-04-20
US201562158067P 2015-05-07 2015-05-07
US62/158,067 2015-05-07
US201562212387P 2015-08-31 2015-08-31
US62/212,387 2015-08-31

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/566,561 A-371-Of-International US10439823B2 (en) 2015-04-13 2016-04-12 Technique for managing profile in communication system
US16/594,752 Continuation US10965470B2 (en) 2015-04-13 2019-10-07 Technique for managing profile in communication system

Publications (1)

Publication Number Publication Date
WO2016167551A1 true WO2016167551A1 (ko) 2016-10-20

Family

ID=57126301

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/003858 WO2016167551A1 (ko) 2015-04-13 2016-04-12 통신 시스템에서 프로파일을 관리하는 기법

Country Status (6)

Country Link
US (2) US10439823B2 (ko)
EP (2) EP3562184B1 (ko)
KR (1) KR102558361B1 (ko)
CN (1) CN107873137B (ko)
AU (1) AU2016247689B2 (ko)
WO (1) WO2016167551A1 (ko)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106851621A (zh) * 2017-02-17 2017-06-13 惠州Tcl移动通信有限公司 一种基于rsp的lpa应用实现方法及实现系统
CN106937274A (zh) * 2017-05-12 2017-07-07 东信和平科技股份有限公司 一种基于EUICC的Profile切换方法及装置
WO2018129753A1 (zh) * 2017-01-16 2018-07-19 华为技术有限公司 一种签约信息集的下载方法、装置以及相关设备
WO2018147711A1 (en) 2017-02-13 2018-08-16 Samsung Electronics Co., Ltd. APPARATUS AND METHOD FOR ACCESS CONTROL ON eSIM
CN108702617A (zh) * 2017-02-10 2018-10-23 华为技术有限公司 一种更新证书颁发者公钥的方法、相关设备及系统
CN109245900A (zh) * 2018-09-14 2019-01-18 北京清大智信科技有限公司 一种毫米级超微型计算机安全交互方法及系统
WO2019018244A1 (en) * 2017-07-20 2019-01-24 T-Mobile Usa, Inc. SUPPLY OF ESIM PROFILE METADATA
WO2019028698A1 (en) * 2017-08-09 2019-02-14 Apple Inc. PROTECTION OF THE CONFIDENTIALITY OF A SUBSCRIBER IDENTITY
CN109716805A (zh) * 2016-11-22 2019-05-03 华为技术有限公司 一种签约数据集的安装方法、终端及服务器
WO2019095948A1 (zh) * 2017-11-17 2019-05-23 华为技术有限公司 一种事件的处理方法和终端
WO2019120610A1 (en) * 2017-12-22 2019-06-27 Giesecke+Devrient Mobile Security Gmbh Msisdn registration
WO2019119267A1 (zh) * 2017-12-19 2019-06-27 华为技术有限公司 配置文件管理的方法、嵌入式通用集成电路卡和终端
US10356604B2 (en) 2017-07-20 2019-07-16 T-Mobile Usa, Inc. eSIM profile reuse for eUICCs
US10362475B2 (en) 2017-07-20 2019-07-23 T-Mobile Usa, Inc. Subscription management service data feeds
US10368230B2 (en) 2017-07-20 2019-07-30 T-Mobile Usa, Inc. Data enhancements for eSIM profile operation callbacks
CN110121859A (zh) * 2017-08-28 2019-08-13 华为技术有限公司 一种信息验证方法及相关设备
CN110178393A (zh) * 2017-01-13 2019-08-27 华为技术有限公司 一种签约数据集的下载方法、设备及服务器
EP3531667A1 (de) * 2018-02-26 2019-08-28 Deutsche Telekom AG Herstellung von kommunikationsfunktionen für teilnehmeridentitätsmodule
CN110301146A (zh) * 2017-03-01 2019-10-01 华为技术有限公司 网络配置方法及终端
CN111434087A (zh) * 2017-11-30 2020-07-17 三星电子株式会社 用于提供通信服务的方法和电子设备
WO2021187874A1 (ko) * 2020-03-16 2021-09-23 삼성전자 주식회사 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6333410B2 (ja) 2014-06-24 2018-05-30 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 障害処理方法、関連装置、およびコンピュータ
US11080414B2 (en) * 2015-05-22 2021-08-03 Huawei Device Co., Ltd. Cryptographic unit for public key infrastructure (PKI) operations
FR3039738B1 (fr) * 2015-07-28 2018-06-22 Idemia France Procede de gestion d'un profil enregistre dans un element securise, et element securise correspondant
EP4164263A1 (en) * 2016-02-25 2023-04-12 Huawei Technologies Co., Ltd. Application processing method and apparatus for embedded universal integrated circuit card
CN107182048B (zh) * 2016-03-10 2021-06-25 中兴通讯股份有限公司 实现多个终端共享用户身份识别卡的方法和装置
US9900765B2 (en) * 2016-06-02 2018-02-20 Apple Inc. Method and apparatus for creating and using a roaming list based on a user roaming plan
FR3059194B1 (fr) * 2016-11-21 2019-06-28 Oberthur Technologies Installation d'un profil dans un module d'identite de souscripteur embarque
EP3610626B1 (en) * 2017-04-12 2023-06-07 Telefonaktiebolaget LM Ericsson (Publ) Methods for automatic bootstrapping of a device
US10122606B1 (en) * 2017-05-04 2018-11-06 Netscout Systems, Inc. System and method for estimating an amount of acknowledged application data transmitted by encrypted transport
DE102017212994B3 (de) * 2017-05-31 2018-11-29 Apple Inc. INSTALLATION UND TESTEN EINES ELEKTRONISCHEN TEILNEHMERIDENTITÄTSMODULS (eSIM)
KR102462366B1 (ko) * 2018-04-06 2022-11-04 삼성전자주식회사 eUICC 버전을 협상하는 방법 및 장치
US20190312878A1 (en) * 2018-04-09 2019-10-10 Averon Us, Inc. Secure communication using device-identity information linked to cloud-based certificates
CN110475200B (zh) * 2018-05-10 2021-07-09 华为技术有限公司 定位终端设备的方法和设备
CN110474945B (zh) * 2018-05-11 2021-08-03 华为技术有限公司 一种数据下载、管理的方法和终端
CN108966205B (zh) * 2018-07-04 2021-08-27 高新兴物联科技有限公司 一种兼容多种eSIM管理规范的方法、设备及计算机可读存储介质
CN112956155B (zh) * 2018-09-07 2024-04-05 三星电子株式会社 Ssp设备和服务器协商数字证书的装置和方法
CN110932858B (zh) * 2018-09-19 2023-05-02 阿里巴巴集团控股有限公司 认证方法和系统
US10798564B2 (en) * 2018-10-05 2020-10-06 T-Mobile USA, Inc Machine-readable code-based embedded subscriber identity module (ESIM) profile download
CN109495874B (zh) * 2018-12-28 2020-06-02 恒宝股份有限公司 Profile下载的方法和装置
US10687204B1 (en) * 2019-05-20 2020-06-16 T-Mobile Usa, Inc. Intelligent SIM profile procurement
CN112073176B (zh) * 2019-06-11 2022-03-11 大唐移动通信设备有限公司 密钥更新方法及装置
US20220377081A1 (en) * 2019-09-20 2022-11-24 Samsung Electronics Co., Ltd. Mutual device-to-device authentication method and device during device-to-device bundle or profile transfer
US20230300596A1 (en) * 2020-06-26 2023-09-21 Telefonaktiebolaget Lm Ericsson (Publ) Remote subscription profile download
CN111522516B (zh) * 2020-07-06 2020-10-27 飞天诚信科技股份有限公司 一种云播报打印数据的处理方法及系统
US11310659B2 (en) 2020-07-10 2022-04-19 Cisco Technology, Inc. Techniques for provisioning an enterprise electronic subscriber identity module (ESIM) profile for an enterprise user
US11785456B2 (en) 2020-08-18 2023-10-10 Cisco Technology, Inc. Delivering standalone non-public network (SNPN) credentials from an enterprise authentication server to a user equipment over extensible authentication protocol (EAP)
CN112637848B (zh) * 2020-12-18 2023-03-14 中国联合网络通信集团有限公司 管理认证应用证书的方法、装置和系统
CN112543448A (zh) * 2020-12-21 2021-03-23 中国联合网络通信集团有限公司 电子卡安装方法、设备及系统
CN113190862B (zh) * 2021-05-10 2023-01-06 成都卫士通信息产业股份有限公司 基于sm2的无证书密钥生成方法、装置、电子设备及介质
US11564081B1 (en) 2021-07-06 2023-01-24 Cisco Technology, Inc. Auto-update and activation of locale-specific eSIM profile for a global enterprise user
EP4352979A1 (en) * 2021-08-20 2024-04-17 Samsung Electronics Co., Ltd. Method and device for providing event in wireless communication system
CN113873516B (zh) * 2021-08-25 2023-10-20 国网江苏省电力有限公司泰州供电分公司 一种高安全性的电网无线通信系统
CN114189334B (zh) * 2021-11-05 2023-09-26 卓望数码技术（深圳）有限公司 一种可管控的eSIM终端证书在线签发方法和系统
US20230354026A1 (en) * 2022-04-29 2023-11-02 Microsoft Technology Licensing, Llc Encrypted flow of sim data between regions and edge networks

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013036010A1 (ko) * 2011-09-05 2013-03-14 주식회사 케이티 내장 uicc의 인증정보를 이용한 인증방법과, 그를 이용한 프로비저닝 및 mno 변경 방법, 그를 위한 내장 uicc, mno 시스템 및 기록매체
US20140228071A1 (en) * 2011-05-27 2014-08-14 Telefonica, S.A. Method to switch subscriptions of a personal device supporting multiple subscriptions
US20140235210A1 (en) * 2011-09-05 2014-08-21 Kt Corporation Method for managing embedded uicc and embedded uicc, mno system, provision method, and method for changing mno using same
WO2014193181A1 (ko) * 2013-05-30 2014-12-04 삼성전자 주식회사 프로파일 설치를 위한 방법 및 장치

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1680719B1 (en) * 2003-11-07 2019-08-14 Nokia Technologies Oy Method and device for controlling installation of applications using operator root certificates
MX2012006589A (es) * 2009-12-11 2012-06-19 Nokia Corp Perfil de caracteristica de seguridad de tarjeta inteligente en servidor de abonado domestico.
US8555067B2 (en) * 2010-10-28 2013-10-08 Apple Inc. Methods and apparatus for delivering electronic identification components over a wireless network
EP2461613A1 (en) * 2010-12-06 2012-06-06 Gemalto SA Methods and system for handling UICC data
US9009475B2 (en) * 2011-04-05 2015-04-14 Apple Inc. Apparatus and methods for storing electronic access clients
KR102001869B1 (ko) * 2011-09-05 2019-07-19 주식회사 케이티 ｅＵＩＣＣ의 프로파일 관리방법 및 그를 이용한 ｅＵＩＣＣ, ｅＵＩＣＣ 탑재 단말과, 프로비저닝 방법 및 ＭＮＯ 변경 방법
KR101954450B1 (ko) * 2011-09-05 2019-05-31 주식회사 케이티 내장 ｕｉｃｃ의 인증정보를 이용한 인증방법과, 그를 이용한 프로비저닝 및 ｍｎｏ 변경 방법, 그를 위한 내장 ｕｉｃｃ, ｍｎｏ 시스템 및 기록매체
EP2587715B1 (en) * 2011-09-20 2017-01-04 BlackBerry Limited Assisted certificate enrollment
KR101986312B1 (ko) * 2011-11-04 2019-06-05 주식회사 케이티 신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ
BR112014019937A8 (pt) * 2012-02-14 2017-07-11 Apple Inc Método e aparelho para distribuição em grande escala de clientes de acesso eletrônico
WO2014042701A1 (en) * 2012-09-17 2014-03-20 Motorola Mobility Llc Efficient key generator for distribution of sensitive material from mulitple application service providers to a secure element such as a universal integrated circuit card (uicc)
WO2014069871A1 (ko) 2012-10-29 2014-05-08 주식회사 케이티 가입자 인증 모듈을 관리하는 개체를 변경하는 방법 및 이를 이용하는 장치
EP2747466B1 (en) * 2012-12-21 2017-10-04 Giesecke+Devrient Mobile Security GmbH Methods and devices for ota subscription management
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
US9100175B2 (en) * 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
EP3073770A4 (en) * 2013-12-05 2016-10-26 Huawei Device Co Ltd SECURITY CONTROL METHOD FOR EUICC AND EUICC
US9730072B2 (en) * 2014-05-23 2017-08-08 Apple Inc. Electronic subscriber identity module provisioning
TWI573473B (zh) * 2014-05-30 2017-03-01 蘋果公司 在無線通訊裝置中之電子用戶識別模組的安全儲存
US9722975B2 (en) * 2014-07-03 2017-08-01 Apple Inc. Methods and apparatus for establishing a secure communication channel
EP3148235B1 (en) * 2014-07-07 2021-03-17 Huawei Technologies Co., Ltd. Authorization method and apparatus for management of embedded universal integrated circuit card
KR102032857B1 (ko) * 2015-03-22 2019-10-16 애플 인크. 모바일 디바이스에서의 사용자 인증 및 인간 의도 검증을 위한 방법 및 장치

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140228071A1 (en) * 2011-05-27 2014-08-14 Telefonica, S.A. Method to switch subscriptions of a personal device supporting multiple subscriptions
WO2013036010A1 (ko) * 2011-09-05 2013-03-14 주식회사 케이티 내장 uicc의 인증정보를 이용한 인증방법과, 그를 이용한 프로비저닝 및 mno 변경 방법, 그를 위한 내장 uicc, mno 시스템 및 기록매체
US20140235210A1 (en) * 2011-09-05 2014-08-21 Kt Corporation Method for managing embedded uicc and embedded uicc, mno system, provision method, and method for changing mno using same
WO2014193181A1 (ko) * 2013-05-30 2014-12-04 삼성전자 주식회사 프로파일 설치를 위한 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"3GPP; TSG CT; Universal Subscriber Identity Module (USIM) Application Toolkit (USAT) (Release 12", 3GPP TS 31.111 V12.7.0, 27 March 2015 (2015-03-27), XP055324678, Retrieved from the Internet <URL:http://www.3gpp.org/DynaReport/31111.htm> *

Cited By (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10667123B2 (en) 2016-11-22 2020-05-26 Huawei Technologies Co., Ltd. Method for installing subscription profile, terminal, and server
CN109716805B (zh) * 2016-11-22 2020-11-06 华为技术有限公司 一种签约数据集的安装方法、终端及服务器
CN109716805A (zh) * 2016-11-22 2019-05-03 华为技术有限公司 一种签约数据集的安装方法、终端及服务器
CN110178393A (zh) * 2017-01-13 2019-08-27 华为技术有限公司 一种签约数据集的下载方法、设备及服务器
US11832347B2 (en) 2017-01-13 2023-11-28 Huawei Technologies Co., Ltd. Subscription profile downloading method, device, and server
EP3565289A4 (en) * 2017-01-13 2019-11-06 Huawei Technologies Co., Ltd. METHOD, DEVICE AND SERVER FOR DOWNLOADING SUBSCRIPTION PROFILE
CN110121894B (zh) * 2017-01-16 2021-02-05 华为技术有限公司 一种签约信息集的下载方法、装置以及相关设备
WO2018129753A1 (zh) * 2017-01-16 2018-07-19 华为技术有限公司 一种签约信息集的下载方法、装置以及相关设备
CN110121894A (zh) * 2017-01-16 2019-08-13 华为技术有限公司 一种签约信息集的下载方法、装置以及相关设备
EP4221088A3 (en) * 2017-02-10 2023-09-06 Huawei Technologies Co., Ltd. Method and system for updating certificate issuer public key, and related device
US11223950B2 (en) 2017-02-10 2022-01-11 Huawei Technologies Co., Ltd. Method and system for updating certificate issuer public key, and related device
CN108702617B (zh) * 2017-02-10 2021-01-12 华为技术有限公司 一种更新证书颁发者公钥的方法、相关设备及系统
US20220095109A1 (en) * 2017-02-10 2022-03-24 Huawei Technologies Co., Ltd. Method and System for Updating Certificate Issuer Public Key, and Related Device
CN108702617A (zh) * 2017-02-10 2018-10-23 华为技术有限公司 一种更新证书颁发者公钥的方法、相关设备及系统
EP3567888A4 (en) * 2017-02-10 2019-12-04 Huawei Technologies Co., Ltd. METHOD FOR UPDATING PUBLIC CERTIFICATE TRANSMITTER KEY, AND DEVICE AND SYSTEM THEREOF
US11601809B2 (en) 2017-02-10 2023-03-07 Huawei Technologies Co., Ltd. Method and system for updating certificate issuer public key, and related device
US11930360B2 (en) 2017-02-10 2024-03-12 Huawei Technologies Co., Ltd. Method and system for updating certificate issuer public key, and related device
EP3905742A1 (en) * 2017-02-13 2021-11-03 Samsung Electronics Co., Ltd. Apparatus and method for access control on esim
CN110024426B (zh) * 2017-02-13 2022-09-02 三星电子株式会社 通过eSIM进行访问控制的装置及方法
KR102293683B1 (ko) * 2017-02-13 2021-08-26 삼성전자 주식회사 eSIM 접근 제어 방법 및 장치
US11496883B2 (en) 2017-02-13 2022-11-08 Samsung Electronics Co., Ltd Apparatus and method for access control on eSIM
EP3566481A4 (en) * 2017-02-13 2020-10-14 Samsung Electronics Co., Ltd. ESIM ACCESS CONTROL APPARATUS AND METHOD
KR20180093333A (ko) * 2017-02-13 2018-08-22 삼성전자주식회사 eSIM 접근 제어 방법 및 장치
WO2018147711A1 (en) 2017-02-13 2018-08-16 Samsung Electronics Co., Ltd. APPARATUS AND METHOD FOR ACCESS CONTROL ON eSIM
CN110024426A (zh) * 2017-02-13 2019-07-16 三星电子株式会社 通过eSIM进行访问控制的装置及方法
WO2018149356A1 (zh) * 2017-02-17 2018-08-23 Tcl通讯（宁波）有限公司 一种基于rsp的lpa应用实现方法、实现系统及终端
US11019482B2 (en) 2017-02-17 2021-05-25 Tcl Communications (Ningbo) Co., Ltd. Method, system, and terminal device for realizing local profile assistant based on remote subscriber identification module provisioning
CN106851621A (zh) * 2017-02-17 2017-06-13 惠州Tcl移动通信有限公司 一种基于rsp的lpa应用实现方法及实现系统
CN110301146A (zh) * 2017-03-01 2019-10-01 华为技术有限公司 网络配置方法及终端
CN110301146B (zh) * 2017-03-01 2021-02-26 华为技术有限公司 网络配置方法及终端
CN106937274A (zh) * 2017-05-12 2017-07-07 东信和平科技股份有限公司 一种基于EUICC的Profile切换方法及装置
CN106937274B (zh) * 2017-05-12 2020-06-09 东信和平科技股份有限公司 一种基于EUICC的Profile切换方法及装置
US10721614B2 (en) 2017-07-20 2020-07-21 T-Mobile Usa, Inc. Enhancements to eSIM profile operation callbacks using a machine-to-machine (M2M) device
US10477383B2 (en) 2017-07-20 2019-11-12 T-Mobile Usa, Inc. ESIM profile metadata provisioning
US10362475B2 (en) 2017-07-20 2019-07-23 T-Mobile Usa, Inc. Subscription management service data feeds
US11223941B2 (en) 2017-07-20 2022-01-11 T-Mobile Usa, Inc. Data feeds of consumer eSIMS for a subscription management service
WO2019018244A1 (en) * 2017-07-20 2019-01-24 T-Mobile Usa, Inc. SUPPLY OF ESIM PROFILE METADATA
US10356604B2 (en) 2017-07-20 2019-07-16 T-Mobile Usa, Inc. eSIM profile reuse for eUICCs
US10368230B2 (en) 2017-07-20 2019-07-30 T-Mobile Usa, Inc. Data enhancements for eSIM profile operation callbacks
WO2019028698A1 (en) * 2017-08-09 2019-02-14 Apple Inc. PROTECTION OF THE CONFIDENTIALITY OF A SUBSCRIBER IDENTITY
US11234131B2 (en) 2017-08-28 2022-01-25 Huawei Technologies Co., Ltd. Information verification method and related device
CN110121859B (zh) * 2017-08-28 2021-01-15 华为技术有限公司 一种信息验证方法及相关设备
CN110121859A (zh) * 2017-08-28 2019-08-13 华为技术有限公司 一种信息验证方法及相关设备
WO2019095948A1 (zh) * 2017-11-17 2019-05-23 华为技术有限公司 一种事件的处理方法和终端
CN111434087B (zh) * 2017-11-30 2022-12-02 三星电子株式会社 用于提供通信服务的方法和电子设备
CN111434087A (zh) * 2017-11-30 2020-07-17 三星电子株式会社 用于提供通信服务的方法和电子设备
US11516672B2 (en) 2017-12-19 2022-11-29 Huawei Technologies Co., Ltd. Profile management method, embedded universal integrated circuit card, and terminal
WO2019119267A1 (zh) * 2017-12-19 2019-06-27 华为技术有限公司 配置文件管理的方法、嵌入式通用集成电路卡和终端
US10966081B2 (en) 2017-12-22 2021-03-30 Giesecke+Devrient Mobile Security Gmbh MSISDN registration
WO2019120610A1 (en) * 2017-12-22 2019-06-27 Giesecke+Devrient Mobile Security Gmbh Msisdn registration
EP3531667A1 (de) * 2018-02-26 2019-08-28 Deutsche Telekom AG Herstellung von kommunikationsfunktionen für teilnehmeridentitätsmodule
CN109245900A (zh) * 2018-09-14 2019-01-18 北京清大智信科技有限公司 一种毫米级超微型计算机安全交互方法及系统
WO2021187874A1 (ko) * 2020-03-16 2021-09-23 삼성전자 주식회사 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치

Also Published As

Publication number Publication date
EP3562184B1 (en) 2020-08-12
US20200052907A1 (en) 2020-02-13
KR102558361B1 (ko) 2023-07-21
EP3297309A4 (en) 2018-04-18
AU2016247689A1 (en) 2017-11-30
US10965470B2 (en) 2021-03-30
US10439823B2 (en) 2019-10-08
EP3297309B1 (en) 2019-06-19
US20180123803A1 (en) 2018-05-03
AU2016247689B2 (en) 2020-07-02
CN107873137A (zh) 2018-04-03
AU2016247689A2 (en) 2017-12-14
EP3562184A1 (en) 2019-10-30
EP3297309A1 (en) 2018-03-21
CN107873137B (zh) 2021-11-23
KR20170140809A (ko) 2017-12-21

Similar Documents

Publication Publication Date Title
WO2016167551A1 (ko) 통신 시스템에서 프로파일을 관리하는 기법
WO2017039320A1 (ko) 통신 시스템에서 프로파일 다운로드 방법 및 장치
WO2016178548A1 (ko) 프로파일 제공 방법 및 장치
WO2019050325A1 (en) METHOD AND APPARATUS FOR SUPPORTING PROFILE TRANSFER BETWEEN DEVICES IN A WIRELESS COMMUNICATION SYSTEM
WO2020226454A1 (en) Apparatus and method for providing mobile edge computing services in wireless communication system
WO2016163796A1 (en) Method and apparatus for downloading a profile in a wireless communication system
WO2016167536A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2016080726A1 (en) Apparatus and method for profile installation in communication system
EP3284274A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2018008972A1 (en) Method and apparatus for accessing cellular network for sim profile
WO2018135919A1 (en) Apparatus and method for providing and managing security information in communication system
WO2015061992A1 (zh) 一种密钥配置方法、系统和装置
WO2020171672A1 (en) Method for interoperating between bundle download process and esim profile download process by ssp terminal
WO2020080909A1 (en) Method and apparatus for handling remote profile management exception
WO2019107876A1 (en) Method and apparatus for managing event in communication system
EP3520363A1 (en) Apparatus and method for providing and managing security information in communication system
EP3566481A1 (en) APPARATUS AND METHOD FOR ACCESS CONTROL ON eSIM
WO2020226466A1 (en) Method and apparatus for managing and verifying certificate
EP3854115A1 (en) Method and apparatus for handling remote profile management exception
WO2022045789A1 (en) Method and apparatus for recovering profile in case of device change failure
EP3530016A1 (en) Apparatus and method for installing and managing esim profiles
WO2020184995A1 (ko) Euicc 단말을 변경하는 방법 및 장치
WO2020171475A1 (ko) 무선 통신 시스템의 기기변경 방법 및 장치
WO2022139373A1 (en) Method and apparatus to manage authentication and subscription information in wireless communication system
WO2022045869A1 (en) Apparatus and method for managing events in communication system

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15566561

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20177032815

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2016247689

Country of ref document: AU

Date of ref document: 20160412

Kind code of ref document: A