Patent Description:
In order to meet wireless data traffic demands that have increased after <NUM> communication system commercialization, efforts to develop an improved <NUM> communication system or a pre-<NUM> communication system have been made. For this reason, the <NUM> communication system or the pre-<NUM> communication system is called a beyond <NUM> network communication system or a post LTE system.

In order to achieve a high data transmission rate, an implementation of the <NUM> communication system in a mmWave band (for example, <NUM> band) is being considered. In the <NUM> communication system, technologies such as beamforming, massive MIMO, Full Dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, and large scale antenna are being discussed as means to mitigate a propagation path loss in the mm Wave band and increase a propagation transmission distance.

Further, the <NUM> communication system has developed technologies such as an evolved small cell, an advanced small cell, a cloud Radio Access Network (RAN), an ultra-dense network, Device to Device communication (D2D), a wireless backhaul, a moving network, cooperative communication, Coordinated Multi-Points (CoMP), and received interference cancellation to improve the system network.

In addition, the <NUM> system has developed Advanced Coding Modulation (ACM) schemes such as Hybrid FSK and QAM Modulation (FQAM) and Sliding Window Superposition Coding (SWSC), and advanced access technologies such as Filter Bank Multi Carrier (FBMC), Non Orthogonal Multiple Access (NOMA), and Sparse Code Multiple Access (SCMA).

Meanwhile, the Internet has been evolved to an Internet of Things (IoT) network in which distributed components such as objects exchange and process information from a human-oriented connection network in which humans generate and consume information. An Internet of Everything (IoE) technology in which a big data processing technology through a connection with a cloud server or the like is combined with the loT technology has emerged. In order to implement loT, technical factors such as a sensing technique, wired/wireless communication, network infrastructure, service-interface technology, and security technology are required, and research on technologies such as a sensor network, Machine-to-Machine (M2M) communication, Machine-Type Communication (MTC), and the like for connection between objects has recently been conducted. In an loT environment, through collection and analysis of data generated in connected objects, an intelligent Internet Technology (IT) service to create a new value for peoples' lives may be provided. The loT may be applied to fields such as those of a smart home, a smart building, a smart city, a smart car, a connected car, a smart grid, health care, a smart home appliance, or high-tech medical services through the convergence of the conventional Information Technology (IT) and various industries.

Accordingly, various attempts to apply the <NUM> communication to the loT network are made. For example, technologies, such as a sensor network, machine-to-machine (M2M) communication, machine type communication (MTC), and the like, are being implemented by <NUM> communication techniques such as beamforming, MIMO, array antennas, and the like. The application of a cloud RAN as the big data processing technology may be an example of convergence of the <NUM> technology and the loT technology.

A universal integrated circuit card (UICC) is a smart card that is inserted into a mobile terminal and the like for use and is also called a "UICC". The UICC may include an access control module for accessing a mobile communication provider's network. Examples of the access control module include a universal subscriber identity module (USIM), a subscriber identity module (SIM), an IP multimedia service identity module (ISIM), and the like. A UICC including a USIM is commonly called a "USIM card". Likewise, a UICC including a SIM module is commonly called a "SIM card". In the following description of the disclosure, a SIM card will be used as a typical meaning encompassing a UICC, a USIM card, a UICC including an ISIM, and the like. That is, although a description is made of the SIM card, techniques thereof may be equally applied to a USIM card, an ISIM card, or a general UICC.

The SIM card stores personal information of a mobile communication subscriber and performs subscriber authentication and producing a traffic security key when accessing a mobile communication network, thereby enabling secure usage of mobile communication.

At the time of proposing the disclosure, the SIM card is generally manufactured as a dedicated card to a specific mobile communication provider at the request of the corresponding provider when manufacturing the card, and authentication information of the corresponding provider for network access, such as a universal subscriber identity module (USIM) application, an international mobile subscriber identity (IMSI), a K value, an OPc value, and the like, are prerecorded in the card to then be provided. Therefore, the manufactured SIM card is supplied to the corresponding mobile communication provider, and the mobile communication provider provides the SIM card to the subscriber. Thereafter, if necessary, it is possible to perform management of installation, modification, and deletion of an application with respect to the UICC using technology such as over-the-air (OTA) or the like. The subscriber may insert the UICC into a mobile terminal owned by the subscriber, thereby using the network and application services of the corresponding mobile communication provider. When replacing the terminal, the subscriber may take out the UICC from the existing terminal and insert the same into a new terminal, thereby using authentication information, a mobile phone number, personal phone books, and the like without any change.

However, the SIM card is inconvenient for the user of the mobile terminal when receiving services from other mobile communication providers. The user of the mobile terminal must physically acquire a SIM card in order to receive services from a mobile communication provider. For example, if the user travels to another country, the user must acquire a local SIM card in order to receive local mobile communication services. Although a roaming service solves the above inconvenience to some extent, a service charge of the roaming service is very high, and the roaming service requires a separate contract between the mobile communication providers.

Meanwhile, if a SIM module is able to be remotely downloaded and installed in the UICC, most of the inconveniences may be eliminated. That is, the user may download, to the UICC, a SIM module of the mobile communication services to be used at the time desired by the user. In addition, the UICC may download and install a plurality of SIM modules, and may select and use only one of the SIM modules. The UICC may or may not be fixed to the terminal. In particular, a UICC fixed to a terminal is called an "embedded UICC (eUICC)". Typically, the eUICC denotes a UICC that is fixed to a terminal and may select a SIM module by remotely downloading the same. In the disclosure, a UICC capable of remotely downloading and selecting the SIM module will be collectively referred to as an "eUICC". That is, among the UICCs capable of remotely downloading and selecting the SIM module, the UICC that is or is not fixed to the terminal will be collectively referred to as an "eUICC". In addition, SIM module information to be downloaded will be collectively referred to as an "eUICC profile".

