Apparatus and method for access control by esim

Abstract

The disclosure relates to a communication technology that combines a 5G communication system for supporting a data rate higher than a data rate of a super 4G system with an IoT technology, and a system thereof. The disclosure can be applied to intelligent services based on the 5G communication technology and the IoT-related technology, such as smart home, smart building, smart city, smart car or connected car, health care, digital education, retail, security and safety-related services. More specifically, the disclosure relates to an apparatus and method in which a terminal performs a communication connection by downloading and installing a communication service in a communication system.

Description

[0001] This application is a divisional application of patent application No. 201880004652.9, filed on February 13, 2018, entitled "Apparatus and method for access control through eSIM", the disclosure of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present disclosure relates generally to an apparatus and method for communication connection in a communication system by downloading and installing a communication service onto a terminal, and more particularly, to an apparatus and method for online downloading, installing, and managing a profile in a communication system. BACKGROUND

[0003] To meet the demand for wireless data traffic that is on an increasing trend since commercialization of 4G communication systems, efforts are being made to develop an improved 5G or pre-5G communication system. Therefore, the 5G or pre-5G communication system is also called a beyond 4G network communication system or a post LTE system.

[0004] To achieve a high data rate, it has been considered to implement 5G communication systems in a super high frequency (mmWave) band (e.g., similar to 60 GHz band). To decrease the path loss of radio waves and increase a transfer distance of the radio waves in the super high frequency band, technologies of beamforming, massive MIMO, full dimensional MIMO (FD-MIMO), array antenna, hybrid beamforming, and large scale antenna for 5G communication systems have been discussed.

[0005] In addition, for system network improvement in 5G communication systems, technologies for evolved small cells, advanced small cells, cloud radio access network (cloud RAN), ultra-dense networks, device-to-device communication (D2D), wireless backhaul, moving networks, cooperative communication, coordinated multi-points (CoMP), and reception interference cancellation have been developed.

[0006] In addition, in 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) that are a kind of advanced coding modulation (ACM) systems and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) that are a kind of advanced connection techniques have been developed.

[0007] On the other hand, the Internet, which is a human centered connectivity network where humans generate and consume information, is now evolving to the Internet of Things (IoT) where distributed entities, such as things, exchange and process information to create a smart world. The Internet of Everything (IoE), which is a combination of the IoT technology and the Big Data processing technology through connection with a cloud server, has emerged as a new paradigm for the IoT. As technology elements, such as a sensing technology, a wired / wireless communication and network infrastructure, a service interface technology, and a security technology, have been demanded for IoT implementation, a sensor network, a Machine to Machine (M2M) communication, Machine Type Communication (MTC), and so forth have been researched. Such an IoT environment can provide intelligent Internet technology (IT) services that create a new value through collection and analysis of data generated from connected things. The IoT can be applied to a variety of fields including a smart home, a smart building, a smart city, a smart car or a connected car, a smart grid, health care, smart appliances, and an advanced medical service through the convergence of existing information technology (IT) and various industries.

[0008] Accordingly, various attempts have been made to apply the 5G communication system to the IoT network. For example, technologies, such as a sensor network, Machine to Machine (M2M) communication, and MTC, have been implemented by techniques, such as beamforming, MIMO, and array antennas, corresponding to 5G communication technologies. As big data processing technology as described above, application of a cloud Radio Access Network (RAN) will be an example of convergence between the 5G technology and the IoT technology. SUMMARY

[0009] TECHNICAL PROBLEM

[0010] A Universal Integrated Circuit Card (UICC) is a smart card that can be inserted into a mobile communication terminal or the like. The UICC can include an access control module for accessing a network of a mobile communication service provider. Examples of the access control module include a Universal Subscriber Identity Module (USIM), a Subscriber Identity Module (SIM), and an Internet Protocol (IP) Multimedia Service Identity Module (ISIM). The UICC including the USIM can be referred to as a USIM card. Similarly, the UICC including the SIM module can be referred to as a SIM card. Herein, it is assumed that the SIM card includes a UICC card, a USIM card, and a UICC containing an ISIM. However, although the SIM card is described, technical features thereof can be applied to the USIM card, the ISIM card, or a general UICC card in the same manner.

[0011] The SIM card stores personal information of a mobile communication user and allows the user to use secure mobile communication by performing user authentication and service security key generation during access to a mobile communication network.

[0012] Typically, a SIM card is manufactured as a dedicated card for a specific mobile communications service provider. Authentication information for accessing the service provider's network, such as the USIM application (app) and IMSI, K value (user key), and OPc value (operator variant algorithm configuration value), is pre-embedded in the card before shipment. The manufactured SIM card is then delivered to the mobile communications service provider and then provided to the user. Thereafter, if necessary, applications in the UICC can be managed, such as installation, modification, and deletion, using technologies such as over-the-air (OTA). Users can access the network and application services of the mobile communications service provider by inserting the UICC into their mobile communications terminal.

[0013] When a user changes terminals, the UICC card can be removed from the existing terminal and inserted into the new terminal, thereby allowing the new terminal to use the authentication information, mobile communication phone number, personal phone book, etc. stored in the UICC card.

[0014] However, when a mobile communication terminal user wants to change service providers, i.e., to receive services from a new mobile communication service provider, SIM cards are inconvenient to use because the user must physically obtain a new SIM card for the service from the new mobile communication service provider. For example, when traveling to a new country, the terminal user must purchase a local SIM card to receive local mobile communication services in the new country. Although roaming services can partially alleviate this inconvenience, users may not be able to or do not want to receive roaming services due to high fees or the lack of agreements between communication service providers.

[0015] However, this problem can be solved by remotely downloading and installing a SIM module into a UICC. This means that users can download a new SIM module for the mobile communication service they wish to use into the UICC at a desired time. Multiple SIM modules can be downloaded and installed into the UICC, and one of the downloaded SIM modules can be selected for use. The UICC can be fixed or not fixed to the terminal.

[0016] In particular, a UICC that is fixed to a terminal is often referred to as an embedded UICC (eUICC). Herein, an eUICC refers to a UICC card that is typically fixed within a terminal and that enables remote download and selection of a SIM module. In other words, a UICC card that is fixed within a terminal or not fixed within a terminal and that enables remote download and selection of a SIM module is referred to as an eUICC. Furthermore, the downloaded SIM module information may be referred to as an eUICC profile or profile.

[0017] A terminal can include software that controls eUICC operations (e.g., operations to download, select, or delete eUICC profiles). Herein, such software can be referred to as a local profile assistant (LPA), which can be unique software that controls an eUICC by receiving input from other software included in a terminal.

[0018] Solution to the problem

[0019] An aspect of the disclosure is to provide an apparatus and method for a terminal to perform a communication connection using a selected communication service in a communication system.

[0020] Another aspect of the disclosure is to provide an apparatus and method for a terminal to download, install, and manage a profile to perform a communication connection in a communication system.

[0021] Another aspect of the disclosure is to provide an apparatus and method for efficiently controlling access of terminal software to an eUICC in a communication system.

[0022] According to an aspect of the disclosure, a method for a terminal to transmit and receive information related to a UICC in a wireless communication system is provided. The method includes transmitting, to a first server, a first message including a challenge generated by a UICC of the terminal, receiving, from the first server, a second message including a signature generated by a second server in response to the challenge, and verifying the signature by the UICC of the terminal.

