Method and apparatus for discussing digital certificates by esim terminal and server

Abstract

The disclosure relates to a communication technology for converging IoT technology with a 5G communication system for supporting a higher data transmission rate beyond a 4G system. The disclosure can be applied to intelligent services based on the 5G communication technology and the IoT-related technology. A method performed by a terminal including a universal integrated circuit card (UICC) in a wireless communication system is disclosed. The method includes identifying a first certificate issuer (CI) public key identifier, obtaining, from the UICC, UICC information including a list of public key identifiers supported by the UICC, obtaining a new list based on the list of public key identifiers supported by the UICC, wherein the new list includes at least one public key identifier from the list of public key identifiers supported by the UICC, except for a public key identifier that does not match the first CI public key identifier, and transmitting, to a server, a first message for initiating authentication, the first message including the new list.

Description

[0001] This application is a divisional application of the application filed on June 26, 2018, with application number 201880045001.4, entitled "Method and apparatus for discussing digital certificates by an ESIM terminal and a server". Technical Field

[0002] This disclosure relates to a method and apparatus for establishing a communication connection in a communication system by downloading and installing communication services via a terminal. This disclosure also relates to a method and apparatus for online downloading, installation, and management of files in a communication system. Background Technology

[0003] To meet the increasing demand for wireless data traffic since the commercialization of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as super 4G network communication systems or post-LTE systems.

[0004] To achieve higher data transmission rates, 5G communication systems are being considered for implementation in millimeter-wave bands (e.g., the 60 GHz band). In 5G communication systems, technologies such as beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO are discussed as means to reduce propagation path loss and increase transmission distance in the millimeter-wave band.

[0005] In addition, 5G communication systems have developed technologies such as evolved small cells, advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device communication (D2D), wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), and receive interference cancellation to improve system networks.

[0006] In addition, 5G systems have developed advanced coding and modulation (ACM) schemes such as hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC), as well as advanced access technologies such as filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA).

[0007] Meanwhile, the internet has evolved from a human-centric network where humans generate and consume information to the Internet of Things (IoT), in which distributed components, such as objects, exchange and process information. The Internet of Everything (IoE) technology has emerged, combining big data processing technologies with IoT technologies through connections to cloud servers and other systems. To realize IoT, technological elements such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology are required, and recent research has focused on technologies such as sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC). In the IoT environment, by collecting and analyzing data generated between connected objects, intelligent internet of things (IT) services can be provided to create new value for human life. Through the integration of traditional information technology (IT) with various industries, IoT can be applied to fields such as smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances, and high-tech medical services.

[0008] Therefore, various attempts have been made to apply 5G communication to IoT networks. For example, technologies such as sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC) are being implemented using 5G communication technologies such as beamforming, MIMO, and array antennas. Cloud RAN, as an application of big data processing technology, can be seen as an example of the integration of 5G and IoT technologies.

[0009] A Universal Integrated Circuit Card (UICC) is a smart card inserted into a mobile terminal or similar device, and is also referred to as a "UICC". A UICC may include an access control module for accessing a mobile communication provider's network. Examples of access control modules include a Universal Subscriber Identity Module (USIM), a Subscriber Identity Module (SIM), an IP Multimedia Service Identity Module (ISIM), and so on. A UICC including a USIM is often referred to as a "USIM card". Similarly, a UICC including a SIM module is often referred to as a "SIM card". In the following description of this disclosure, "SIM card" will be used to refer to the typical meaning encompassing UICC, USIM card, UICC including ISIM, etc. That is, although a SIM card is described, its technology can be equivalently applied to USIM cards, ISIM cards, or universal UICCs.

[0010] The SIM card stores the mobile communication subscriber's personal information and performs subscriber authentication and generates a service security key when accessing the mobile communication network, thereby enabling secure use of mobile communication.

[0011] At the time of this disclosure, typically during card manufacturing, the SIM card is manufactured as a dedicated card for a specific mobile communication provider, according to the request of the respective provider. The corresponding provider's authentication information for network access, such as the Universal Subscriber Identity Module (USIM) application, International Mobile Subscriber Identity (IMSI), K-value, OPC value, etc., are pre-recorded in the card before it is provided. Therefore, the manufactured SIM card is provided to the corresponding mobile communication provider, and the mobile communication provider provides the SIM card to the subscriber. Subsequently, if necessary, the UICC can be managed by installing, modifying, and deleting applications using technologies such as over-the-air (OTA). The subscriber can insert the UICC into their mobile terminal to use the network and application services of the corresponding mobile communication provider. When changing terminals, the subscriber can remove the UICC from the existing terminal and insert it into the new terminal, thus using authentication information, mobile phone number, personal phone book, etc., without any changes.

[0012] However, SIM cards are inconvenient for mobile device users when receiving services from other mobile communication providers. To receive services from a mobile communication provider, the user must physically obtain a SIM card. For example, if a user travels to another country, they must obtain a local SIM card to receive local mobile communication services. While roaming services alleviate these inconveniences to some extent, roaming service fees are very high, and roaming services require separate contracts between mobile communication providers.

[0013] Furthermore, if the SIM module can be remotely downloaded and installed in the UICC, most inconveniences can be eliminated. That is, users can download the SIM module for the mobile communication service they wish to use to the UICC at their desired time. Additionally, the UICC can download and install multiple SIM modules, and users can select and use only one of them. The UICC may or may not be fixed to the terminal. Specifically, a UICC fixed to the terminal is called an "embedded UICC (eUICC)". Generally, eUICC refers to a UICC fixed to the terminal that allows selection of the SIM module via remote download. In this disclosure, UICCs capable of remotely downloading and selecting SIM modules will be collectively referred to as "eUICC". That is, among UICCs capable of remotely downloading and selecting SIM modules, UICCs fixed to or not fixed to the terminal will be collectively referred to as "eUICC". Furthermore, the SIM module information to be downloaded will be collectively referred to as an "eUICC profile". Summary of the Invention

[0014] Technical issues

[0015] One aspect of this disclosure is to provide a method and apparatus in which a terminal selects a communication service for a communication connection in a communication system. Another aspect of this disclosure is to provide a method and apparatus in which a terminal downloads, installs, and manages a profile for a communication connection online within a communication system. Yet another aspect of this disclosure is to provide an apparatus and method for securely providing a profile to a terminal in a communication system.

[0016] Specifically, this disclosure proposes the following solutions for the aforementioned purposes.

[0017] - A method for sending trusted digital certificate issuer information to a profile management server (SM-DP+).

[0018] - A method for a simplified profile management server (SM-DP+) to send a digital certificate corresponding to the above information to the terminal as a response.

[0019] - The message exchange process between the terminal and the profile management server (SM-DP+).

[0020] Problem-solving methods

[0021] To address the aforementioned issues, a method for performing an authentication process between a terminal and a server in a wireless communication system may include: obtaining a first public key identifier of a specific Certificate Authority (CI); identifying a second public key identifier supported by the terminal's Universal Integrated Circuit Card (UICC); determining a public key identifier belonging to the first public key identifier from among the second public key identifiers supported by the terminal's UICC; and sending an authentication request message containing the determined public key identifier to a server (e.g., a profile management server SM+DP-).