A prior art of <CIT> describes a method where a terminal of an eUICC) may initiate a request for downloading a profile of an operator, and the operator does not need to know an identity of the eUICC in advance; a range of objects that can download the profile of the operator may be extended to all eUICCs, and an end user may freely select an opportunity for downloading the profile of the operator.

Aspects of the invention are a method and an apparatus in which a terminal selects a public key identifier for a communication connection in a communication system.

In order to solve the above problems, a method for performing an authentication procedure by a terminal in a wireless communication system is defined as per the appended claims.

In order to solve the above problems, a terminal is defined, as per the appended claims.

The technical subjects pursued in the disclosure may not be limited to the above mentioned technical subjects, and other technical subjects which are not mentioned may be clearly understood, through the following descriptions, by those skilled in the art of the disclosure.

According to the disclosure, the terminal can inform the profile management server (SM-DP+) of digital certificate issuer information trusted by the terminal, and can receive a digital certificate issued by a digital certificate issuer that the terminal trusts from the profile management server (SM-DP+) in a communication system. Accordingly, the terminal and the profile management server (SM-DP+) can reduce the security threat during a mutual authentication process using a digital certificate issued by a specific digital certificate issuer during the mutual authentication.

In describing the exemplary embodiments of the disclosure, descriptions related to technical contents which are well-known in the art to which the disclosure pertains, and are not directly associated with the disclosure, will be omitted.

Further, the size of each element does not entirely reflect the actual size.

The specific terms used herein are provided for ease of understanding the disclosure, and such specific terms may be changed into other forms without departing from the scope of the disclosure.

And each block of the flowchart illustrations may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing the specified logical function(s).

As used herein, the "unit" refers to a software element or a hardware element, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), which performs a predetermined function. However, the "unit does not always have a meaning limited to software or hardware. The "unit" may be constructed either to be stored in an addressable storage medium or to execute one or more processors. Therefore, the "unit" includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, properties, procedures, sub-routines, segments of a program code, drivers, firmware, micro-codes, circuits, data, database, data structures, tables, arrays, and parameters. The elements and functions provided by the "unit" may be either combined into a smaller number of elements, "unit" or divided into a larger number of elements, "unit". Moreover, the elements and "units" may be implemented to reproduce one or more CPUs within a device or a security multimedia card. Also, in an embodiment, the '~ unit' may include one or more processors.

First, terms used in this specification will be defined.

In this specification, a UICC is a smart card inserted and used in a mobile terminal and denotes a chip that stores personal information, such as network access authentication information of a mobile communication subscriber, phone books, and SMS, and performs subscriber authentication and traffic security key generation when accessing a mobile communication network, such as GSM, WCDMA, LTE, or the like, thereby enabling secure mobile communication usage. The UICC may be equipped with communication applications, such as a subscriber identification module (SIM), a universal SIM (USIM), IP multimedia SIM (ISIM), or the like, according to the type of mobile communication network accessed by the subscriber, and may provide a higher level security function for employing various applications such as an electronic wallet, ticketing, an electronic passport, and the like.

In this specification, an embedded UICC (eUICC) is a security module in the form of a chip embedded in a terminal, which cannot be inserted into and cannot be removed from the terminal. The eUICC may download and install a profile using over-the-air (OTA) technology. The eUICC may be referred to as a "UICC capable of downloading and installing a profile".

In this specification, a method of downloading and installing a profile in the eUICC using the OTA technology may also be applied to a detachable UICC that can be inserted into and removed from the terminal. That is, the embodiments of the disclosure may be applied to a UICC capable of downloading and installing a profile using the OTA technology.

In this specification, the term "UICC" may be used interchangeably with "SIM", and the term "eUICC" may be used interchangeably with "eSIM".

In this specification, a profile may denote a package of an application, a file system, an authentication key value, and the like, which are stored in the UICC, in a software form.

In this specification, a USIM Profile may have the same meaning as the profile, or may denote a package of information included in the USIM application in the profile in a software form.

In this specification, a profile provision server may have a function of producing a profile, encrypting the produced profile, producing a remote profile management instruction, or encrypting the produced remote profile management instruction, and may be referred to as 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", a "profile producing server", a "profile provisioner (PP)", a "profile provider", or a "profile provisioning credentials (PPC) holder".

In this specification, a profile management server may be referred to as a "subscription manager secure routing (SM-SR)", a "subscription manager secure routing plus (SM-SR+)", an "off-card entity of eUICC profile manager", a "profile management credentials (PMC) holder", or an "eUICC manager (EM)".

In this specification, the profile provision server may encompass the functions of the profile management server. Therefore, in various embodiments of the disclosure, that is, in the following description, the operation of the profile provision server may also be performed by the profile management server. Likewise, the operation of the profile management server or the SM-SR may also be performed by the profile provision server.

The term "terminal" as used herein may be referred to as a "mobile station (MS)", "user equipment (UE)", a "user terminal (UT)", a "wireless terminal", an "access terminal (AT)", 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. Various embodiments of the terminal may include a cellular phone, a smartphone 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, a photographing device, such as a digital camera, having a wireless communication function, a gaming device having a wireless communication function, home appliances for music storage and playback having a wireless communication function, Internet home appliances capable of wireless Internet access and browsing, a portable unit employing combinations of the above functions, or terminals thereof. In addition, the terminal may include a machine-to-machine (M2M) terminal or a machine type communication (MTC) terminal/device, but is not limited thereto. In this specification, the terminal may be referred to as an "electronic device".