[0023] According to another aspect of the disclosure, a terminal for transmitting and receiving information related to a UICC in a wireless communication system is provided. The terminal includes a transceiver, and a controller coupled with the transceiver and configured to control the transceiver to transmit, to a first server, a first message including a challenge generated by a UICC of the terminal, control the transceiver to receive, from the first server, a second message including a signature generated by a second server in response to the challenge, and verify the signature by the UICC of the terminal.

[0024] According to another aspect of the disclosure, a method for a first server to transmit and receive information related to a UICC in a wireless communication system is provided. The method includes receiving, from a terminal, a first message including a challenge generated by a UICC of the terminal, and transmitting, to the terminal, a second message including a signature generated by a second server in response to the challenge, wherein the signature is verified by the terminal through the UICC.

[0025] According to another aspect of the present disclosure, a first server that transmits and receives information related to a UICC in a wireless communication system is provided. The first server includes a transceiver, and a controller coupled with the transceiver and configured to control the transceiver to receive a first message including a challenge generated by a UICC of a terminal from the terminal, and control the transceiver to transmit a second message including a signature generated by a second server to the terminal in response to the challenge, wherein the signature is confirmed by the terminal through the UICC.

[0026] Advantages of the Invention

[0027] According to embodiments of the present disclosure, if the second software intends to call a function of the LPA, the LPA of the terminal can identify whether the second software is verified software in the terminal, and can identify access authority of the second software through the network server. Accordingly, the LPA can prevent unverified third software from accessing the LPA, and can inform the network server that the second software intends to access the LPA.

[0028] Further, if the second software intends to call a function of the LPA twice or more, the LPA of the terminal can allow the second software to access according to the above-described procedure regarding initial access, and can omit identification of access authority of the second software through the network server regarding two or more accesses. Accordingly, in the case where verified software requests consecutive LPA access, the LPA can reduce a burden of access authority verification, and can shorten a verification time. BRIEF DESCRIPTION OF DRAWINGS

[0029] The above and other aspects, features, and advantages of certain embodiments of the present disclosure will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0030] Figure 1 A method in which a terminal connects to a mobile communication network using a UICC in which a fixed profile is embedded is illustrated;

[0031] FIGS. 2A and 2B illustrate a configuration of a terminal, a profile server, a service provider server, a service provider app, an LPA, and an eUICC according to an embodiment;

[0032] Figure 3 A method for performing access authority verification of a service provider app in both an offline authentication and an online authentication according to an embodiment is illustrated;

[0033] Figure 4 A method in which, if access authority of a service provider app is verified multiple times, online authentication regarding two or more verifications is omitted according to an embodiment is illustrated;

[0034] Figure 5 An online authentication method in which the LPA accesses the service provider server through the service provider app is shown according to an embodiment;

[0035] Figure 6 An online authentication method in which the LPA directly accesses the service provider server is shown according to an embodiment;

[0036] Figure 7 A process in which the LPA receives help from the eUICC in the online authentication method in which the LPA accesses the service provider server through the service provider app is shown according to an embodiment;

[0037] Figure 8 A process in which the LPA receives help from the eUICC in the online authentication method in which the LPA directly accesses the service provider server is shown according to an embodiment;

[0038] Figure 9 A process in which the LPA receives help from the profile server in the online authentication method in which the LPA accesses the service provider server through the service provider app is shown according to an embodiment;

[0039] Figure 10 A process in which the LPA receives help from the profile server in the online authentication method in which the LPA directly accesses the service provider server is shown according to an embodiment;

[0040] Figure 11 A process in which the LPA receives help from the eUICC and the profile server in the online authentication method in which the LPA accesses the service provider server through the service provider app is shown according to an embodiment;

[0041] Figure 12 A process in which the LPA receives help from the eUICC and the profile server in the online authentication method in which the LPA directly accesses the service provider server is shown according to an embodiment;

[0042] Figure 13 A process in which the LPA uses a key pre-shared in the service provider app and the profile server in the online authentication method in which the LPA accesses the profile server is shown according to an embodiment;

[0043] Figure 14 A process in which the service provider app performs online authentication regarding two LPA function calls if the service provider app downloads a profile through all two LPA function calls is shown according to an embodiment;

[0044] Figure 15It is shown that, according to an embodiment, if the service provider app downloads the profile by two LPA function invocations, the service provider app uses the token about the second LPA function invocation to omit the procedure of online authentication;

[0045] Figure 16 It is shown that, according to an embodiment, if the service provider app downloads the profile by two LPA function invocations, the service provider app uses the token about the second LPA function invocation to omit the procedure of online authentication;

[0046] Figure 17 A terminal according to an embodiment is shown;

[0047] Figure 18 A server according to an embodiment is shown. DETAILED DESCRIPTION

[0048] Various embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. In the following description, specific details such as detailed configuration and components are provided only in order to assist in a comprehensive understanding of these embodiments of the present disclosure. Therefore, it will be apparent to those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. In addition, descriptions of well-known functions and structures are omitted for clarity and conciseness.

[0049] In the drawings, some elements can be exaggerated, omitted, or roughly shown. In addition, the size of the elements shown can not completely reflect the actual size thereof. In addition, the same or similar reference numerals can be used for the same or similar elements in each of the drawings.

[0050] Each block or step of a flowchart illustration and combinations of blocks or steps in the flowchart illustration can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions can also be stored in a computer-usable or computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-usable or computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0051] Each block or step of the flowchart illustrations can represent a module, segment, or portion of code, which includes one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks or steps can occur out of the order noted in the flowcharts. For example, two blocks or steps shown in succession can in fact be executed substantially concurrently or in the reverse order, depending on the functionality involved.

[0052] Herein, the term "unit" can refer to a software or hardware component such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC) that performs certain tasks. However, "unit" does not necessarily refer to a software or hardware. The "unit" can be advantageously configured to reside on a storage medium or device (RAM memory, flash memory, optical disk, hard disk, etc.) and configured to execute on one or more processors. Thus, a "unit" can include a software component, an object-oriented software component, a class component and task component, a process, a function, attribute, procedure, subroutine, a program code segment, a driver, firmware, a microcode, a circuit, a database, a data structure, table, array, or variable. The functionality provided by the components and "units" can be combined into fewer components and "units" or further separated into additional components and "units". In addition, the components and "units" can be implemented to operate one or more central processing units (CPUs) in a device or a secure multimedia card. Furthermore, "unit" can include one or more processors.

[0053] The specific terms used in the following description are provided to help the understanding of the present disclosure, and can be modified in various forms without departing from the scope of the technical idea of the present disclosure.

[0054] Herein, the UICC is a smart card that can be inserted into a mobile communication terminal. The UICC stores personal information such as network access authentication information of a mobile communication subscriber, a phone book, and a short message service (SMS), and can securely use mobile communication by performing user authentication and service security key generation when accessing a mobile communication network such as a global system for mobile communications (GSM), wideband code division multiple access (WCDMA), and LTE.