[0022] The identification may include: comparing the first public key identifier with UICC information cached in the terminal, or receiving information about the second public key identifier supported by the UICC and comparing the second public key identifier with the first public key identifier, and excluding public key identifiers not included in the first public key identifier from the second public key identifiers supported by the UICC, thereby restricting the third public key identifier used in the authentication process.

[0023] The acquisition may include: obtaining the first public key identifier of the specific CI by receiving user input about the terminal, retrieving information stored in the UICC, retrieving an activation code, retrieving a command code, receiving a first public key identifier from a profile-related server, or retrieving a profile installed in the UICC.

[0024] The method may further include: receiving an authentication response message from the server, the authentication response message containing a fourth public key identifier to be used by the UICC, and terminating the authentication process if the fourth public key identifier to be used by the UICC included in the authentication response message is different from the first public key identifier, if the UICC does not support the fourth public key identifier to be used by the UICC, if the UICC does not support the first public key identifier, or if there is no public key identifier belonging to the first public key identifier among the public key identifiers supported by the UICC.

[0025] To address the aforementioned issues, a terminal according to an embodiment may include: a transceiver configured to transmit and receive signals; and a controller configured to: acquire a first public key identifier of a specific Certificate Authority (CI), identify a second public key identifier supported by the terminal's Universal Integrated Circuit Card (UICC), determine a public key identifier belonging to the first public key identifier among the second public key identifiers supported by the terminal's UICC; send an authentication request message containing the determined public key identifier to a server, and verify the public key identifier to be used by the UICC contained in a verification response message sent by the server.

[0026] To address the aforementioned issues, the method according to an embodiment may include: receiving an authentication request message containing a first public key identifier from a terminal; and sending an authentication response message containing a second public key identifier to the terminal, the second public key identifier being used by the terminal's Universal Integrated Circuit Card (UICC); wherein the first public key identifier included in the authentication request message may belong to a third public key identifier pre-acquired by the terminal among the second public key identifiers supported by the terminal's UICC.

[0027] To address the aforementioned issues, a server according to an embodiment may include: a transceiver configured to send and receive signals; and a controller configured to: receive an authentication request message containing a first public key identifier from a terminal, and send an authentication response message containing a second public key identifier to the terminal, the second public key identifier being used by the terminal's Universal Integrated Circuit Card (UICC); wherein the first public key identifier included in the authentication request message may belong to a third public key identifier pre-acquired by the terminal among the second public key identifiers supported by the terminal's UICC.

[0028] Another aspect of this disclosure provides a method performed by a terminal including a Universal Integrated Circuit Card (UICC) in a wireless communication system. The method includes: identifying a first Certificate Authority (CI) public key identifier; obtaining UICC information from the UICC, including a list of public key identifiers supported by the UICC; obtaining a new list based on the list of public key identifiers supported by the UICC, wherein the new list includes at least one public key identifier from the list of public key identifiers supported by the UICC, excluding public key identifiers that do not match the first CI public key identifier; and sending a first message to a server for initiating authentication, the first message containing the new list.

[0029] Another aspect of this disclosure provides a terminal in a wireless communication system. The terminal includes: a transceiver; a Universal Integrated Circuit Card (UICC); and a controller coupled to the transceiver and configured to: identify a first Certificate Authority (CI) public key identifier; obtain UICC information from the UICC including a list of public key identifiers supported by the UICC; obtain a new list based on the list of public key identifiers supported by the UICC, wherein the new list includes at least one public key identifier from the list of public key identifiers supported by the UICC, excluding public key identifiers that do not match the first CI public key identifier; and send a first message to a server for initiating authentication, the first message containing the new list.

[0030] Another aspect of this disclosure provides a method for execution by a server in a wireless communication system. The method includes: receiving from a terminal a first message for initiating authentication of the terminal, the first message including a list of public key identifiers matching a first certificate issuer (CI) public key identifier; and sending to the terminal a second message as a response to the first message, the second message including a second CI public key identifier to be used by the terminal's Universal Integrated Circuit Card (UICC); wherein the list includes at least one public key identifier from a list of public key identifiers supported by the terminal's UICC, excluding public key identifiers not matching the first CI public key identifier.

[0031] Another aspect of this disclosure provides a server in a wireless communication system. The server includes: a transceiver; and a controller coupled to the transceiver and configured to: receive from a terminal a first message for initiating authentication of the terminal, the first message including a list of public key identifiers matching a first certificate issuer (CI) public key identifier; and send to the terminal a second message as a response to the first message, the second message including a second CI public key identifier to be used by the terminal's Universal Integrated Circuit Card (UICC), wherein the list includes at least one public key identifier from a list of public key identifiers supported by the terminal's UICC, excluding public key identifiers not matching the first CI public key identifier.

[0032] The technical topics pursued in this disclosure may not be limited to those described above, and other technical topics not mentioned will be clearly understood by those skilled in the art through the following description.

[0033] Beneficial effects of the invention

[0034] According to embodiments of this disclosure, a terminal can notify a Profile Management Server (SM-DP+) of information about a digital certificate issuer it trusts, and can receive a digital certificate issued by that trusted issuer from the Profile Management Server (SM-DP+) in the communication system. Therefore, the terminal and the Profile Management Server (SM-DP+) can use a digital certificate issued by a specific issuer during mutual authentication to reduce security threats during the mutual authentication process. Attached Figure Description

[0035] Figure 1 This diagram illustrates a method by which a terminal connects to a mobile communication network using a UICC equipped with a fixed profile.

[0036] Figure 2 This is a diagram illustrating an example of a certificate hierarchy used for certificates issued by a specific certificate issuer.

[0037] Figure 3 This is a diagram illustrating the mutual authentication process between the server and the terminal.

[0038] Figure 4 This is a diagram illustrating the process of using certificates during the mutual authentication process between a server and a terminal, according to an embodiment.

[0039] Figure 5 This is a diagram illustrating a process, according to an embodiment, for selecting a certificate recommended by a terminal for a mutual authentication process with a server.

[0040] Figure 6This is a diagram illustrating the structure of a terminal according to an embodiment of the present disclosure.

[0041] Figure 7 This is a diagram illustrating the structure of a server according to an embodiment of the present disclosure. Detailed Implementation

[0042] In the following, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0043] In describing exemplary embodiments of this disclosure, descriptions relating to technical content known in the art to which this disclosure pertains and not directly related to this disclosure will be omitted. Such omission of unnecessary descriptions is intended to prevent obscuring the main ideas of this disclosure and to convey the main ideas more clearly.

[0044] For the same reason, some elements may be enlarged, omitted, or shown schematically in the accompanying drawings. Furthermore, the size of each element does not perfectly reflect its actual size. In the accompanying drawings, identical or corresponding elements are provided with the same reference numerals.