In this specification, the electronic device may include an embedded UICC capable of downloading and installing a profile. In the case where the UICC is not embedded in the electronic device, a UICC physically separated from the electronic device may be inserted into the electronic device, thereby connecting to the electronic device. For example, the UICC in the form of a card may be inserted into the electronic device. The electronic device may include the terminal, and in this case, the terminal may be a terminal including a UICC capable of downloading and installing a profile. The UICC may be embedded in the terminal, and in the case where the terminal and the UICC are separate from each other, the UICC may be inserted into the terminal to then be connected to the terminal. The UICC capable of downloading and installing a profile may be called, for example, an "eUICC".

In this specification, the terminal or the electronic device may include software or an application installed in the terminal or the electronic device so as to control the UICC or the eUICC. The software or the application may, for example, be referred to as a "local profile assistant (LPA)".

In this specification, a profile identifier may be referred to as a "profile ID", an "integrated circuit card ID (ICCID)", a "matching ID", an "event identifier (ID)", an "activation code", an "activation code token", or a "factor matching ISD-P or a profile domain (PD)". The profile ID may indicate a unique identifier of each profile. The profile identifier may include an address of a profile provision server (SM-DP+) capable of indexing profiles.

In this specification, an eUICC identifier (eUICC ID) may be a unique identifier of the eUICC embedded in the terminal, and may be referred to as an "EID". In addition, in the case where the eUICC is equipped with a provisioning profile, the eUICC identifier may be a profile ID of the corresponding provisioning profile. In addition, in the case where the terminal and the eUICC chip are not separate as in the embodiment of the disclosure, the eUICC identifier may be a terminal ID. In addition, the eUICC identifier may denote a specific secure domain of the eUICC chip.

In this specification, a profile container may be referred to as a "profile domain". The profile container may be a security domain.

In this specification, an application protocol data unit (APDU) may be a message by which the terminal interworks with the eUICC. In addition, the APDU may be a message by which a PP or a PM interworks with the eUICC.

In this specification, profile provisioning credentials (PPC) may be a means used in mutual authentication, profile encryption, and signature between the profile provision server and the eUICC. The PPC may include at least one of a symmetric key, a Rivest Shamir Adleman (RSA) certificate and a private key, an elliptic curved cryptography (ECC) certificate and a private key, a root certification authority (CA), and a certificate chain. In addition, if there is a plurality of profile provision servers, different PPCs may be stored in the eUICC or used for the respective profile provision servers.

In this specification, profile management credentials (PMC) may be a means used in mutual authentication, transmission data encryption, and signature between the profile management server and the eUICC. The PMC may include at least one 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. In addition, if there is a plurality of profile management servers, different PMCs may be stored in the eUICC or used for the respective profile management servers.

In this specification, an AID may be an application identifier. This value may be an identifier for distinguishing between different applications in the eUICC.

In this specification, an event may denote profile download, remote profile management, or management/processing instructions of other profiles or the eUICC. "Profile download" may be used interchangeably with "profile installation". In addition, an event type may be used to indicate whether a specific event is profile download, remote profile management, or a management/processing command of other profiles or the eUICC, and may be referred to as an "operation type (or operationtype)", an "operation class (or operationclass)", an "event request type", an "event class", an "event request class", or the like.

In this specification, a "profile package" may be used interchangeably with a "profile", or may be used as a term indicating a data object of a specific profile, and may be referred to as a "profile TLV" or a "profile package TLV". In the case where a profile package is encrypted using encryption parameters, the profile package may be referred to as a "protected profile package (PPP)" or a "protected profile package TLV (PPP TLV)". In the case where a profile package is encrypted using encryption parameters that can be decrypted only by a specific eUICC, the profile package may be referred to as a "bound profile package (BPP)" or a "bound profile package TLV (BPP TLV)". The profile package TLV may be a data set representing information constituting the profile in a TLV (tag, length, and value) format.

In this specification, remote profile management (RPM) may be referred to as "remote profile management", "remote management", a "remote management command", a "remote command", a "remote profile management (RPM) package", a "remote profile management package", a "remote management package", a "remote management command package", or a "remote command package". The RPM may be used to change the status of a specific profile (enabled, disabled, or deleted) or update the content of a specific profile (e.g., a profile nickname, profile metadata, or the like). The RPM may include one or more remote management commands, and in this case, the profiles, which are targets of the respective remote management commands, may be the same or different depending on the remote management commands.

In this specification, a certificate or a digital certificate may denote a digital certificate used for mutual authentication based on an asymmetric key including a pair of a public key (PK) and a secret key (SK). Each certificate may include one or more public keys (PKs), public key identifiers (PKIDs) corresponding to the respective public keys, an identifier of a certificate issuer (CI) who issued the certificate (a certificate issuer ID), and a digital signature thereof. In addition, the certificate issuer may be referred to as a "certification issuer", a "certificate authority (CA)", a "certification authority", or the like. In this specification, the public key (PK) and the public key ID (PKID) may denote a specific public key or a certificate containing the corresponding public key, a portion of a specific public key or a portion of a certificate containing the corresponding public key, an operation result value of a specific public key (e.g., hash) or an operation result value of a certificate containing the corresponding public key (e.g., hash), an operation result value of a portion of a specific public key (e.g., hash) or an operation result value of a portion of a certificate containing the corresponding public key (e.g., hash), or a storage space storing the above data, and may be used interchangeably therewith.

In this specification, if certificates issued by a single certificate issuer (primary certificates) are used to issue other certificates (secondary certificates), or if the secondary certificates are successively used to issue third or more certificates, the correlation of the certificates may be referred to as a "certificate chain" or a "certificate hierarchy". In this case, the CI certificate used in initial certificate issuance may be referred to as a "root of certificate", a "highest certificate", a "root CI", a "root CI certificate, a "root CA", a "root CA certificate", or the like.