[0055] In the UICC, communication applications such as a SIM, a USIM, and an ISIM are embedded according to the type of a mobile communication network accessed by a user, and the UICC can provide an upper layer security function for embedding various applications such as an electronic wallet application, a ticketing application, and an electronic passport application.

[0056] The eUICC is a chip-type security module that is embedded (or fixed) in a terminal. The eUICC can download and install a profile using an OTA technique. The eUICC can be referred to as a UICC in which profile download and installation can be performed.

[0057] In the disclosure, the method of downloading and installing a profile in an eUICC using an OTA technique can be applied to a detachable type UICC that can be inserted into or detached from a terminal. That is, the embodiments of the disclosure described with reference to an eUICC can also be applied to a UICC capable of downloading and installing a profile using an OTA technique.

[0058] Herein, the term "UICC" can be used interchangeably with SIM, and the term "eUICC" can be used interchangeably with eSIM.

[0059] Herein, a profile can refer to encapsulation of an application, a file system, and an authentication key value stored in a UICC in the form of software.

[0060] A "USIM profile" can have the same meaning as a "profile," or can mean encapsulation of information included in a USIM application in a profile in the form of software.

[0061] A profile provisioning server can generate a profile, encrypt the generated profile, generate a remote profile management command, and / or encrypt the generated remote profile management command. The profile provisioning server can also be referred to as a subscriber manager data preparation (SM-DP), a subscriber manager data preparation plus (SM-DP+), an out-of-card entity of a profile domain, a profile encryption server, a profile generation server, a profile provider (PP), a profile provider, or a profile provisioning credential holder (PPC holder).

[0062] A profile management server can be referred to as a subscriber manager security routing (SM-SR), a subscriber manager security routing plus (SM-SR+), an out-of-card entity of an eUICC profile manager, a profile management credential (PMC) holder, or an eUICC manager (EM).

[0063] The profile provisioning server can also include the functions of the profile management server. Accordingly, according to various embodiments of the disclosure, the operations of the profile provisioning server can also be performed by the profile management server. The operations described with respect to the profile management server or the SM-SR can also be performed by the profile provisioning server.

[0064] Herein, a terminal can include a mobile station (MS), a user equipment (UE), a user terminal (UT), a wireless terminal, an access terminal (AT), a subscriber unit, a subscriber station (SS), a wireless device, a wireless communication device, a wireless transmit / receive unit (WTRU), a mobile node, a mobile device, a cellular phone, a smartphone, a personal digital assistant (PDA), a wireless modem, a portable computer, an imaging device such as a digital camera, a game device, a music storage and reproduction device, an Internet home appliance, or a portable unit or terminal integrated with a combination of these functions.

[0065] Also, the terminal can include an M2M terminal or an MTC terminal / device, but is not limited thereto.

[0066] The terminal can also be referred to as an electronic device.

[0067] Herein, the UICC capable of downloading and installing a profile can be embedded in an electronic device (e.g., eUICC), or can be physically separated from the electronic device. For example, a card-type UICC can be inserted into the electronic device. The electronic device can include a terminal, and the terminal can include a UICC configured to download and install a profile.

[0068] The terminal or the electronic device can include a first software or application installed therein to control the UICC or the eUICC. The first software or application can be referred to as an LPA.

[0069] The terminal or the electronic device can include a second software or application allowed to access the LPA. The second software or application can be referred to as a service provider app.

[0070] The service provider app can include an access address of a specific server in advance. The server configured to be accessed by the service provider app can be referred to as a service provider server.

[0071] The terminal or the electronic device can include a third software or application not allowed to access the LPA. The third software or application can be referred to as a malicious software.

[0072] The profile discriminator can include a profile identifier (ID), an integrated circuit card ID (ICCID), a machine ID, an event ID, an activation code, an activation code token, an issuer security domain profile (ISD-P), or a factor matching a profile domain (PD). The profile ID can indicate an inherent identifier of each profile. The profile discriminator can include an address of a profile providing server (e.g., SM-DP+) capable of indexing a profile.

[0073] The eUICC ID (EID) can be an inherent identifier of the eUICC embedded in the terminal. Also, if a provider profile has been embedded in the eUICC, the EID can be a profile ID of the corresponding provider profile. Also, according to an embodiment of the disclosure, if the terminal and the eUICC chip are not separated from each other, the EID can be a terminal ID. Also, the EID can be referred to as a specific security domain of the eUICC chip.

[0074] The profile container can include a profile domain or a security domain.

[0075] The Application Protocol Data Unit (APDU) may be a message used for interlocking between the terminal and the eUICC. In addition, the APDU may be a message used for interlocking between the PP or the Profile Manager (PM) and the eUICC.

[0076] An event may refer to a profile download, remote profile management, or another profile or eUICC management / processing command. Profile download may be used interchangeably with profile installation.

[0077] In addition, the event type may indicate whether the specific event is a profile download or remote profile management, or whether the specific event is another profile or eUICC management / processing command. The event type may include an event request type, an event class, or an event request class.

[0078] Profile Envelope can be used interchangeably with Profile or as a term to refer to a data object for a specific profile. A Profile Envelope can include the Profile Type, Length, and Value (TLV) or Profile Envelope TLV. If the Profile Envelope is encrypted using encryption parameters, it can be referred to as a Protected Profile Envelope (PPP) or PPP TLV.

[0079] If 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 BBP TLV. A profile package TLV may include a data set representing information constituting a profile of a TLV type.

[0080] Remote Profile Management (RPM) may be referred to as profile remote management, remote management, remote management commands, remote commands, RPM packages, profile remote management packages, remote management packages, remote management command packages, or remote command packages. RPM can be used to change the state of a specific profile (e.g., enable, disable, or delete) or update the content of a specific profile (e.g., profile nickname or profile metadata).

[0081] Authentication and Key Agreement (AKA) may indicate an authentication algorithm for accessing 3rd Generation Partnership Project (3GPP) and 3GPP2 networks.

[0082] Herein, K is an encryption key value stored in the eUICC for the AKA authentication algorithm, and OPc is a parameter value that may be stored in the eUICC for the AKA authentication algorithm.

[0083] A Network Access Application (NAA) program (such as a USIM or ISIM) may be stored in the UICC to access the network. The NAA may include a network access module.

[0084] Figure 1 A method is shown in which a terminal uses a UICC embedded with a profile fixed to the terminal (100) to connect to a mobile communication network.

[0085] Referring to Figure 1 , the UICC 120 can be inserted into the terminal 110. The UICC can be of a detachable type, or can be pre-embedded in the terminal 110. A fixed profile of the UICC embedded with a fixed profile indicates that "access information" for accessing a specific communication service provider is fixed. The access information can include a subscriber identifier and a K value or a sub-key (Ki) value for authentication in a network using the subscriber identifier.

[0086] The terminal 110 can use the UICC to perform authentication with an authentication processing system (e.g., a home location register (HLR) or an authentication center (AuC)) of a mobile communication service provider. The authentication process can include an AKA process. If the authentication is successful, the terminal 110 can use a mobile communication network 130 of a mobile communication system to use a mobile communication service (e.g., make a phone call) or use mobile data.

[0087] FIGS. 2A and 2B illustrate a terminal (230), a profile server (280), a service provider server (270), a service provider app (240), malware (245), an LPA (250), and an eUICC (260) according to an embodiment (200).