[0045] The specific terminology used herein is provided for ease of understanding of this disclosure, and these specific terms may be changed to other forms without departing from the spirit and scope of this disclosure.

[0046] The advantages and features of this disclosure, as well as the ways in which they are implemented, will become apparent from the embodiments described in detail below with reference to the accompanying drawings. However, this disclosure is not limited to the embodiments set forth below, but can be implemented in a variety of different forms. The following embodiments are provided only to fully disclose this disclosure and to inform those skilled in the art of its scope, and this disclosure is limited only by the scope of the appended claims.

[0047] Here, it will be understood that each box in the flowchart illustration, and combinations of boxes in the flowchart illustration, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing device, create means for implementing the functions specified in the flowchart boxes. These computer program instructions can also be stored in computer-usable or computer-readable memory that can instruct the computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-usable or computer-readable memory produce a product including instruction means that implement the functions specified in the flowchart boxes. Computer program instructions can also be loaded onto a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable device, provide steps for implementing the functions specified in the flowchart boxes.

[0048] Furthermore, each box in the flowchart can represent a module, code segment, or code section, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the boxes may occur out of order. For example, depending on the functions involved, two consecutively shown boxes may actually be executed substantially simultaneously, or sometimes they may be executed in reverse order.

[0049] As used herein, "unit" refers to a software or hardware element that performs a predetermined function, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC). However, "unit" is not always limited to software or hardware. A "unit" can be interpreted as something stored in addressable storage media or executing one or more processors. Therefore, "unit" includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and parameters. The elements and functions provided by a "unit" can be combined into a smaller number of element "units" or divided into a larger number of element "units". Furthermore, elements and "units" can be implemented as one or more CPUs within a playback device or secure multimedia card. Similarly, in embodiments, A "unit" may include one or more processors.

[0050] First, the terminology used in this specification will be defined.

[0051] In this specification, UICC is a smart card inserted and used in a mobile terminal, representing a chip used to store personal information (such as network access authentication information, phonebook, and SMS for mobile communication subscribers) and to perform subscriber authentication and service security key generation when accessing mobile communication networks such as GSM, WCDMA, and LTE, thereby enabling secure mobile communication. Depending on the type of mobile communication network accessed by the subscriber, UICC can be equipped with communication applications such as Subscriber Identity Module (SIM), Universal SIM (USIM), and IP Multimedia SIM (ISIM). It can also provide higher levels of security features for various applications such as e-wallets, ticketing, and e-passports.

[0052] In this specification, the embedded UICC (eUICC) is a chip-based security module embedded in a terminal, which cannot be inserted into or removed from the terminal. The eUICC can use over-the-air (OTA) technology to download and install its documentation. The eUICC can be referred to as a "UICC capable of downloading and installing documentation."

[0053] The method for downloading and installing profiles in an eUICC using OTA technology, as described in this specification, can also be applied to removable UICCs that can be inserted into and removed from a terminal. That is, the embodiments of this disclosure can be applied to UICCs capable of downloading and installing profiles using OTA technology.

[0054] In this specification, the term “UICC” is used interchangeably with “SIM”, and the term “eUICC” is used interchangeably with “eSIM”.

[0055] In this specification, a brief may refer to a package in software form stored in UICC, such as an application, file system, authentication key value, etc.

[0056] In this specification, a USIM profile may have the same meaning as the profile itself, or it may represent a package of information in a software form included in a USIM application within the profile.

[0057] In this specification, a profile provider server may have the functions of generating profiles, encrypting generated profiles, generating remote profile management instructions or encrypting remote profile management instructions, and may be referred to as "Subscription Manager Data Preparation (SM-DP)," "Subscription Manager Data Preparation Plus (SM-DP+)," "Off-Card Entity of Profile Domain," "Profile Encryption Server," "Profile Generation Server," "Profile Provider (PP)," "Profile Provider," or "Profile Provider Credential (PPC) Holder."

[0058] In this specification, the profile management server may be referred to as "Subscription Manager Security Router (SM-SR)", "Subscription Manager Security Router Plus (SM-SR+)", "Off-Card Entity of eUICC Profile Manager", "Profile Management Credentials (PMC) Holder" or "eUICC Manager (EM)".

[0059] In this specification, the profile providing server may include the functionality of a profile management server. Therefore, in various embodiments of this disclosure, i.e., in the following description, the operation of the profile providing server may also be performed by the profile management server. Similarly, the operation of the profile management server or the SM-SR may also be performed by the profile providing server.

[0060] As used herein, the term "terminal" may be referred to as "mobile station (MS)," "user equipment (UE)," "user terminal (UT)," "wireless terminal," "access terminal (AT)," "terminal," "subscriber unit," "subscriber station (SS)," "wireless device," "wireless communication device," "wireless transceiver unit (WTRU)," "mobile node," "mobile," or other terms. Various embodiments of a terminal may include a cellular phone, a smartphone with wireless communication capabilities, a personal digital assistant (PDA) with wireless communication capabilities, a wireless modem, a portable computer with wireless communication capabilities, a photographic device such as a digital camera with wireless communication capabilities, a gaming device with wireless communication capabilities, a home appliance with wireless communication capabilities for music storage and playback, an internet-connected home appliance capable of wireless internet access and browsing, a portable unit employing a combination of the above functions, or a terminal thereof. Additionally, a terminal may include, but is not limited to, a machine-to-machine (M2M) terminal or a machine-type communication (MTC) terminal / device. In this specification, a terminal may be referred to as an "electronic device."

[0061] In this specification, an electronic device may include an embedded UICC capable of downloading and installing a profile. If the UICC is not embedded in the electronic device, a UICC physically separate from the electronic device may be inserted into the electronic device for connection. For example, a UICC in card form may be inserted into the electronic device. The electronic device may include a 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 if the terminal and the UICC are separate from each other, the UICC may be inserted into the terminal and then connected to the terminal. A UICC capable of downloading and installing a profile may be referred to, for example, as an "eUICC".

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

[0063] In this specification, the profile identifier may be referred to as "profile ID," "Integrated Circuit Card ID (ICCID)," "Match ID," "Event Identifier (ID)," "Activation Code," "Activation Code Token," or "Factor Match ISD-P or Profile Domain (PD)." The profile ID can indicate a unique identifier for each profile. The profile identifier may include the address of the profile providing server (SM-DP+) capable of indexing the profile.

[0064] In this specification, the eUICC identifier (eUICC ID) can be a unique identifier of the eUICC embedded in the terminal, and can be referred to as "EID". Additionally, when the eUICC is equipped with a supply profile, the eUICC identifier can be the profile ID of the corresponding supply profile. Furthermore, in embodiments of this disclosure where the terminal and the eUICC chip are not separate, the eUICC identifier can be the terminal ID. Additionally, the eUICC identifier can represent a specific security domain of the eUICC chip.

[0065] In this specification, a profile container may be referred to as a "profile field". A profile container may be a security field.

[0066] In this specification, the Application Protocol Data Unit (APDU) can be a message used for communication between the terminal and the eUICC. Alternatively, the APDU can be a message used for communication between the PP or PM and the eUICC.