In this specification, AKA may indicate authentication and key agreement, and may represent an authentication algorithm for accessing 3GPP and 3GPP2 networks.

In this specification, "K" is an encryption key value stored in the eUICC, which is used in the AKA authentication algorithm.

In this specification, "OPc" is a parameter value that may be stored in the eUICC, which is used in the AKA authentication algorithm.

In this specification, an "NAA" is a network access application, and may be an application program such as USIM or ISIM stored in the UICC and accessing a network. The NAA may be a network access module.

In describing the disclosure, a detailed description of related known functions or configurations, which may unnecessarily obscure the subject matter of the disclosure, will be omitted.

<FIG> is a diagram <NUM> illustrating a method of connecting a terminal to a mobile communication network using a UICC equipped with a profile fixed to the terminal.

Referring to <FIG>, a UICC <NUM> may be inserted into a terminal <NUM>. In this case, the UICC may be detachable, or may be embedded in the terminal. The fixed profile of the UICC equipped with the fixed profile denotes that "access information" for accessing a specific communication provider is fixed. The access information may be, for example, an IMSI, which is a subscriber identifier, and a value "K" or "Ki" necessary for authentication in access to the network together with the subscriber identifier.

Then, the terminal may perform authentication with an authentication processing system {e.g., a home location register (HLR) or AuC) of a mobile communication provider using the UICC. The authentication process may be an authentication and key agreement (AKA) process. If authentication is successful, the terminal may use mobile communication services, such as a phone call or usage of mobile data using the mobile communication network <NUM> of the mobile communication system.

<FIG> is a diagram <NUM> illustrating an example of a hierarchy of certificate (or a certificate chain) issued by a certificate issuer (CI) and an example of configuration of a public key and a digital signature of a certificate issuer (CI), which are included in each certificate.

Referring to <FIG>, the certificate issuer (CI) may produce a public key and a secret key to be used by the certificate issuer, may produce a certificate issuer (CI) certificate <NUM> by including the public key <NUM>, among the above keys, in its own certificate, and may attach, to the certificate, a digital signature <NUM> produced using its own secret key with respect to the certificate.

In addition, referring to <FIG>, the CI certificate <NUM> may be used to issue a certificate <NUM> of Object <NUM> (see <NUM>). Object <NUM> may be, for example, a profile management server (SM-DP+). Object <NUM> may produce a public key and a secret key to be used by itself, may produce a certificate <NUM> of Object <NUM> by including the public key <NUM>, among the keys, in its own certificate, and may make a request to the certificate issuer, thereby receiving certificate issuer (CI) digital signature <NUM> using the certificate issuer (CI) secret key. In this case, the certificate <NUM> of Object <NUM> may include a certificate issuer (CI) public key identifier (ID) (CI PKID) <NUM> corresponding to the certificate issuer (CI) public key <NUM>, which is to be used when checking the certificate issuer signature <NUM> contained in the corresponding certificate.

In addition, referring to <FIG>, the CI certificate <NUM> may be used to issue a certificate <NUM> of Object <NUM> (see <NUM>). Object <NUM> may be, for example, an eUICC manufacturer (EUM). Object <NUM> may produce a public key and a secret key to be used by itself, may produce a certificate <NUM> of Object <NUM> by including the public key <NUM>, among the above keys, in its own certificate, and may make a request to the certificate issuer, thereby receiving a certificate issuer (CI) digital signature <NUM> using the certificate issuer (CI) secret key. In this case, the certificate <NUM> of Object <NUM> may include a certificate issuer (CI) public key identifier (ID) (CI PKID) <NUM> corresponding to the certificate issuer (CI) public key <NUM>, which is to be used when checking the certificate issuer signature <NUM> included in the corresponding certificate. The certificate issuer signatures <NUM> and <NUM> contained in the certificate <NUM> of Object <NUM> and the certificate <NUM> of Object <NUM> may have different values from each other, but the certificate issuer public key identifiers (CI PKIDs) <NUM> have the same value.

In addition, referring to <FIG>, the certificate <NUM> of Object <NUM> may be used to issue a certificate <NUM> of Object <NUM> (see <NUM>). Object <NUM> may be, for example, an eUICC manufactured by an eUICC manufacturer (EUM). Object <NUM> may produce a public key and a secret key to be used by itself, may produce a certificate <NUM> of Object <NUM> by including the public key <NUM>, among the above keys, in its own certificate, and may make a request to Object <NUM>, thereby receiving a digital signature <NUM> of Object <NUM> using the secret key of Object <NUM>. In this case, the certificate <NUM> of Object <NUM> may include a public key identifier (ID) (CI PKID) <NUM> corresponding to the public key <NUM> of Object <NUM>, which is to be used when checking the signature <NUM> of Object <NUM> contained in the corresponding certificate.

The certificate <NUM> of Object <NUM>, the certificate <NUM> of Object <NUM>, and the certificate <NUM> of Object <NUM> illustrated in the example of <FIG> all have the same CI certificate <NUM> as the highest certificate or the root of certificate. Therefore, Object <NUM>, Object <NUM>, and Object <NUM> require the CI certificate <NUM> or the CI public key <NUM> contained therein in order to authenticate each other. More specifically, in the example of <FIG>, in order for Object <NUM> and Object <NUM> to authenticate each other using digital certificates and signatures, Object <NUM> requires the signature of Object <NUM>, the certificate <NUM> of Object <NUM>, and the CI public key <NUM>, and Object <NUM> requires the signature of Object <NUM>, the certificate <NUM> of Object <NUM>, and the CI public key <NUM>.