[0088] Referring to FIG. 2A, the terminal 230 includes an LPA 250 connected to a service provider app 240 and an eUICC 260. The connection between the LPA 250 and the service provider app 240 follows a security procedure 290 provided by an operating system (OS) of the terminal 230, fourth security software, or a physical interface connection. In the security procedure 290, if a hash value or a signature value of program code of software or an application and a public key for the corresponding hash or signature or a digital certificate in which the public key is stored are included in the software or the application, the OS of the terminal 230 uses the public key or the digital certificate to verify the hash value or the signature value during installation of the software or the application.

[0089] The LPA 250 is also connected to a profile server (SM-DP+) 280, for example, through a transport layer security (TLS) security procedure.

[0090] The service provider app 240 is also connected to a service provider server 270. The connection between the service provider app 240 and the service provider server 270 can follow a security procedure (e.g., a TLS connection based on an encryption method or a symmetric key) that is optionally selected by the service provider.

[0091] Referring to FIG. 2B, in the terminal 230, in addition to the LPA 250 as the first software and the service provider app 240 as the second software, a malicious software 245 as a third software is installed. According to the security program 290 in the terminal 230, the second software 240 can be allowed to access the LPA 250 (B) or the third software 245 can be blocked from accessing the LPA 250 (A).

[0092] If the service provider app 240 is allowed to access the LPA 250, the service provider app 240 transmits a message requesting information (e.g., the size of the available storage space) of the eUICC 260 to the LPA 250 at step 211. The LPA 250 can read the information of the eUICC 260 and reply to the service provider app 240.

[0093] The service provider app 240 prepares a profile in the profile server 280 using the acquired information of the eUICC at step 213. As a result of the profile preparation, an activation code for profile installation can be generated.

[0094] The service provider app 240 transmits the generated activation code to the LPA 250 at step 215.

[0095] The LPA 250 receives a profile downloaded from the profile server 280 using the received activation code at step 217.

[0096] According to the above-described procedure, the access control of the LPA with respect to the second software or the third software should depend on the security program 290 in the terminal 230, and the network (e.g., the service provider server 270) cannot manage the operation in the terminal 230. In addition, if the LPA 250 is continuously accessed as in steps 211 and 215 in FIG. 2B, the terminal 230 should effectively handle the continuous access to improve the performance of the terminal 230.

[0097] Figure 3 A method (300) for performing access right verification of a service provider app in both phases of offline authentication and online authentication according to an embodiment is illustrated.

[0098] Referring to Figure 3 The LPA 250 offline authenticates the service provider app 240 at step 301. As described above with reference to FIG. 2A, the offline authentication of step 301 can use a function provided by the terminal 230.

[0099] In step 305, LPA 250 authenticates service provider app 240 online through service provider server 270. The online authentication in step 305 may be performed so that LPA 250 accesses service provider server 270 through service provider app 240, or LPA 250 may directly access service provider server 270 in step 307 depending on the configuration of terminal 230 or LPA 250.

[0100] Furthermore, in step 309 , the LPA 250 accesses the eUICC 260 , and in step 311 , the service provider server 270 accesses the profile server 280 .

[0101] Figure 4 It is shown that according to an embodiment, if the access authority of the service provider app is verified multiple times, a method (400) of omitting online authentication regarding two or more verifications is performed.

[0102] Reference Figure 4 , LPA 250 and service provider app 240 for example according to Figure 3 The process initially verifies the access rights of the service provider app 240 to the LPA 250. If the offline authentication in step 301 and the online authentication in step 303 are successful, the LPA 250 operates a timer or issues a token to the service provider app 240.

[0103] Thereafter, when re-authenticating the access rights of the same service provider app 240 to the LPA 250, the LPA 250 determines, in step 401 for offline authentication of the service provider app 240, whether the corresponding authentication was performed or a valid token was used before the expiration of the timer during the previous authentication. If the service provider app 240 was successful in the previous authentication performed before the expiration of the timer or a valid token was used, the LPA 250 may omit online authentication in step 403.

[0104] Figure 5 It shows an online authentication method (500) in which the LPA identifies the service provider app by accessing the service provider server through the service provider app according to an embodiment.

[0105] Reference Figure 5 In step 501, the service provider app 240 attempts to call a specific function of the LPA 250. The corresponding access can be done through Figure 3 The offline authentication of step 301 is transmitted to the LPA 250, and the corresponding access can use the functions provided by the terminal 230 as described above with reference to FIG. 2A.

[0106] At step 503, the LPA 250 generates a query.

[0107] In step 505, the LPA 250 transmits the generated challenge to the service provider server 270 through the service provider app 240 to request a digital signature. The address of the service provider server 270 may be pre-set in the service provider app 240 or the LPA 250, or may be input by the user.

[0108] The service provider server 270 performs a digital signature on the received query in step 507. The digital signature may be performed using a digital certificate and a corresponding key pre-stored in the service provider server 270.

[0109] In step 509, the service provider server 270 sends the generated digital signature to the LPA 250 as a response through the service provider app 240. The response may include the digital signature and one or more digital certificates for verifying the digital signature.

[0110] At step 511, LPA 250 attempts to verify the received digital signature. If the digital signature verification succeeds, LPA 250 deems the access rights of service provider app 240 to be approved, executes the function called by service provider app 240 (e.g., downloading a profile from a profile server), and notifies service provider app 240 or service provider server 270 of the result of executing the function.

[0111] Figure 6 An online authentication method (600) is shown in which the LPA directly accesses the service provider server to identify the service provider app according to an embodiment.

[0112] Reference Figure 6 In step 601, the service provider app 240 attempts to call a specific function of the LPA 250. The corresponding access can be done through Figure 3 The offline authentication of step 301 is transmitted to the LPA 250, and corresponding access can be provided by using the functions of the terminal 230 as described above with reference to FIG. 2A.

[0113] At step 603, the LPA 250 generates a query.

[0114] In step 605, the LPA 250 transmits the generated challenge directly to the service provider server 270 to request a digital signature. The address of the service provider server 270 may be pre-set in the LPA 250, transmitted from the service provider app 240 in step 601, or input from the user.

[0115] The service provider server 270 performs a digital signature on the received query in step 607. The digital signature may be performed using a digital certificate and a corresponding key pre-stored in the service provider server 270.

[0116] In step 609, the service provider server 270 sends the generated digital signature directly to the LPA 250 as a response. The response may include the digital signature and one or more digital certificates for verifying the digital signature.

[0117] In step 611, LPA 250 attempts to verify the received digital signature. If the digital signature verification succeeds, LPA 250 deems the access rights of service provider app 240 to be approved, executes the function called by service provider app 240 (e.g., downloading a profile from a profile server), and notifies service provider app 240 or service provider server 270 of the result of executing the function.

[0118] Figure 7 It shows an online authentication process (700) in which the LPA receives assistance from the eUICC when the LPA identifies the service provider app by accessing the service provider server via the service provider app according to an embodiment.

[0119] Reference Figure 7 In step 701, the service provider app 240 attempts to call a specific function of the LPA 250. The corresponding access can be done through Figure 3 The offline authentication of step 301 is transmitted to the LPA 250, and corresponding access can be provided by using the functions of the terminal 230 as described above with reference to FIG. 2A.