[0067] In this specification, a Profile Provider Credential (PPC) can be a means used for mutual authentication, profile encryption, and signing between the profile provider server and the eUICC. A PPC may include at least one of the following: a symmetric key, a Rivest Shamir Adleman (RSA) certificate and private key, an elliptic curved cryptography (ECC) certificate and private key, a root certificate authority (CA), and a certificate chain. Additionally, if multiple profile provider servers exist, different PPCs may be stored in the eUICC or used by each profile provider server.

[0068] In this specification, a Profile Management Credential (PMC) can be a means used for mutual authentication, data encryption, and signing between the profile management server and the eUICC. A PMC may include at least one of the following: a symmetric key, an RSA certificate and private key, an ECC certificate and private key, a root CA, and a certificate chain. Additionally, if multiple profile management servers exist, different PMCs may be stored in the eUICC or used on each profile management server.

[0069] In this specification, AID can be an application identifier. This value can be an identifier used to distinguish different applications in eUICC.

[0070] In this specification, an event can represent a profile download, remote profile management, or other profile or eUICC management / processing command. "Profile download" can be used interchangeably with "profile installation." Additionally, an event type can be used to indicate whether a specific event is a profile download, remote profile management, or other profile or eUICC management / processing command, and can be referred to as "operation type," "operation class," "event request type," "event class," "event request class," etc.

[0071] In this specification, "profile packet" may be used interchangeably with "profile," or it may be used as a term to indicate the data object of a specific profile, and may be referred to as "profile TLV" or "profile packet TLV." When a profile packet is encrypted using encryption parameters, it may be referred to as "protected profile packet (PPP)" or "protected profile packet TLV (PPP TLV)." When a profile packet is encrypted using encryption parameters that can only be decrypted by a specific eUICC, it may be referred to as "bound profile packet (BPP)" or "bound profile packet TLV (BPP TLV)." A profile packet TLV may be a dataset representing the information constituting the profile, expressed in TLV (label, length, and value) format.

[0072] In this specification, Remote Profile Management (RPM) may be referred to as "Remote Profile Management," "Remote Management," "Remote Management Command," "Remote Command," "Remote Profile Management (RPM) Packet," "Remote Profile Management Packet," "Remote Management Packet," "Remote Management Command Packet," or "Remote Command Packet." RPM can be used to change the status of a specific profile (enable, disable, or delete) or update the content of a specific profile (e.g., profile nickname, profile metadata, etc.). RPM may include one or more remote management commands, and in this case, the profile targeted by each remote management command may be the same or different depending on the remote management command.

[0073] In this specification, a certificate or digital certificate can refer to a digital certificate used for mutual authentication based on an asymmetric key pair including a public key (PK) and a secret key (SK). Each certificate may include one or more public keys (PK), a public key identifier (PKID) corresponding to each public key, an identifier of the certificate issuer (CI) that issued the certificate (Certificate Issuer ID), and its digital signature. Furthermore, the certificate issuer may be referred to as a "certificate issuer," "certificate authority (CA)," "certification authority," etc. In this specification, the public key (PK) and public key ID (PKID) can represent 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, the result value of an operation on a specific public key (e.g., a hash) or the result value of an operation on a certificate containing the corresponding public key (e.g., a hash), the result value of an operation on a portion of a specific public key (e.g., a hash) or the result value of an operation on a certificate containing the corresponding public key (e.g., a hash), or storage space storing the aforementioned data, and can be used interchangeably with them.

[0074] In this specification, if a certificate issued by a single certificate authority (primary certificate) is used to issue other certificates (secondary certificates), or if secondary certificates are used consecutively to issue third or more certificates, the relationship between certificates can be referred to as a "certificate chain" or "certificate hierarchy." In this case, the CI certificate used in the initial certificate issuance can be referred to as the "root certificate," "highest certificate," "root CI," "root CI certificate," "root CA," "root CA certificate," etc.

[0075] In this specification, AKA can indicate authentication and key agreement, and can represent authentication algorithms used for accessing 3GPP and 3GPP2 networks.

[0076] In this specification, "K" is the encryption key value stored in eUICC and used in the AKA authentication algorithm.

[0077] In this specification, "OPc" is a parameter value that can be stored in eUICC and used in the AKA authentication algorithm.

[0078] In this specification, "NAA" stands for Network Access Application, and can be an application such as USIM or ISIM stored in the UICC and connected to the network. NAA can also be a Network Access Module.

[0079] In describing this disclosure, detailed descriptions of related known functions or configurations that may unnecessarily obscure the subject matter of this disclosure will be omitted.

[0080] Figure 1 Figure 100 illustrates a method of connecting a terminal to a mobile communication network using a UICC equipped with a terminal-to-terminal profile.

[0081] refer to Figure 1 The UICC 120 can be inserted into the terminal 110. In this case, the UICC can be detachable or embedded in the terminal. The fixed profile of the UICC equipped with a fixed profile indicates that the "access information" used to access a specific communication provider is fixed. The access information can be, for example, the IMSI as a subscriber identifier, and the value "K" or "Ki" necessary for authentication when accessing the network along with the subscriber identifier.

[0082] The terminal can then perform authentication using the UICC through the mobile communication provider's authentication processing system (e.g., Home Location Register (HLR) or AuC). The authentication process can be an authentication and key agreement (AKA) process. If authentication is successful, the terminal can use mobile communication services, such as telephone calls or mobile data usage using the mobile communication network 130 of the mobile communication system.

[0083] Figure 2 Figure 200 shows an example of a hierarchy (or certificate chain) of certificates issued by a Certificate Authority (CI) contained in each certificate, as well as an example of the configuration of the Certificate Authority's (CI) public key and digital signature.

[0084] refer to Figure 2 The Certificate Issuer (CI) can generate a public key and a secret key that will be used by the Certificate Issuer. It can generate a Certificate Issuer (CI) certificate 211 by including the public key 213 of the above keys in its own certificate, and can attach a digital signature 215 generated using its own secret key about the certificate to the certificate.

[0085] Additionally, refer to Figure 2CI certificate 211 can be used to issue certificate 231 (see 291) for object 1. Object 1 can be, for example, a profile management server (SM-DP+). Object 1 can generate a public key and a secret key for its own use. This can be achieved by including the public key 233 within its own certificate, and by requesting a certificate issuer to receive a certificate issuer (CI) digital signature 235 using the certificate issuer's (CI) secret key. In this case, object 1's certificate 231 may include a certificate issuer (CI) public key identifier (ID) (CI PKID) 237 corresponding to the certificate issuer's (CI) public key 213, which will be used when checking the certificate issuer signature 235 contained in the corresponding certificate.