In addition, in the example of <FIG>, in order for Object <NUM> and Object <NUM> to authenticate each other using digital certificates and signature, Object <NUM> requires the signature of Object <NUM>, the certificate <NUM> of Object <NUM>, the certificate <NUM> of Object <NUM>, and the CI public key <NUM>, and Object <NUM> requires the signature of Object <NUM>, the certificate <NUM> of Object <NUM>, and the CI public key <NUM>. In this case, the certificate <NUM> of Object <NUM> with respect to the certificate <NUM> of Object <NUM> may be referred to as a "sub-certificate issuer (sub CI) certificate" or a "sub-certificate authority (sub CA) certificate".

<FIG> is a diagram <NUM> illustrating a mutual authentication procedure between a server <NUM> and a terminal <NUM>.

In <FIG>, the server <NUM> may be, for example, a profile management server (SM-DP+) or a service discovery server (SM-DS). In addition, in <FIG>, the terminal <NUM> may include software for controlling an eUICC {local profile assistant (LPA)} <NUM> and an eUICC <NUM>. In addition, in <FIG>, each of the server <NUM>, the LPA <NUM>, and the eUICC <NUM> may store one or more digital certificates.

Referring to <FIG>, the LPA <NUM> may check a list of all CI public keys (CI PKIDs) supported by the eUICC <NUM> in step <NUM>. More specifically, in step <NUM>, the LPA <NUM> and the eUICC <NUM> may identify eUICC information using an eUICC information request (Get eUICC Info request) message and an eUICC information response (Get eUICC Info response) message. The eUICC information response message may include eUICC information, which is referred to as "euicclnfo1", "euicclnfo", or the like. The eUICC information may include a list of all CI PKIDs supported by the eUICC <NUM>.

In step <NUM>, the LPA <NUM> and the server <NUM> may estimate a TLS connection. The TLS connection in step <NUM> may be performed using a server authentication method, among TLS connection methods, in which the LPA <NUM> verifies the identity of the server <NUM>. When the LPA <NUM> identifies the identity of the server <NUM> during the TLS connection in step <NUM>, the server <NUM> may submit a TLS certificate to the LPA <NUM>. The LPA <NUM> or the terminal <NUM> may store one or more CI PKIDs for validating the TLS certificate. If one or more sub-CI certificates are required for validating the TLS certificate of the server <NUM> using the CI PKID, the server <NUM> may submit one or more sub-CI certificates to the LPA <NUM> together with the TLS certificate in step <NUM>. After the TLS connection is established, all messages between the LPA <NUM> and the server <NUM> may be protected by the TLS security procedure.

In operation <NUM>, the LPA <NUM> may make a request to the server <NUM> for initiating mutual authentication. The initiation of mutual authentication may be performed using an initiate authentication request message. The initiate authentication request message in step <NUM> may include all CI PKIDs supported by the eUICC <NUM>, based on the information (euiccInfo1) of the eUICC <NUM> identified by the LPA <NUM> in step <NUM>.

In operation <NUM>, the server <NUM> may respond to the LPA <NUM> with initiation of the mutual authentication. The mutual authentication response may use an initiate authentication response message. The initiate authentication response message in step <NUM> may include one CI PKID selected from the list of CI PKIDs included in the information (euiccInfo1) of the eUICC <NUM> received by the server <NUM> in step <NUM>, a server certificate capable of verifying the validity using the corresponding CI PKID, and a digital signature of the server <NUM> capable of verifying the validity using the corresponding server certificate. In this case, the CI PKID selected by the server <NUM> may be referred to as an "eUICC CI PKID to be used by the eUICC". In addition, if one or more sub-CI certificates are required to determine validity of the server <NUM> using the selected CI PKID, the initiate authentication response message in step <NUM> may include one or more sub-CI certificates together with the server certificate. The certificate of the server <NUM> transmitted in step <NUM> may be different from the TLS certificate of the server <NUM> transmitted in step <NUM>. In addition, the CI that issues the certificate of the server <NUM> transmitted in step <NUM> and the CI that issues the TLS certificate of the server <NUM> transmitted in step <NUM> may be the same or different.

In operation <NUM>, the LPA <NUM> may make a request to the eUICC <NUM> for authentication of the server. The authentication request may be performed using an authenticate server request message. The authenticate server request message in step <NUM>, like the message received by the LPA <NUM> in step <NUM>, may include a CI PKID that the server selects and transmits, a server certificate capable of verifying the validity using the corresponding CI PKID, one or more sub-CI certificates necessary for the verification of the validity, and a digital signature of the server <NUM> capable of verifying the validity using the server certificate. In addition, the authenticate server request message in step <NUM> is information additionally produced by the LPA <NUM>, and may include information about the operation type that the terminal intends to perform.

In step <NUM>, the eUICC <NUM> may transmit a server authentication result to the LPA <NUM> in reply. The authentication result may be transmitted using an authenticate server response message. The authenticate server response message in step <NUM> may include a validity verification result with respect to the digital signature of the server <NUM> received by the eUICC <NUM> in step <NUM>, a CI PKID that the server <NUM> selects and transmits, an eUICC certificate capable of verifying the validity using the corresponding CI PKID, one or more sub-CI certificates necessary for the verification of the validity, a digital signature of the eUICC <NUM> capable of verifying the validity using the eUICC certificate, and information about the operation type that the terminal intends to perform.

In operation <NUM>, the LPA <NUM> may make a request to the server <NUM> for authentication of the terminal. The authentication request of the terminal may be performed using an authenticate client request message. The authenticate client request message in step <NUM> may include information received by the LPA <NUM> from the eUICC <NUM> in step <NUM>.