[0120] In step 703, the LPA 250 requests the eUICC 260 to generate a challenge, and then the eUICC 260 generates a challenge and sends the generated challenge to the LPA 250 as a response.

[0121] In step 705, the LPA 250 transmits the received query to the service provider server 270 through the service provider app 240 to request a digital signature. The address of the service provider server 270 may be preset in the service provider app 240 or the LPA 250, or may be input from the user.

[0122] The service provider server 270 performs a digital signature on the received query in step 707. The digital signature may be performed using a digital certificate and a corresponding key pre-stored in the service provider server 270.

[0123] At step 709, the service provider server 270 sends the generated digital signature to the LPA 250 as a reply through the service provider app 240. The reply can include the digital signature and one or more digital certificates for verifying the digital signature.

[0124] At step 711, the LPA 250 transmits the received digital signature to the eUICC 260 to request verification of the digital signature. The eUICC 260 can send the result of the verification of the digital signature to the LPA 250 as a reply. If the digital signature verification by the eUICC 260 is successful, the LPA 250 considers that the access right of the service provider app 240 has been approved, performs the function called by the service provider app 240 (e.g., downloads a profile from a profile server), and notifies the service provider app 240 or the service provider server 270 of the result of the function.

[0125] Figure 8 An online authentication procedure with assistance from the eUICC is shown to be received by the LPA from the eUICC when the LPA identifies the service provider app by directly accessing the service provider server, according to an embodiment (800).

[0126] Referring to Figure 8 At step 801, the service provider app 240 attempts to call a specific function of the LPA 250. The corresponding access can be transmitted to the LPA 250 by the offline authentication of step 301 of FIG. 2A, and can use the function provided by the terminal 230 as described above with reference to FIG. 2A. Figure 3

[0127] At step 803, the LPA 250 requests the eUICC 260 to generate a challenge. The eUICC can generate the challenge and send the generated challenge to the LPA 250 as a reply.

[0128] At step 805, the LPA 250 directly transmits the received challenge to the service provider server 270 to request a digital signature. The address of the service provider server 270 can be pre-set in the LPA 250, can be transmitted from the service provider app 240 at step 801, or can be input from the user.

[0129] At step 807, the service provider server 270 performs a digital signature with respect to the received challenge. The digital signature can be performed using a digital certificate and a corresponding key pre-stored in the service provider server 270.

[0130] ​At step 809, the service provider server 270 sends the generated digital signature directly to the LPA 250 as a response. The response can include the digital signature and one or more digital certificates for verifying the digital signature.

[0131] At step 811, the LPA 250 transmits the received digital signature to the eUICC 260 to request verification of the digital signature. The eUICC 260 can send the result of the verification of the digital signature to the LPA 250 as a response. If the digital signature verification by the eUICC 260 is successful, the LPA 250 considers that the access right of the service provider app 240 has been approved, performs the function called by the service provider app 240 (e.g., downloads a profile from a profile server), and notifies the service provider app 240 or the service provider server 270 of the result of performing the function.

[0132] Figure 9 It is shown that, according to an embodiment, when the LPA identifies the service provider app by accessing the service provider server via the service provider app, the LPA receives an assisted online authentication procedure from a profile server (900).

[0133] Referring to Figure 9 At step 901, the service provider app 240 attempts to call a specific function of the LPA 250. The corresponding access can be transmitted to the LPA 250 by the offline authentication of step 301 of Figure 3 the function provided by the terminal 230 as described above with reference to FIG. 2A.

[0134] At step 903, the LPA 250 generates a challenge.

[0135] At step 905, the LPA 250 transmits the generated challenge to the service provider server 270 through the service provider app 240 to request a digital signature. The address of the service provider server 270 can be pre-set in the service provider app 240 or the LPA 250, or can be input from the user.

[0136] At step 907, the service provider server 270 obtains a digital signature of the profile server 280 by transmitting the received challenge to the profile server 280. The address of the profile server 280 can be pre-set in the service provider server 270. The digital signature can be performed using a digital certificate and a corresponding key pre-stored in the profile server 280.

[0137] At step 909, the service provider server 270 sends the generated digital signature to the LPA 250 as a reply through the service provider app 240. The reply can include the digital signature and one or more digital certificates for verifying the digital signature.

[0138] At step 911, the LPA 250 attempts to verify the received digital signature. If the digital signature verification is successful, the LPA 250 considers that the access of the service provider app 240 has been approved, performs the function called by the service provider app 240 (e.g., downloads a profile from the profile server), and notifies the service provider app 240 or the service provider server 270 of the result of performing the function.

[0139] Figure 10 An online authentication process with assistance from a profile server is shown according to an embodiment when the LPA identifies a service provider app by directly accessing a service provider server (1000).

[0140] Referring to Figure 10 At step 1001, the service provider app 240 attempts to call a specific function of the LPA 250. The corresponding access can be transmitted to the LPA 250 by Figure 3 the offline authentication of step 301 of FIG. 2A, and can use the function provided by the terminal 230 as described above with reference to FIG. 2A.

[0141] At step 1003, the LPA 250 generates a challenge.

[0142] At step 1005, the LPA 250 directly transmits the generated challenge to the service provider server 270 to request a digital signature. The address of the service provider server 270 can be pre-set in the LPA 250, can be transmitted from the service provider app 240 at step 1001, or can be input from the user.

[0143] At step 1007, the service provider server 270 obtains a digital signature of the profile server 280 by transmitting the received challenge to the profile server 280. The address of the profile server 280 can be pre-set in the service provider server 270. The digital signature can be performed using a digital certificate and a corresponding key pre-stored in the profile server 280.

[0144] At step 1009, the service provider server 270 directly sends the generated digital signature to the LPA 250 as a reply. The reply can include the digital signature and one or more digital certificates for verifying the digital signature.

[0145] At step 1011, the LPA 250 attempts to verify the received digital signature. If the digital signature verification is successful, the LPA 250 considers that the access right of the service provider app 240 has been approved, performs the function called by the service provider app 240 (e.g., downloads a profile from a profile server), and notifies the service provider app 240 or the service provider server 270 of the result of performing the function.

[0146] Figure 11 It is shown according to an embodiment that when the LPA identifies the service provider app by accessing the service provider server via the service provider app, the LPA receives an assisted online authentication procedure from the eUICC and the profile server (1100).

[0147] Referring to Figure 11 At step 1101, the service provider app 240 attempts to call a specific function of the LPA 250. The corresponding access can be transmitted to the LPA 250 by the offline authentication of step 301 of Figure 3 the function provided by the terminal 230 as described above with reference to FIG. 2A.

[0148] At step 1103, the LPA 250 can request the eUICC 260 to generate a challenge. The eUICC 260 can generate the challenge and transmit the generated challenge to the LPA 250 as a response.

[0149] At step 1105, the LPA 250 can transmit the received challenge to the service provider server 270 through the service provider app 240 to request a digital signature. The address of the service provider server 270 can be pre-set in the service provider app 240 or the LPA 250, or can be input from the user.