[0086] Additionally, refer to Figure 2 CI certificate 211 can be used to issue certificate 251 for object 2 (see 293). Object 2 can be, for example, an eUICC manufacturer (EUM). Object 2 can generate a public key and a secret key for its own use. This can be achieved by including the public key 253 of the aforementioned keys in its own certificate to generate certificate 251, and by requesting a certificate issuer to receive a certificate issuer (CI) digital signature 255 using the certificate issuer's (CI) secret key. In this case, certificate 251 for object 2 may include a certificate issuer (CI) public key identifier (ID) (CI PKID) 237 corresponding to the certificate issuer (CI) public key 213, which will be used when checking the certificate issuer signature 255 contained in the corresponding certificate. The certificate issuer signatures 235 and 255 contained in certificate 231 for object 1 and certificate 251 for object 2 may have different values, but the certificate issuer public key identifier (CI PKID) 237 has the same value.

[0087] Additionally, refer to Figure 2 The certificate 251 of object 2 can be used to issue the certificate 271 of object 3 (see 295). Object 3 can be, for example, an eUICC manufactured by an eUICC manufacturer (EUM). Object 3 can generate a public key and a secret key for its own use. The certificate 251 of object 3 can be generated by including the public key 273 of the aforementioned keys in its own certificate, and can request object 2 to receive the digital signature 275 of object 2 using the secret key of object 2. In this case, the certificate 271 of object 3 may include a public key identifier (ID) (CI PKID) 277 corresponding to the public key 253 of object 2, which will be used when checking the signature 275 of object 2 contained in the corresponding certificate.

[0088] exist Figure 2 The example shown illustrates that certificate 231 for object 1, certificate 251 for object 2, and certificate 271 for object 3 all have the same CI certificate 211 as the highest certificate or certificate root. Therefore, objects 1, 2, and 3 need to include either CI certificate 211 or CI public key 213 to authenticate each other. More specifically, in Figure 2 In the example, in order for Object 1 and Object 2 to authenticate each other using digital certificates and signatures, Object 1 needs Object 2's signature, Object 2's certificate 251, and CI public key 213, and Object 2 needs Object 1's signature, Object 1's certificate 231, and CI public key 213.

[0089] In addition, Figure 2 In the example, for Object 1 and Object 3 to authenticate each other using digital certificates and signatures, Object 1 needs Object 3's signature, Object 3's certificate 271, Object 2's certificate 251, and CI public key 213, while Object 3 needs Object 1's signature, Object 1's certificate 231, and CI public key 213. In this case, the certificate 251 of Object 2 regarding Object 3's certificate 271 can be referred to as a "sub-CI certificate" or a "sub-CA certificate".

[0090] Figure 3 Figure 300 illustrates the mutual authentication process between server 310 and terminal 350.

[0091] exist Figure 3 In this context, server 310 can be, for example, a profile management server (SM-DP+) or a service discovery server (SM-DS). Additionally, in... Figure 3 In this configuration, terminal 350 may include eUICC 330 and software {Local Profile Assistant (LPA)} 320 for controlling eUICC. Furthermore, in... Figure 3 In this configuration, each of the servers 310, LPA 320, and eUICC 330 can store one or more digital certificates.

[0092] refer to Figure 3In step 3003, LPA 320 can check a list of all CI public keys (CIPKIDs) supported by eUICC 330. More specifically, in step 3003, LPA 320 and eUICC 330 can identify eUICC information using eUICC information request (get eUICC information request) messages and eUICC information response (get eUICC information response) messages. The eUICC information response message may include eUICC information, referred to as "euiccInfo1", "euiccInfo", etc. The eUICC information may include a list of all CI PKIDs supported by eUICC 330.

[0093] In step 3005, LPA 320 and server 310 can establish a TLS connection. The server authentication method in the TLS connection method can be used to establish the TLS connection in step 3005, where LPA 320 verifies the identity of server 310. While LPA 320 identifies server 310 during the TLS connection in step 3005, server 310 can submit its TLS certificate to LPA 320. LPA 320 or terminal 350 can store one or more CI PKIDs used to verify the TLS certificate. If verifying the validity of server 310's TLS certificate using CIPKIDs requires one or more sub-CI certificates, server 310 can submit one or more sub-CI certificates along with the TLS certificate to LPA 320 in step 3005. After the TLS connection is established, all messages between LPA 320 and server 310 can be protected by the TLS security process.

[0094] In operation 3007, LPA 320 may send a request to server 310 to initiate mutual authentication. The initiation of mutual authentication can be performed using an Initiate Authentication Request message. Based on the eUICC 330 information (euiccInfo1) identified by LPA 320 in step 3003, the Initiate Authentication Request message in step 3007 may include all CI PKIDs supported by eUICC 330.

[0095] In operation 3009, server 310 may respond to LPA 320 with mutual authentication. The mutual authentication response may use an Initiate Authentication Response message. The Initiate Authentication Response message in step 3009 may include a CI PKID selected from the list of CI PKIDs included in the eUICC 330 information (euiccInfo1) received by server 310 in step 3007, a server certificate capable of verifying validity using the corresponding CI PKID, and a digital signature of server 310 capable of verifying validity using the corresponding server certificate. In this case, the CI PKID selected by server 310 may be referred to as the "eUICC CI PKID to be used by eUICC". Additionally, if determining the validity of server 310 using the selected CI PKID requires one or more sub-CI certificates, the Initiate Authentication Response message in step 3009 may include one or more sub-CI certificates and the server certificate. The certificate of server 310 sent in step 3007 may be different from the TLS certificate of server 310 sent in step 3005. Furthermore, the CI for issuing the certificate of server 310 sent in step 3007 and the CI for issuing the TLS certificate of server 310 sent in step 3005 can be the same or different.

[0096] In operation 3011, LPA 320 may send a request to eUICC 330 to authenticate the server. An authentication server request message can be used to perform the authentication request. The authentication server request message in step 3011, similar to the message received by LPA 320 in step 3009, may include the CI PKID selected and sent by the server, a server certificate that can be used to verify validity using the corresponding CI PKID, one or more sub-CI certificates necessary for verification, and a digital signature of server 310 that can be used to verify validity using the server certificate. Additionally, the authentication server request message in step 3011 contains additional information generated by LPA 320 and may include information about the type of operation the terminal intends to perform.

[0097] In step 3013, eUICC 330 may send the server authentication result to LPA 320 as a response. The authentication result can be sent using an authentication server response message. The authentication server response message in step 3013 may include the validity verification result of the digital signature of server 310 received by eUICC 320 in step 3011, the CI PKID selected and sent by server 310, the eUICC certificate capable of verifying validity using the corresponding CI PKID, one or more sub-CI certificates required for validity verification, the digital signature of eUICC 330 capable of verifying validity using the eUICC certificate, and information about the type of operation the terminal intends to perform.

[0098] In operation 3015, LPA 320 may send an authentication request for the terminal to server 310. The authentication request for the terminal can be executed using an authentication client request message. The authentication client request message in step 3015 may include the information received by LPA 320 from eUICC 330 in step 3013.

[0099] In operation 3017, server 310 may send the authentication result of the terminal as a response. The authentication result can be sent using an authentication client response message. The authentication client response message in step 3017 may include a verification result regarding the validity of the digital signature of the eUICC 330 received by server 310 in step 3015, and information regarding an event or event summary corresponding to the type of operation to be performed by terminal 350.