In operation <NUM>, the server <NUM> may transmit an authentication result of the terminal in reply. The authentication result may be transmitted using an authenticate client response message. The authenticate client response message in step <NUM> may include a validity verification result with respect to the digital signature of the eUICC <NUM> received by the server <NUM> in step <NUM> and the information on an event or event summary corresponding to the operation type to be performed by the terminal <NUM>.

In step <NUM>, the terminal <NUM> may install a profile or perform remote management of a profile according to the content of the event received in step <NUM>.

According to the mutual authentication procedure between the server <NUM> and the terminal <NUM> shown in <FIG>, since the terminal <NUM> verifies the server certificate using all CI PKIDs pre-stored in the eUICC <NUM>, it is difficult to limit a connection to the server <NUM> having a server certificate belonging to a certificate hierarchy of a specific CI certificate.

<FIG> is a diagram <NUM> illustrating a procedure of identifying a server <NUM> having a server certificate belonging to a certificate hierarchy of a specific CI certificate when performing mutual authentication between the server <NUM> and a terminal <NUM> according to an embodiment of the disclosure.

In <FIG>, a description of the server <NUM>, the LPA <NUM>, the eUICC <NUM>, and the terminal <NUM> refers to the description made with reference to <FIG>.

Referring to <FIG>, as a method for restricting the certificate of the server <NUM> to the certificate belonging to a certificate hierarchy of a specific CI certificate when performing mutual authentication later, the LPA <NUM> may acquire public key identifier (CI PKID) information of the corresponding CI certificate in step <NUM>. The LPA <NUM> may acquire the corresponding CI PKID information by the following methods, but the method is not necessarily limited thereto.

In step <NUM>, the LPA <NUM> may check whether or not the eUICC <NUM> is able to support the corresponding CI PKID in relation to the CI PKID information acquired in step <NUM>. The operation of the terminal <NUM> in step <NUM> will be described in more detail with reference to <FIG>.

In operation <NUM>, the LPA <NUM> and the server <NUM> may perform a TLS connection. The TLS connection in step <NUM> may be performed using a server authentication method in which the LPA <NUM> identifies the identity of the server <NUM>, among TLS connection methods. When the LPA <NUM> identifies the identity of the server <NUM> in the TLS connection process in step <NUM>, the server <NUM> may submit a TLS certificate to the LPA <NUM>. The LPA <NUM> or the terminal <NUM> may include one or more CI PKIDs for verifying the validity of the TLS certificate. If one or more sub-CI certificates are required for verifying the validity of the TLS certificate of the server <NUM> using the CI PKID, the server <NUM> may submit one or more sub-CI certificates to the LPA <NUM> together with the TLS certificate in step <NUM>. In step <NUM>, compared with step <NUM> described in <FIG>, the terminal <NUM> may further check whether or not it is possible to verify the certificate of the TLS certificate and the sub-CI certificates, which are submitted by the server, using the CI PKID identified in step <NUM>. After the TLS connection is established, all messages between the LPA <NUM> and the server <NUM> may be protected by the TLS security procedure.

In operation <NUM>, the LPA <NUM> may make a request to the server <NUM> for initiating mutual authentication. The initiation of mutual authentication may be performed using an initiate authentication request message. The initiate authentication request message in step <NUM>, compared with step <NUM> described in <FIG>, may include a CI PKID that the LPA <NUM> acquires in step <NUM>. In addition, the initiate authentication request message in step <NUM>, compared with step <NUM> described in <FIG>, may include a CI PKID that is identified to be supported by the eUICC through the eUICC in step <NUM>.

In operation <NUM>, the server <NUM> may respond to the LPA <NUM> with initiation of mutual authentication. The mutual authentication response may be performed using an initiate authentication response message. The initiate authentication response message in step <NUM> may include the CI PKID received by the server <NUM> in step <NUM>, a server certificate capable of verifying the validity using the corresponding CI PKID, and a digital signature of the server <NUM> capable of verifying the validity using the corresponding server certificate. In this case, the transmitted CI PKID may be referred to as an "eUICC CI PKID to be used by the eUICC". In addition, if one or more sub-CI certificates are required to determine the validity of the server <NUM> using the corresponding CI PKID, the initiate authentication response message in step <NUM> may include one or more sub-CI certificates together with the server certificate. The certificate of the server <NUM> transmitted in step <NUM> may be different from the TLS certificate of the server <NUM> transmitted in step <NUM>. In addition, the CI that issues the certificate of the server <NUM> transmitted in step <NUM> and the CI that issues the TLS certificate of the server <NUM> transmitted in step <NUM> may be the same or different. In addition, the LPA <NUM> may compare the CI PKID transmitted by the server <NUM> in step <NUM> with the CI PKID transmitted by the LPA <NUM> in step <NUM>. If the CI PKID transmitted by the server <NUM> is different from the CI PKID transmitted by the LPA <NUM> in step <NUM>, the LPA <NUM> may terminate the communication.

In operation <NUM>, the LPA <NUM> may make a request to the eUICC <NUM> for authentication of the server. The authentication request may be performed using an authenticate server request message. The authenticate server request message in step <NUM>, like the message received by the LPA <NUM> in step <NUM>, may include a CI PKID transmitted by the server <NUM>, a server certificate capable of verifying the validity using the corresponding CI PKID, one or more sub-CI certificates necessary for the verification of the validity, and a digital signature of the server <NUM> capable of verifying the validity using the server certificate. In addition, the authenticate server request message in step <NUM> is information additionally produced by the LPA <NUM>, and may include information about the operation type that the terminal intends to perform. The eUICC <NUM> that has received the message in step <NUM> may verify the validity of the certificates included in the message in step <NUM>, and may verify the digital signature of the server <NUM> using the corresponding certificates. In this case, the eUICC <NUM> may further check whether or not the eUICC <NUM> is able to support the CI PKID included in the message in step <NUM> and/or whether or not the CI PKID is available. If the CI PKID transmitted by the server <NUM> cannot be supported or if the CI PKID is not available, the eUICC <NUM> may terminate the communication.