[0150] At step 1107, the service provider server 270 transmits the received challenge to the profile server 280 to obtain a digital signature of the profile server 280. The address of the profile server 280 can be pre-set in the service provider server 270. The signature can be performed using a digital certificate and a corresponding key pre-stored in the profile server 280.

[0151] At step 1109, the service provider server 270 transmits the generated digital signature to the LPA 250 through the service provider app 240 as a response. The response can include the digital signature and one or more digital certificates for verifying the digital signature.

[0152] At step 1111, the LPA 250 transmits the received digital signature to the eUICC 260 to request verification of the digital signature. The eUICC 260 can transmit the result of the verification of the digital signature to the LPA 250 as a response. If the digital signature verification by the eUICC 260 is successful, the LPA 250 considers that the access right of the service provider app 240 has been approved, performs a function called by the service provider app 240 (e.g., downloads a profile from a profile server), and notifies the service provider app 240 or the service provider server 270 of the result of the performance of the function.

[0153] Figure 12 It is shown that according to an embodiment, when the LPA identifies the service provider app by directly accessing the service provider server, the LPA receives an online authentication procedure (1200) from the eUICC and the profile server for assistance.

[0154] Referring to Figure 12 At step 1201, the service provider app 240 attempts to call a specific function of the LPA 250. The corresponding access can be transmitted to the LPA 250 by Figure 3 the offline authentication of step 301, and can use the function provided by the terminal 230 as described above with reference to FIG. 2A.

[0155] At step 1203, the LPA 250 requests the eUICC 260 to generate a challenge. The eUICC 260 can generate the challenge and transmit the generated challenge to the LPA 250 as a response.

[0156] At step 1205, the LPA 250 directly transmits the received challenge to the service provider server 270 to request a digital signature. The address of the service provider server 270 can be pre-set in the LPA 250, can be transmitted from the service provider app 240 at operation 1201, or can be input from a user.

[0157] At step 1207, the service provider server 270 transmits the received challenge to the profile server 280 to obtain a digital signature of the profile server 280. The address of the profile server 280 can be pre-set in the service provider server 270. The digital signature can be performed using a digital certificate and a corresponding key pre-stored in the profile server 280.

[0158] At step 1209, the service provider server 270 directly transmits the generated digital signature to the LPA 250 as a response. The response can include the digital signature and one or more digital certificates for verifying the digital signature.

[0159] The LPA 250 transmits the received digital signature to the eUICC 260 to request verification of the digital signature at step 1211. The eUICC 260 can transmit the result of the verification of the digital signature to the LPA 250 as a response. If the digital signature verification by the eUICC 260 is successful, the LPA 250 considers that the access authority of the service provider app 240 has been approved, performs a function called by the service provider app 240 (e.g., downloading a profile from a profile server), and informs the service provider app 240 or the service provider server 270 of the result of the performance of the function.

[0160] Figure 13 It is shown that, according to an embodiment, when the LPA identifies the service provider app, the LPA uses an online authentication procedure of a key pre-shared in the service provider app and the profile server (1300).

[0161] Referring to Figure 13 The service provider server 270 can store the same key in the service provider app 240 and the profile server 280.

[0162] At step 1301, when the service provider app 240 attempts to call a specific function of the LPA 250, the service provider app 240 transmits a key included in the service provider app 240 and an operation result using the corresponding key. The corresponding access can be transferred to the LPA 250 by the offline authentication of step 301 of Figure 3 the function provided by the terminal 230 as described above with reference to FIG. 2A.

[0163] At step 1303, the LPA 250 transmits the received key and the operation result using the corresponding key to the profile server 280. The address of the profile server 280 can be pre-stored in the LPA 250, can be transmitted from the service provider app 240 at step 1301, or can be input from a user.

[0164] At step 1305, the profile server 280 can verify the received key or the operation result using the corresponding key using the key stored in the profile server 280.

[0165] At step 1307, the profile server 280 transmits the verification result to the LPA 250 as a response. If the verification result is successful, the LPA 250 considers that the access authority of the service provider app 240 has been approved, performs a function called by the service provider app 240 (e.g., downloading a profile from a profile server), and informs the service provider app 240 or the service provider server 270 of the result of the performance of the function.

[0166] Figure 14 A method (1400) in which the service provider app according to the embodiment allows the LPA to download a profile by successively invoking two specific functions of the LPA is shown.

[0167] Referring to Figure 14 In step 1401, the service provider app 240 transmits an "acquire eUICC information" message to the LPA 250 as a first LPA function call. The "acquire eUICC information" message of step 1401 can be transmitted to the LPA 250 by the method of step 301 of Figure 3 , and can use the functions provided by the terminal 230 as described above with reference to FIG. 2A.

[0168] In step 1403, the LPA 250 online authenticates the access authority of the service provider app 240, for example, according to one of the methods shown in Figure 5 to Figure 13 . Further, although not shown in Figure 14 , the eUICC 260 and / or the profile server 280 can be included in the online authentication process as appropriate, as shown in Figure 5 to Figure 13 .

[0169] In step 1405, the LPA 250 informs the service provider app 240 of the online authentication result. In the case of "acquire eUICC information" as a first LPA function call according to the embodiment, the corresponding online authentication result can be transmitted together with the eUICC information that the LPA 250 has read out from the eUICC 260.

[0170] In step 1407, the service provider app 240 transmits the received eUICC information to the service provider server 270.

[0171] In step 1409, the service provider server 270 prepares a profile to be installed in the eUICC based on the received eUICC information. The preparation of the profile can be performed in association with a specific profile server 280, and as a result of the profile preparation, an activation code for downloading the corresponding profile can be generated.

[0172] In step 1411, the service provider server 270 transmits the generated activation code to the service provider app 240 as a response.

[0173] To deliver the received activation code to the LPA 250, the service provider app 240 delivers a "push activation code" message to the LPA 250 as a second LPA function call at step 1413. The "push activation code" message of step 1413 can be delivered through the same offline authentication as step 1401 described above.

[0174] At step 1415, the LPA 250 re-performs the same online authentication as performed at step 1403. Also, the online authentication procedure regarding the "push activation code" message at step 1415 can include a procedure of delivering the activation code received, for example, at step 1413 and the challenge to the service provider server 270 and requesting a digital signature, which identifies the integrity of the corresponding activation code, as shown in the embodiment of FIG. 14B. Figure 5 to Figure 13

[0175] At step 1417, the LPA 250 informs the service provider app 240 of the online authentication result. In the case of the "push activation code" which is the second LPA function call according to the embodiment, the corresponding online authentication result can be sent as a response after the profile is installed at step 1419.

[0176] At step 1419, the LPA 250 downloads and installs the profile from the profile server 280 using the activation code received at step 1413.

[0177] Figure 15 It is shown that, according to the embodiment, when the service provider app successively calls two specific functions of the LPA, the service provider app replaces the method of online authentication with a timer operation regarding the second access (1500).

[0178] Referring to Figure 15 At step 1501, the service provider app 240 delivers a "get eUICC information" message to the LPA 250 as a first LPA function call. The "get eUICC information" message of step 1501 can be delivered through the offline authentication of step 301 of FIG. 3A, and can be provided using the function of the terminal 230 as described above with reference to FIG. 2A. Figure 3