[0100] In step 3019, terminal 350 can install a profile or remotely manage the profile based on the content of the event received in step 3017.

[0101] according to Figure 3 The mutual authentication process between server 310 and terminal 350 shown in the diagram is such that, since terminal 350 uses all CI PKIDs pre-stored in eUICC 330 to verify the validity of the server certificate, it is difficult to restrict connections to server 310 which has a server certificate belonging to a specific CI certificate certificate hierarchy.

[0102] Figure 4 This is a diagram illustrating the process of identifying a server 310 having a server certificate belonging to a specific CI certificate hierarchy when mutual authentication is performed between a server 310 and a terminal 350 according to an embodiment of the present disclosure.

[0103] exist Figure 4 For descriptions of server 310, LPA 320, eUICC 330, and terminal 350, please refer to the documentation. Figure 3The description is as follows.

[0104] refer to Figure 4 As a method to restrict the certificate of server 310 to certificates belonging to a specific CI certificate's certificate hierarchy during subsequent mutual authentication, LPA 320 can obtain the public key identifier (CI PKID) information of the corresponding CI certificate in step 4001. LPA 320 can obtain the corresponding CI PKID information through methods such as those described below, but the method is not limited to these.

[0105] - Instructs the user to input into the terminal

[0106] - Retrieved some data from the eUICC storage space

[0107] - Retrieve the archive installed in eUICC

[0108] - Retrieve the activation code used in the installation of the archive.

[0109] - Transmitted to LPA in the form of command codes by third-party software

[0110] -Transmission to LPA from a specific server installed via a relay profile or remotely managed.

[0111] - Data is transmitted from the management terminal, LPA, and eUICC server to the LPA.

[0112] In step 4003, LPA 320 may check whether eUICC 330 can support the corresponding CI PKID associated with the CI PKID information obtained in step 4001. (Refer to...) Figure 5 The operation of terminal 350 in step 4003 is described in more detail.

[0113] In operation 4005, LPA 320 and server 310 can establish a TLS connection. The TLS connection in step 4005 can be established using the server authentication method within the TLS connection method, in which LPA 320 identifies the identity of server 310. When LPA 320 identifies the identity of server 310 during the TLS connection processing in step 4005, server 310 can submit its TLS certificate to LPA 320. LPA 320 or terminal 350 may include one or more CIPKIDs for verifying the validity of the TLS certificate. If verifying the validity of server 310's TLS certificate using a CI PKID requires one or more sub-CI certificates, server 310 can submit one or more sub-CI certificates along with the TLS certificate to LPA 320 in step S4005. In step 4005, with... Figure 3Compared to step 3005 described in step 4001, terminal 350 can also use the CI PKID identified in step 4001 to check whether the TLS certificate and subCI certificate submitted by the server can be verified. After the TLS connection is established, all messages between LPA 320 and server 310 can be protected by the TLS security process.

[0114] In operation 4007, LPA 320 can send a request to server 310 to initiate mutual authentication. The initiation of mutual authentication can be performed using an Initiate Authentication Request message. Figure 3 Compared to step 3007 described herein, the authentication request message in step 4007 may include the CI PKID obtained by LPA 320 in step 4001. Additionally, compared to... Figure 3 Compared to step 3007 described in step 4007, the authentication request message in step 4007 may include the CI PKID that was identified by eUICC as being supported by eUICC in step 4003.

[0115] In operation 4009, server 310 can respond to LPA 320 with mutual authentication. A mutual authentication response can be performed using an Initiate Authentication Response message. The Initiate Authentication Response message in step 4009 may include the CI PKID received by server 310 in step 4007, a server certificate capable of verifying validity using the corresponding CI PKID, and a digital signature of server 310 capable of verifying validity using the corresponding server certificate. In this case, the sent CI PKID may be referred to as the "eUICC CI PKID to be used by eUICC". Additionally, if determining the validity of server 310 using the corresponding CI PKID requires one or more sub-CI certificates, the Initiate Authentication Response message in step 4009 may include one or more sub-CI certificates and the server certificate. The certificate of server 310 sent in step 4009 may be different from the TLS certificate of server 310 sent in step 4005. Furthermore, the CI that issued the certificate of server 310 sent in step 4009 and the CI that issued the TLS certificate of server 310 sent in step 4005 may be the same or different. Additionally, LPA 320 can compare the CI PKID sent by server 310 in step 4009 with the CI PKID sent by LPA 320 in step 4007. If the CI PKID sent by server 310 is different from the CI PKID sent by LPA 320 in step 4007, LPA 320 can terminate the communication.

[0116] In operation 4011, LPA 320 may request authentication from eUICC 330. An authentication server request message can be used to execute the authentication request. Similar to the message received by LPA 320 in step 4009, the authentication server request message in step 4011 may include a CI PKID sent by server 310, a server certificate that can be validated using the corresponding CI PKID, one or more sub-CI certificates required for validity verification, and a digital signature of server 310 that can be validated using the server certificate. Additionally, the authentication server request message in step 4011 contains additional information generated by LPA 320 and may include information about the type of operation the terminal intends to perform. Having received the message in step 4011, eUICC 330 can verify the validity of the certificate included in the message in step 4011 and can use the corresponding certificate to verify the digital signature of server 310. In this case, eUICC 330 may also check whether eUICC 330 can support the CI PKID included in the message in step 4011 and / or whether the CI PKID is available. If the CI PKID sent by server 310 cannot be supported, or if the CI PKID is unavailable, eUICC 330 may terminate communication.

[0117] In step 4013, eUICC 330 may send the server authentication result to LPA 320 in response. The authentication result can be sent using an authentication server response message. The authentication server response message in step 4013 may include the validity verification result of the digital signature of server 310 received by eUICC 320 in step 4011, the CI PKID sent by server 310, the eUICC certificate whose validity can be verified using the corresponding CI PKID, one or more sub-CI certificates required for validity verification, the digital signature of eUICC 330 whose validity can be verified using the eUICC certificate, and information about the type of operation the terminal intends to perform.

[0118] The description of the subsequent operations in steps 4015 to 4019 refers to the... Figure 3 Description of the operations in steps 3015 to 3019.

[0119] according to Figure 4 The mutual authentication process between server 310 and terminal 350 shown in the diagram allows connection to server 310 with a server certificate belonging to a specific CI certificate hierarchy to be restricted, since terminal 350 uses the specific CI PKID entered in step 4001 to verify the server certificate.

[0120] Figure 5 It is shown that... Figure 4 Figure 500 shows the operation of LPA 320 and eUICC 330 related to the operation in step 4003 described in the figure.

[0121] exist Figure 5 For descriptions of LPA 320, eUICC 330, and Terminal 350, please refer to the section on... Figure 3 The description is as follows.