In step <NUM>, the eUICC <NUM> may transmit a server authentication result to the LPA <NUM> in reply. The authentication result may be transmitted using an authenticate server response message. The authenticate server response message in step <NUM> may include the validity verification result with respect to the digital signature of the server <NUM> received by the eUICC <NUM> in step <NUM>, a CI PKID transmitted by the server <NUM>, an eUICC certificate capable of verifying the validity using the corresponding CI PKID, one or more sub-CI certificates necessary for the verification of the validity, a digital signature of the eUICC <NUM> capable of verifying the validity using the eUICC certificate, and information about the operation type that the terminal intends to perform.

A description of the subsequent operations in steps <NUM> to <NUM> refers to the description of the operations in steps <NUM> to <NUM> in <FIG>.

According to the mutual authentication procedure between the server <NUM> and the terminal <NUM> shown in <FIG>, since the terminal <NUM> verifies the server certificate using a specific CI PKID input in step <NUM>, it is possible to limit a connection to the server <NUM> having a server certificate belonging to a certificate hierarchy of a specific CI certificate.

<FIG> is a diagram <NUM> illustrating the operations of the LPA <NUM> and the eUICC <NUM> in detail in relation to the operation in step <NUM> described in <FIG>.

In <FIG>, a description of the LPA <NUM>, the eUICC <NUM>, and the terminal <NUM> refers to the description made with reference to <FIG>.

Referring to <FIG>, the LPA <NUM> may acquire CI PKID information as in step <NUM> of <FIG>. A detailed description of step <NUM> refers to the description made with reference to <FIG>. Thereafter, the terminal <NUM> may check whether or not the eUICC <NUM> is able to support the corresponding CI PKID in the following manner.

As an example <NUM>, the LPA <NUM> may compare the CI PKID information acquired in step <NUM> with eUICC information (euiccInfo1 or euicclnfo) temporarily cached in the LPA <NUM> in step <NUM>. More specifically, in the case where the LPA <NUM> caches the eUICC information (euicclnfo1 or euicclnfo) identified by the method as described in step <NUM> of <FIG> in a temporary storage before step <NUM>, the LPA <NUM> may compare a list of all CI PKIDs supported by the eUICC, which are included in the temporary storage, with the CI PKID information acquired in step <NUM>. As a result of the comparison, if it is determined that the eUICC <NUM> does not support the CI PKID acquired in step <NUM>, the LPA <NUM> may terminate communication.

As another example <NUM>, in steps <NUM> to <NUM>, the LPA <NUM> may transmit a message to the eUICC (<NUM>) to identify a list of CI PKIDs supported by the eUICC (<NUM>), and may compare the same with the CI PKID in step <NUM>. More specifically, the LPA <NUM> may transmit an information request message to the eUICC <NUM> in step <NUM> after step <NUM>. The message in step <NUM> may be referred to as a "Get eUICC info request message", a "Get eUICC challenge request message", an "authenticate server request message", or the like. In addition, the message in step <NUM> may include an identifier of the profile (a profile ID, an ICCID, or an AID) to be the target of the remote profile management in the future. In step <NUM>, the eUICC <NUM> may retrieve CI PKID information from the profile corresponding to the profile identifier received in step <NUM>, or may acquire all CI PKID information supported by the eUICC <NUM>, thereby transmitting, to the LPA <NUM>, the corresponding CI PKID information together with the eUICC information (euiccInfo1 or euiccInfo). The message in step <NUM> may be referred to as a "Get eUICC info response message", a "Get eUICC challenge response message", or an "authenticate server response message". Thereafter, in step <NUM>, the LPA <NUM> may compare the response of the eUICC <NUM> received in step <NUM> with the CI PKID acquired in step <NUM>. As a result of the comparison, if it is determined that the eUICC <NUM> does not support the CI PKID acquired in step <NUM>, the LPA <NUM> may terminate communication.

As another example <NUM>, in steps <NUM> to <NUM>, the LPA <NUM> may transmit a message to the eUICC <NUM>, thereby making a request for checking whether or not the eUICC <NUM> supports the CI PKID in step <NUM>. More specifically, the LPA <NUM> may transmit a checking request message to the eUICC <NUM> in step <NUM> after step <NUM>. The message in step <NUM> may be referred to as a "Get eUICC info request message", a "Get eUICC challenge request message", or an "authenticate server request message". In addition, the message in step <NUM> may include the CI PKID information in step <NUM> for making a request for checking whether or not the eUICC <NUM> supports, and may further include an identifier of the profile (a profile ID, an ICCID, or an AID) to be the target of the remote profile management in the future. In this regard, in step <NUM>, the eUICC <NUM> may compare the CI PKID information in step <NUM>, which is received in step <NUM>, with a list of CI PKIDs supported by the eUICC <NUM>, or may compare CI PKID information retrieved from the profile corresponding to the corresponding profile identifier received in step <NUM> with a list of CI PKIDs supported by the eUICC <NUM>, thereby identifying whether or not the eUICC <NUM> supports the corresponding CI PKID. If the eUICC does not support the corresponding CI PKID, the eUICC <NUM> may transmit a specific error code in reply, and may terminate communication. In step <NUM>, the eUICC <NUM> may transmit, to the LPA <NUM>, a checking response message including at least one of information on whether or not the corresponding CI PKID is supported, the corresponding CI PKID information, eUICC information (euicclnfo1 or euicclnfo), and an eUICC random challenge. The message in step <NUM> may be referred to as a "Get eUICC info response message", a "Get eUICC challenge response message", or an "authenticate server response message". If the eUICC <NUM> transmits an error code indicating that the CI PKID is not supported in reply, the LPA <NUM> may terminate the communication.