[0179] At step 1503, the LPA 250 online authenticates the access authority of the service provider app 240 through the service provider server 270, for example, according to one of the embodiments of FIG. 14A. Figure 5 to Figure 13 Also, although not shown in FIG. 14A, the eUICC 260 and / or the profile server 280 can be included in the online authentication procedure according to circumstances, as shown in FIG. 14B. Figure 15 Figure 5 to Figure 13

[0180] ​​​​If the online authentication of step 1503 is successful, the LPA 250 can operate a timer at step 1505 to facilitate the access right verification during the second LPA function call of the corresponding service provider app 240.

[0181] At step 1507, the LPA 250 notifies the service provider app 240 of the online authentication result. In the case of "Get eUICC Information" as the first LPA function call according to this embodiment, the corresponding online authentication result can be transmitted together with the eUICC information that the LPA 250 has read out from the eUICC 260.

[0182] The operations of steps 1507 to 1513 are the same as steps 1405 to 1411 of Figure 14 . Therefore, the repeated description of these steps is omitted.

[0183] In order to transmit the activation code received at step 1513 to the LPA 250, the service provider app 240 transmits a "Push Activation Code" message to the LPA 250 as a second LPA function call at step 1515. The "Push Activation Code" message of step 1515 can be authenticated offline in the same manner as step 1501 described above.

[0184] At step 1517, the LPA 250 identifies whether the second LPA function call is made by the same service provider app 240 and whether it is made before the expiration of the timer operated at step 1505. If the same service provider app 240 calls the function of the LPA 250 a second time, the LPA 250 can consider that the access to the corresponding service provider app 240 is allowed before the expiration of the timer, and can omit the execution of the online authentication process.

[0185] At step 1519, the LPA 250 notifies the service provider app 240 of the identification result at step 1517. In Figure 15 , although the online authentication process is omitted, the online authentication of the second LPA function call can not necessarily be distinguished from the result of the reply, similarly to the embodiment of Figure 14 . Therefore, if necessary, the LPA 250 can operate an additional timer or can extend the operation time of the previous timer for the third LPA function call or subsequent LPA function calls at step 1519. Further, in the case of "Push Activation Code" as the second LPA function call according to this embodiment, the corresponding online authentication result can be transmitted as a reply after the profile is installed at step 1521.

[0186] At step 1521, the LPA 250 downloads and installs the profile from the profile server 280 using the activation code received at step 1515.

[0187] Figure 16 It is shown according to embodiments that when the service provider app continuously invokes two specific functions of the LPA, the service provider app replaces the method of online authentication with token validation for the second access (1600).

[0188] Referring to Figure 16 At step 1601, the service provider app 240 transmits the "get eUICC information" message to the LPA 250 as a first LPA function call. The "get eUICC information" message can be transmitted to the LPA 250 by the offline authentication of step 301, and the function provided by the terminal 230 can be used as described above with reference to FIG. 2A. Figure 3 The "get eUICC information" message of step 1601 can be transmitted to the LPA 250 by the offline authentication of step 301, and the function provided by the terminal 230 can be used as described above with reference to FIG. 2A.

[0189] At step 1603, the LPA 250 authenticates the access right of the service provider app 240 online through the service provider server 270, for example, according to one of the embodiments of Figure 5 to Figure 13 In addition, although not shown in Figure 16 , the eUICC 260 and / or the profile server 280 can be included in the online authentication process according to the situation, as shown in Figure 5 to Figure 13

[0190] If the online authentication of step 1603 has been successful, the LPA 250 issues a token at step 1605 in order to simplify the access right verification during the second LPA function call of the corresponding service provider app 240. The token can be used under the validity limitation such as the following list, but such limitation is not limited thereto:

[0191] - available number of times

[0192] - usage period

[0193] At step 1607, the LPA 250 informs the service provider app 240 of the online authentication result at step 1603. In the case of "get eUICC information" as the first LPA function call according to the present embodiment, the corresponding online authentication result can be transmitted together with the eUICC information that the LPA 250 has read out from the eUICC 260. In addition, at step 1607, the LPA 250 can also transmit the token issued at step 1605 to the service provider app 240.

[0194] The operations of steps 1607 to 1613 are the same as Figure 14 ​Steps 1405 to 1411 are the same as steps 1601 to 1603, and thus, repeated description of these steps is omitted.

[0195] To transfer the activation code received in step 1613 to the LPA 250, the service provider app 240 transmits a "push activation code" message to the LPA 250 as a second LPA function call in step 1615. In step 1615, the service provider app 240 can also transfer the token received in step 1607 to the LPA 250. The "push activation code" message of step 1615 can be authenticated offline in the same manner as step 1601 described above.

[0196] In step 1617, the LPA 250 identifies whether the second LPA function call of step 1615 is caused by the same service provider app 240, and whether the token received in step 1615 is valid by comparing the token with the token issued in step 1605. If the same service provider app 240 calls the function of the LPA 250 using a valid token for the second time, the LPA 250 can consider that the access to the corresponding service provider app 240 has been allowed, and can omit the online authentication process.

[0197] In step 1619, the LPA 250 informs the service provider app 240 of the identification result of step 1617. In Figure 16 In the embodiment, although the online authentication process is omitted, the online authentication of the second LPA function call can not necessarily be distinguished from the result of the reply, similar to Figure 14 Thus, if necessary, the LPA 250 can issue a new token or update the validity of the previously issued token for a third LPA function call or a subsequent LPA function call in step 1619. Further, in the case of the "push activation code" as the second LPA function call according to the present embodiment, the corresponding online authentication result can be transmitted as a reply after the profile is installed in step 1621.

[0198] In step 1621, the LPA 250 downloads and installs the profile from the profile server 280 using the activation code received in step 1613.

[0199] Figure 17 A terminal according to an embodiment is shown.

[0200] Referring to Figure 17 , the terminal 1700 includes a transceiver 1710, a controller 1720, and a UICC 1730. The UICC 1730 can be inserted into the terminal 1700 or can be embedded in the terminal 1700.

[0201] The transceiver 1710 can transmit and receive signals, information, and data.

[0202] The controller 1720 can control the overall operation of the terminal 1700, for example, according to the method shown in FIG. 17. Figure 3 to Figure 16

[0203] Further, the UICC 1730 can download a profile and install the downloaded profile. Further, the UICC 1730 can manage a profile. The UICC 1730 can operate under the control of the controller 1720. Further, the UICC 1730 can include a processor or controller for installing a profile, or can have an application installed therein.

[0204] For example, in a wireless communication system according to an embodiment of the disclosure, the terminal 1700 can include a controller 1720 for controlling a second software to invoke a function of a first software and for preparing a signature request message (challenge) for authority verification of the second software, and a transceiver 1710 for transmitting the signature request message to a service provider server to request a digital signature and receiving the digital signature from the service provider server.

[0205] Further, the controller 1720 can further include a determination unit for verifying the digital signature using a digital certificate. If the digital signature verification by the service provider server is successful, the controller 1720 and the determination unit can thereafter omit additional authority verification for the second software.

[0206] In addition, the terminal 1700 can include a controller 1720 for controlling an eUICC, and a transceiver 1710 for transmitting a profile request message to a profile server SM-DP+ and receiving a profile downloaded from the profile server.