[0122] refer to Figure 5 , such as in Figure 4 Similar to step 4001, LPA 320 can obtain CI PKID information. For a detailed description of step 4001, please refer to [link to relevant documentation]. Figure 4 The following description is provided. Afterwards, terminal 350 can check whether eUICC 330 supports the corresponding CI PKID in the following manner.

[0123] As an example 5100, LPA 320 can compare the CI PKID information obtained in step 4001 with the eUICC information (euiccInfo1 or euiccInfo) temporarily cached in LPA 320 in step 5003. More specifically, before step 4001, LPA 320 will... Figure 3 If the eUICC information (euiccInfo1 or euiccInfo) identified by the method described in step 3003 is cached in temporary memory, LPA 320 can compare the list of all CI PKIDs supported by the eUICC included in the temporary memory with the CI PKID information obtained in step 4001. As a result of the comparison, if it is determined that the eUICC 330 does not support the CI PKID obtained in step 4001, LPA 320 can terminate communication.

[0124] As another example 5200, in steps 5005 to 5009, LPA 320 may send a message to eUICC (330) to identify a list of CI PKIDs supported by eUICC (330) and may compare them with the CI PKIDs in step 4001. More specifically, LPA 320 may send an information request message to eUICC 330 in step 5005 after step 4001. The message in step 5005 may be referred to as a “get eUICC information request message”, a “get eUICC challenge request message”, an “authentication server request message”, etc. Additionally, the message in step 5005 may include the identifier (profile ID, ICCID, or AID) of the profile that will become the target of remote profile management in the future. In step 5007, eUICC 330 can retrieve CI PKID information from the profile corresponding to the profile identifier received in step 5005, or it can obtain all CI PKID information supported by eUICC 330, thereby sending the corresponding CI PKID information and eUICC information (euiccInfo1 or euiccInfo) to LPA 320. The message in step 5007 can be referred to as a "retrieve eUICC information response message," a "retrieve eUICC challenge response message," or an "authentication server response message." Then, in step 5009, LPA 320 can compare the response from eUICC 330 received in step 5007 with the CI PKID obtained in step 4001. As a result of the comparison, if it is determined that eUICC 330 does not support the CI PKID obtained in step 4001, LPA 320 can terminate the communication.

[0125] As another example 5300, in steps 5011 to 5015, LPA 320 may send a message to eUICC 330 to request a check whether eUICC 330 supports the CI PKID in step 4001. More specifically, after step 4001, LPA 320 may send a check request message to eUICC 330 in step 5011. The message in step 5011 may be called a "Get eUICC Information Request Message," a "Get eUICC Challenge Request Message," or an "Authentication Server Request Message." Additionally, the message in step 5011 may include the CI PKID information from step 4001 used to request a check whether eUICC 330 supports it, and may also include the identifier (profile ID, ICCID, or AID) of the profile that will become the target of remote profile management in the future. In this regard, in step 5013, the eUICC 330 can compare the CI PKID information received in step 4001 in step 5011 with a list of CI PKIDs supported by the eUICC 330, or it can compare the CI PKID information retrieved from the profile corresponding to the profile identifier received in step 5011 with a list of CI PKIDs supported by the eUICC 330, thereby identifying whether the eUICC 330 supports the corresponding CI PKID. If the eUICC does not support the corresponding CI PKID, the eUICC 330 can send a specific error code in response and can terminate communication. In step 5015, the eUICC 330 can send a check response message to the LPA 320, which includes at least one of the following: information on whether the corresponding CI PKID is supported, the corresponding CI PKID information, eUICC information (euiccInfo1 or euiccInfo), and an eUICC random challenge. The message in step 5015 can be referred to as "Retrieve eUICC Information Response Message", "Retrieve eUICC Challenge Response Message", or "Authentication Server Response Message". If eUICC 330 sends an error code indicating that CI PKID is not supported in response, LPA 320 can terminate communication.

[0126] Figure 6 This is a diagram illustrating the structure 600 of a terminal according to an embodiment of the present disclosure.

[0127] refer to Figure 6 The terminal may include a transceiver 610, a controller 620, and a storage unit 630. In this disclosure, the controller may be defined as a circuit, an application-specific integrated circuit (ASIC), or at least one processor. Additionally, although in Figure 6 It is not explicitly shown, but the terminal may further include an eUICC, and the eUICC may be inserted into or embedded in the terminal.

[0128] Transceiver 610 can send signals to and receive signals from other network entities. For example, transceiver 610 can transmit information about a digital certificate issuer trusted by the terminal and a random string (a one-time random number or random challenge) used by the Profile Management Server (SM-DP+) when generating a signature for self-authentication to the Profile Management Server, or it can receive the Profile Management Server's signature, one or more digital certificates used to verify the Profile Management Server's signature, and the random string used by the eUICC in the terminal when generating a signature for self-authentication from the Profile Management Server.

[0129] Furthermore, transceiver 610 can send the eUICC signature and one or more digital certificates to be used to verify the eUICC signature. Additionally, transceiver 610 can further send information about the type of operation the terminal intends to perform to a profile management server, or can receive some or all of this information about the operation the terminal intends to perform from the profile management server. However, transceiver 610 can selectively send information about the type of operation the terminal intends to perform.

[0130] According to the embodiments presented in this disclosure, controller 620 can control the overall operation of the terminal. For example, controller 620 can control the signal flow between blocks to perform operations according to the flowchart described above.

[0131] More specifically, the controller 620 can refer to the eUICC in the terminal to identify the digital certificate issuer information that the terminal will trust, verify the validity of the digital certificate and digital certificate issuer information sent by the profile management server, identify the signature of the profile management server, and generate a signature for the eUICC. Furthermore, the controller 620 can perform profile installation or management operations based on information received from the profile management server.

[0132] In addition, the controller 620 can control the operation of the transceiver or storage unit.

[0133] The storage unit 630 can store at least one of the information sent and received by the transceiver 610 and the information generated by the controller 620.

[0134] Furthermore, the terminal disclosed herein may also include an input unit for receiving information about a digital certificate issuer trusted by the terminal. However, without an input unit, the terminal may receive the digital certificate issuer information from a server or network, refer to information pre-stored in the terminal, or receive the information from third-party software within the terminal. When receiving digital certificate issuer information from third-party software, the third-party software may pre-store the information about the digital certificate issuer trusted by the terminal, or it may receive the information from a server or network.

[0135] Figure 7 This is a diagram illustrating the structure 700 of a server according to an embodiment of the present disclosure.

[0136] refer to Figure 7 The server may include a transceiver 710, a controller 720, and a storage unit 730. In this disclosure, the controller may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

[0137] Transceiver 710 can send signals to and receive signals from other network entities. For example, transceiver 710 can receive information about a digital certificate issuer trusted by the terminal, as well as a random string (one-time random number or random challenge) used by the profile management server when generating a signature for self-authentication.

[0138] Furthermore, transceiver 710 can send to the terminal the signature of the profile management server, one or more digital certificates used to authenticate the signature of the profile management server, and a random string used by the eUICC in the terminal when generating a signature for self-authentication. It can also receive the signature of the eUICC and one or more digital certificates to be used to verify the signature of the eUICC. Additionally, transceiver 710 can also receive information from the terminal regarding the type of operation the terminal intends to perform. However, this information regarding the type of operation the terminal intends to perform can be sent selectively.