<FIG> is a diagram illustrating the structure <NUM> of a terminal according to an embodiment of the disclosure.

Referring to <FIG>, the terminal may include a transceiver <NUM>, a controller <NUM>, and a storage unit <NUM>. In the disclosure, the controller may be defined as a circuit, an application-specific integrated circuit, or at least one processor. In addition, although not shown explicitly in <FIG>, the terminal may further include an eUICC, and the eUICC may be inserted into or embedded in the terminal.

The transceiver <NUM> may transmit and receive signals to and from other network entities. For example, the transceiver <NUM> may transmit, to the profile management server, digital certificate issuer information trusted by the terminal and a random character string (nonce or random challenge) that the profile management server (SM-DP+) uses when producing a signature for self-authentication, or may receive, from the profile management server, a signature of the profile management server, one or more digital certificates to be used to verify the signature of the profile management server, and a random character string that the eUICC in the terminal uses when producing a signature for self-authentication.

In addition, the transceiver <NUM> may transmit a signature of the eUICC and one or more digital certificates to be used to verify the signature of the eUICC. In addition, the transceiver <NUM> may further transmit information on the operation type that the terminal intends to perform to the profile management server, or may receive some or all of information on an operation to be performed by the terminal from the profile management server. However, the transceiver <NUM> may selectively transmit information on the operation type that the terminal intends to perform.

The controller <NUM> may control the overall operation of the terminal according to the embodiment proposed by the disclosure. For example, the controller <NUM> may control signal flow between blocks so as to perform the operations according to the flowcharts described above.

More specifically, the controller <NUM> may identify digital certificate issuer information to be trusted by the terminal with reference to the eUICC in the terminal, may verify the validity of a digital certificate and digital certificate issuer information transmitted by the profile management server, may identify a signature of the profile management server, and may produce a signature of the eUICC. In addition, the controller <NUM> may perform an operation of installing or managing a profile according to the information received from the profile management server.

In addition, the controller <NUM> may control the operation of the transceiver or the storage unit.

The storage unit <NUM> may store at least one piece of information transmitted and received through the transceiver <NUM> and information produced through the controller <NUM>.

In addition, the terminal of the disclosure may further include an input unit for receiving digital certificate issuer information to be trusted by the terminal. However, in the case where the input unit is not provided, the terminal may receive the digital certificate issuer information from a server or a network, may refer to information pre-stored in the terminal, or may receive the digital certificate issuer information from a third-party software in the terminal. In the case of receiving the digital certificate issuer information from the third-party software, the third-party software may pre-store digital certificate issuer information to be trusted by the terminal, or may receive the same from a server or a network.

<FIG> is a diagram illustrating the structure <NUM> of a server according to an embodiment of the disclosure.

Referring to <FIG>, the server may include a transceiver <NUM>, a controller <NUM>, and a storage unit <NUM>. In the disclosure, the controller may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

The transceiver <NUM> may transmit and receive signals to and from other network entities. For example, the transceiver <NUM> may receive, from a terminal, digital certificate issuer information trusted by the terminal and a random character string (nonce or random challenge) that the profile management server uses when producing a signature for self-authentication.

In addition, the transceiver <NUM> may transmit, to the terminal, a signature of the profile management server, one or more digital certificates to be used to verify the signature of the profile management server, and a random character string that the eUICC in the terminal uses when producing a signature for self-authentication, and may receive a signature of the eUICC and one or more digital certificates to be used to verify the signature of the eUICC. In addition, the transceiver <NUM> may further receive information on the operation type that the terminal intends to perform from the terminal. However, the information on the operation type that the terminal intends to perform may be selectively transmitted.

In addition, the transceiver <NUM> may transmit, to the terminal, some of all of information on the operation to be performed by the terminal.

The controller <NUM> may control the overall operation of the terminal according to the embodiment proposed by the disclosure. For example, the controller <NUM> may control a signal flow between blocks so as to perform the operations according to the flowcharts described above.

More specifically, the controller <NUM> may verify whether or not digital certificate issuer information trusted by the terminal is valid, may determine whether or not the server is also able to trust the digital certificate issuer trusted by the terminal, may select a digital certificate corresponding to digital certificate issuer information trusted by the terminal, and may produce a signature of the profile management server.

In addition, the controller <NUM> may verify the validity of a digital certificate transmitted by the terminal, may identify a signature of the eUICC, and may determine the operation type to be performed by the terminal.

Claim 1:
A method performed by a terminal (<NUM>, <NUM>) including a universal integrated circuit card (<NUM>), UICC, in a wireless communication system, the method comprising:
obtaining (<NUM>) a first certificate issuer, CI, public key identifier;
obtaining (<NUM>), from the UICC (<NUM>), UICC information including a list of the public key identifiers supported by the UICC;
comparing (<NUM>) the list of the public key identifiers supported by the UICC with the first CI public key identifier;
determining that the first CI public key identifier matches with a public key identifier of the list of the public key identifiers, and
transmitting (<NUM>), to a server (<NUM>, <NUM>), a first message for initiating an authentication, the first message including a matching public key identifier,
wherein the first CI public key identifier is obtained by receiving a user input with respect to the terminal, retrieving information stored in the UICC, receiving an activation code, or receiving a command code.