[0207] Figure 18 A server according to an embodiment is shown. For example, Figure 18 The server 1800 can be a profile server or a service provider server.

[0208] Referring to Figure 18 , the server 1800 includes a transceiver 1810 and a controller 1820.

[0209] The transceiver 1810 can transmit and receive signals, information, and data. For example, the transceiver 1810 can communicate with a terminal or another server (or network entity) such that the transceiver 1810 receives a request from the terminal and transmits a profile and a digital signature to the terminal.

[0210] The controller 1820 can control the overall operation of the server 1800, for example, according to the method shown in FIG. 18. Figure 3 to Figure 16 ​The controller 1820 of the server 1800 can control the entire operation of the server 1800 according to the method shown in FIG. 18.

[0211] For example, if the server 1800 is a service provider server in a wireless communication system according to an embodiment of the disclosure, the server 1800 can include a controller 1820 for receiving a signature request message from a terminal or first software or second software included in the terminal, determining whether a digital signature can be generated, and generating the digital signature. In addition, if the digital signature cannot be generated, the server 1800 can transmit the signature request message to a profile server using the controller 1820 and the transceiver 1810. The server 1800 can receive the digital signature from the profile server, or can transmit the digital signature to the terminal or the first software or the second software included in the terminal.

[0212] According to the above-described embodiments of the disclosure, if the second software intends to call a function of the LPA, the LPA of the terminal can identify whether the second software is verified software in the terminal, and can identify the access authority of the second software through the network server. Accordingly, the LPA can prevent unverified third software from accessing the LPA, and can inform the network server that the second software intends to access the LPA.

[0213] In addition, if the second software intends to call a function of the LPA twice or more, the LPA of the terminal can allow the second software to access according to the above-described procedure regarding initial access, and can omit the identification of the access authority of the second software through the network server regarding the twice or more accesses. Accordingly, in the case where verified software requests consecutive LPA access, the LPA can reduce the burden of access authority verification, and can shorten the verification time.

[0214] Although various embodiments of the disclosure are described above in the specification and drawings, these are merely examples provided to help understand the disclosure, and are not intended to limit the scope of the disclosure. Therefore, it is obvious to those skilled in the art to which the disclosure pertains that various modifications can be made based on the technical idea of the disclosure.

[0215] In addition, the respective embodiments can be combined to operate as needed. For example, parts of different embodiments of the disclosure can be combined to operate a base station and a terminal. In addition, although the above-described embodiments are provided based on an LTE / LTE-Advanced (LTE-A) system, other modifications based on the technical idea of the embodiments can also be applied to other systems, such as a 5G or New Radio (NR) system.

[0216] While the disclosure has been particularly shown and described with reference to certain embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details can be made therein without departing from the spirit and scope of the disclosure as defined by the following claims and their equivalents.

Claims

1. A method performed by an embedded universal integrated circuit card (eUICC) included in a terminal in a wireless communication system, the terminal having an application authorized by an operator, the method comprising: receiving, from a local profile assistant (LPA) installed in the terminal, a first function call associated with an inquiry of the eUICC, the first function call being received based on a first request from the application authorized by the operator; sending a query generated based on the first function call to the LPA; receiving, from the LPA, a second function call associated with a server signature, wherein the second function call includes the server signature generated in response to the query and is received based on a second request from the application authorized by the operator; as well as A request to verify the server's signature is received from the LPA.

2. The method according to claim 1, in, The query is passed from the LPA to the application, and Wherein, a first message including the query is sent from the application to the server.

3. The method according to claim 2, in, sending a second message including the server's signature from the server to the application in response to the first message, and The second request including the signature of the server is sent from the application to the LPA based on the second message.

4. The method according to claim 1, wherein The signature is generated by the server based on a digital certificate.

5. The method according to claim 1, wherein A process for downloading a profile is performed based on a result of the verification.

6. A method performed by a terminal in a wireless communication system, the terminal including an embedded universal integrated circuit card (eUICC) and having an application authorized by an operator and a local profile assistant (LPA) installed in the terminal, the method comprising: receiving, by the LPA, from the application, a first request for querying the eUICC; sending, by the LPA, to the eUICC, a first function call associated with a query of the eUICC; receiving, by the LPA from the eUICC, the query generated based on the first function call; The application sends a first message including the query to the server; receiving, by the application, a second message from the server, the second message including a signature generated by the server in response to the challenge; Sending, by the LPA, a second function call including a signature of the server to the eUICC; as well as A request for verifying the signature of the server is received by the eUICC from the LPA.

7. The method according to claim 6, wherein The query is passed from the LPA to the application.

8. The method according to claim 7, wherein: The application receives the second message from the server in response to the first message, and Wherein, a second request including the signature of the server is sent from the application to the LPA based on the second message.

9. The method according to claim 6, wherein: The signature is generated by the server based on a digital certificate.

10. The method according to claim 6, wherein: A process for downloading a profile is performed based on a result of the verification.

11. An embedded universal integrated circuit card (eUICC) included in a terminal in a wireless communication system, the terminal having an application authorized by an operator, the eUICC being configured to: receiving, from a local profile assistant (LPA) installed in the terminal, a first function call associated with an inquiry of the eUICC, the first function call being received based on a first request from the application authorized by the operator; sending a query generated based on the first function call to the LPA; receiving, from the LPA, a second function call associated with a server signature, wherein the second function call includes the server signature generated in response to the query and is received based on a second request from the application authorized by the operator; as well as A request to verify the server's signature is received from the LPA.

12. The eUICC according to claim 11, wherein: The query is passed from the LPA to the application, and Wherein, a first message including the query is sent from the application to the server.

13. The eUICC according to claim 12, wherein: sending a second message including the server's signature from the server to the application in response to the first message, and The second request including the signature of the server is sent from the application to the LPA based on the second message.

14. The eUICC according to claim 11, wherein: The signature is generated by the server based on a digital certificate.

15. The eUICC according to claim 11, wherein: A process for downloading a profile is performed based on a result of the verification.

16. A terminal including an embedded universal integrated circuit card (eUICC) in a wireless communication system, the terminal having an application authorized by an operator and a local profile assistant (LPA) installed in the terminal, the terminal comprising: a transceiver configured to transmit or receive a signal; as well as A controller configured to: receiving, by the LPA, from the application, a first request for querying the eUICC; sending, by the LPA, to the eUICC, a first function call associated with a query of the eUICC; receiving, by the LPA from the eUICC, the query generated based on the first function call; The application sends a first message including the query to the server; receiving, by the application, a second message from the server, the second message including a signature generated by the server in response to the challenge; Sending, by the LPA, a second function call including a signature of the server to the eUICC; as well as A request for verifying the signature of the server is received by the eUICC from the LPA.

17. The terminal according to claim 16, wherein: The query is passed from the LPA to the application. The terminal according to claim 17 , wherein: The application receives the second message from the server in response to the first message, and Wherein, a second request including the signature of the server is sent from the application to the LPA based on the second message. The terminal according to claim 16 , wherein: The signature is generated by the server based on a digital certificate.

20. The terminal according to claim 16, wherein: A process for downloading a profile is performed based on a result of the verification.

Images