[0139] In addition, transceiver 710 can send some of the information related to the operation to be performed by the terminal to the terminal.

[0140] According to the embodiments presented in this disclosure, the controller 720 can control the overall operation of the terminal. For example, the controller 720 can control the signal flow between blocks to perform operations according to the flowchart described above.

[0141] More specifically, the controller 720 can verify whether the digital certificate issuer information trusted by the terminal is valid, determine whether the server can also trust the digital certificate issuer trusted by the terminal, select a digital certificate corresponding to the digital certificate issuer information trusted by the terminal, and generate a signature for the profile management server.

[0142] In addition, the controller 720 can verify the validity of the digital certificate sent by the terminal, recognize the eUICC signature, and determine the type of operation to be performed by the terminal.

[0143] In addition, the controller 720 can control the operation of the transceiver or storage unit.

[0144] The storage unit 730 can store at least one of the information sent and received by the transceiver 710 and the information generated by the controller 720.

[0145] In the detailed embodiments described above, the components included in this disclosure are represented in a singular or plural form according to the presented detailed embodiments. However, for ease of description, the singular or plural form is chosen to suit the presented situation, and the various embodiments of this disclosure are not limited to a single element or multiple elements thereof. Furthermore, multiple elements expressed in the specification may be configured as a single element, or a single element in the specification may be configured as multiple elements.

[0146] Although embodiments have been described in detail in this disclosure, modifications may be made in various forms without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the embodiments, but rather to the appended claims and their equivalents.

Claims

1. A method performed by a terminal including a Universal Integrated Circuit Card (UICC) in a wireless communication system, the method comprising: identifying a first Certificate Issuer (CI) public key identifier; obtaining UICC information including a list of public key identifiers supported by the UICC from the UICC; obtaining a new list based on the list of public key identifiers supported by the UICC, wherein the new list includes at least one public key identifier from the list of public key identifiers supported by the UICC except for a public key identifier that matches the first CI public key identifier; and transmitting, to a server, a first message for initiating authentication, the first message including the new list, wherein a public key identifier used in an authentication procedure is limited to the first CI public key identifier, and wherein the first CI public key identifier is identified by at least one of receiving a user input regarding the terminal, retrieving information stored in the UICC, retrieving an activation code, or retrieving a command code. The obtaining of the new list comprises:

2. The method of claim 1, wherein, comparing the first CI public key identifier with the list of public key identifiers supported by the UICC included in the UICC information. 3.The method of claim 1, further comprising: stopping the authentication procedure in case that there is no public key identifier that matches the first CI public key identifier in the list of public key identifiers supported by the UICC. 4.The method of claim 1, further comprising: receiving, from the server, a second message as a response to the first message, and wherein the second message includes a second CI public key identifier to be used by the UICC, a server certificate, and a server signature, wherein the second CI public key identifier is determined based on the first message, and wherein the validity of the server for authentication is verified based on the server certificate and the server signature. 5.A terminal in a wireless communication system, the terminal comprising: a transceiver; a Universal Integrated Circuit Card (UICC); and a controller coupled with the transceiver and configured to: identify a first Certificate Issuer (CI) public key identifier, obtain UICC information including a list of public key identifiers supported by the UICC from the UICC, obtain a new list based on the list of public key identifiers supported by the UICC, wherein the new list includes at least one public key identifier from the list of public key identifiers supported by the UICC except for a public key identifier that matches the first CI public key identifier, and transmit, to a server, a first message for initiating authentication, the first message including the new list, wherein a public key identifier used in an authentication procedure is limited to the first CI public key identifier, and wherein the first CI public key identifier is identified by at least one of receiving a user input regarding the terminal, retrieving information stored in the UICC, retrieving an activation code, or retrieving a command code. the controller is configured to: ​ 6. The terminal according to claim 5, wherein ​ comparing the first CI public key identifier with a list of public key identifiers supported by the UICC included in the UICC information.

7. The terminal according to claim 5, wherein The controller is further configured to: stop the authentication procedure in case no public key identifier matches the first CI public key identifier included in the list of public key identifiers supported by the UICC.

8. The terminal of claim 5, wherein, The controller is configured to: receive a second message from the server as a response to the first message, and wherein the second message comprises a second CI public key identifier to be used by the UICC, a server certificate and a server signature, wherein the second CI public key identifier is determined based on the first message, and wherein the validity of the server for authentication is verified based on the server certificate and the server signature. 9.A method for performing by a server in a wireless communication system, the method comprising: receiving a first message for initiating authentication of a terminal from the terminal, the first message comprising a list of public key identifiers matching a first certificate issuer (CI) public key identifier; and transmitting a second message to the terminal as a response to the first message, the second message comprising a second CI public key identifier to be used by a universal integrated circuit card (UICC) of the terminal; wherein the list comprises at least one public key identifier from a list of public key identifiers supported by the UICC of the terminal, except for the public key identifiers not matching the first CI public key identifier, wherein the public key identifier used in the authentication procedure is limited to the first CI public key identifier, and wherein the first CI public key identifier is identified by at least one of receiving a user input regarding the terminal, retrieving information stored in the UICC, retrieving an activation code, or retrieving a command code.

10. The method of claim 9, wherein, the list is identified by the terminal by comparing the first CI public key identifier with a list of public key identifiers supported by the UICC of the terminal included in UICC information cached in the terminal, wherein the second message further comprises a server certificate and a server signature, wherein the second CI public key identifier is determined based on the first message, and wherein the validity of the server for authentication is verified based on the server certificate and the server signature. 11.A server in a wireless communication system, the server comprising: a transceiver; and a controller coupled with the transceiver and configured to: receive a first message for initiating authentication of a terminal from the terminal, the first message comprising a list of public key identifiers matching a first certificate issuer (CI) public key identifier, and transmit a second message to the terminal as a response to the first message, the second message comprising a second CI public key identifier to be used by a universal integrated circuit card (UICC) of the terminal, wherein the list comprises at least one public key identifier from a list of public key identifiers supported by the UICC of the terminal, except for the public key identifiers not matching the first CI public key identifier, wherein the public key identifier used in the authentication procedure is limited to the first CI public key identifier, and wherein the first CI public key identifier is identified by at least one of receiving a user input regarding the terminal, retrieving information stored in the UICC, retrieving an activation code, or retrieving a command code. wherein the first CI public key identifier is identified by at least one of receiving user input regarding the terminal, retrieving information stored in the UICC, retrieving an activation code or retrieving a command code.

12. The server of claim 11, wherein, the list is identified by the terminal by comparing the first CI public key identifier with a list of public key identifiers supported by the UICC of the terminal cached in the terminal, wherein the second message further comprises a server certificate and a server signature, wherein the second CI public key identifier is determined based on the first message, wherein the validity of the server for authentication is verified based on the server certificate and the server signature.

Images