Electronic device, method, and recording medium for authenticating embedded subscriber identity module

Abstract

The present disclosure relates to an electronic device, a method, and a recording medium for performing authentication on an eSIM. The electronic device may comprise: an eSIM including an internal memory and configured to store a profile in the internal memory; a memory including one or more recording media and storing instructions; and a CP including a processing circuit. Sharing information may be shared between the CP and the eSIM. When the instructions are individually or collectively executed by at least one processor including the CP, the instructions may cause the electronic device (101) to perform at least one operation. The at least one operation may comprise an operation of, in response to an authentication request, authenticating the eSIM by using first shared information obtained by the CP and second shared information stored in the eSIM. The at least one operation may comprise an operation of restricting the use of the CP according to whether authentication for the eSIM is successful.

Description

Electronic device, method, and recording medium for authenticating an embedded subscriber identity module

[0001] The present disclosure relates to an electronic device, method, and recording medium for performing authentication for an embedded subscriber identity module.

[0002] In a wireless network environment, a subscriber identity module (SIM) may be essential for electronic devices such as smartphones, wearable devices, or tablets to access a carrier's network for subscriber authentication. The electronic devices may be embedded with a SIM card (e.g., a universal SIM (USIM)) or a chip (e.g., an embedded SIM (eSIM)).

[0003] Electronic devices can use the profile stored on the SIM card to perform authentication procedures to access networks provided by a mobile network operator (MNO). If a profile provided by a specific carrier is not stored on the SIM card, the electronic device may not be permitted to access that network.

[0004] A USIM, which can be removed and installed in a slot in an electronic device, allows users to change the electronic device they are using without any special authentication procedures. Therefore, electronic devices using USIMs may have some security vulnerabilities. In contrast, an eSIM, installed on the device's internal board, requires a registration process to install or store a profile, making it relatively more secure than a USIM. However, even with eSIMs, there is a risk of the board containing the eSIM being misused in another electronic device.

[0005] The above information may be provided as background information to aid in understanding this document. None of the above is claimed to be prior art related to this document or can be used to determine prior art.

[0006] According to one embodiment, an electronic device may include an embedded subscriber identity module (eSIM) including an internal memory and configured to store a profile in the internal memory. The electronic device may include one or more recording media and a memory storing instructions. The electronic device may include a communication processor (CP) including processing circuitry, wherein shared information is shared between the CP and the eSIM. When the instructions are individually or collectively executed by at least one processor including the CP, the instructions may cause the electronic device to perform at least one operation. The at least one operation may include performing authentication on the eSIM using first shared information acquired by the CP and second shared information stored in the eSIM in response to an authentication request. The at least one operation may include restricting use of the CP based on whether authentication on the eSIM is successful.

[0007] According to one embodiment, a storage medium storing computer-readable instructions may be provided. The instructions, when executed by at least a portion of at least one processor, including a communication processor (CP) included in an electronic device, may cause the electronic device to perform at least one operation. The at least one operation may include performing authentication on an embedded subscriber identity module (eSIM) using first shared information obtained by the CP and second shared information stored in the eSIM in response to an authentication request. The at least one operation may include restricting use of the CP based on whether authentication on the eSIM is successful.

[0008] According to one embodiment, a method for authenticating an electronic device may include, in response to an authentication request, performing authentication on an embedded subscriber identity module (eSIM) using first shared information acquired by a communication processor (CP) and second shared information stored in the eSIM. The authentication method may include an operation for restricting use of the CP based on whether authentication on the eSIM is successful.

[0009] In connection with the description of the drawings, the same or similar reference numerals may be used for the same or similar components.

[0010] FIG. 1 is a block diagram of an electronic device within a network environment according to various embodiments.

[0011] FIG. 2a, FIG. 2b or FIG. 2c are exemplary installation diagrams of a subscriber identification module in an electronic device according to various embodiments.

[0012] FIG. 3 is a block diagram of an exemplary electronic device capable of performing the operations described in this document.

[0013] FIG. 4 is a block diagram of an exemplary electronic device capable of performing operations according to various embodiments described herein.

[0014] FIG. 5A is a control flowchart for performing binding in an electronic device according to one embodiment.

[0015] FIG. 5b is a control flowchart for performing authentication in an electronic device according to one embodiment.

[0016] FIG. 6A is a signal flow diagram for performing binding in an electronic device according to one embodiment.

[0017] FIG. 6b is a signal flow diagram for performing authentication in an electronic device according to one embodiment.

[0018] FIG. 7A is a signal flow diagram for performing binding in an electronic device according to one embodiment.

[0019] FIG. 7b is a signal flow diagram for performing authentication in an electronic device according to one embodiment.

[0020] FIG. 8A or FIG. 8B is a block diagram of an exemplary electronic device capable of performing operations according to one embodiment.

[0021] FIG. 9 is a signal flow diagram for performing a binding procedure in an electronic device according to one embodiment.

[0022] FIG. 10 is a signal flow diagram for performing an authentication procedure in an electronic device according to one embodiment.

[0023] FIG. 11 is a signal flow diagram for performing an authentication procedure in an electronic device according to one embodiment.

[0024] FIG. 12A is a control flowchart for performing binding in an electronic device according to one embodiment.

[0025] FIG. 12b is a control flowchart for performing authentication in an electronic device according to one embodiment.

[0026] FIG. 13 is a block diagram of an exemplary electronic device capable of performing operations according to one embodiment.

[0027] FIG. 14 is a signal flow diagram for generating a shared key included in a binding procedure in an electronic device according to one embodiment.

[0028] FIG. 15 is a signal flow diagram for encrypting and storing a shared key included in a binding procedure in an electronic device according to one embodiment.

[0029] FIG. 16 is a signal flow diagram for binding a shared key included in a binding procedure in an electronic device according to one embodiment.

[0030] FIG. 17 is a signal flow diagram for performing an authentication procedure in an electronic device according to one embodiment.

[0031] FIG. 18 is a signal flow diagram for performing an authentication procedure in an electronic device according to one embodiment.

[0032] FIG. 19 is a signal flow diagram for performing authentication for multiple eSIMs in an electronic device according to one embodiment.

[0033] FIG. 20 is a signal flow diagram for performing authentication for multiple eSIMs in an electronic device according to one embodiment.

[0034] FIG. 21 is an example diagram of a user interface that indicates whether network access is available based on authentication of an eSIM in an electronic device, according to one embodiment.

[0035] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings so that those skilled in the art can easily implement the present disclosure. However, the present disclosure may be implemented in various different forms and is not limited to the embodiments described herein. In connection with the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Furthermore, in the drawings and related descriptions, descriptions of well-known functions and configurations may be omitted for clarity and conciseness.

[0036] FIG. 1 is a block diagram of an electronic device (101) within a network environment (100) according to various embodiments.

[0037] Referring to FIG. 1, in a network environment (100), an electronic device (101) may communicate with an electronic device (102) via a first network (198) (e.g., a short-range wireless communication network), or may communicate with an electronic device (104) or a server (108) via a second network (199) (e.g., a long-range wireless communication network). According to one embodiment, the electronic device (101) may communicate with the electronic device (104) via the server (108). According to one embodiment, the electronic device (101) may include a processor (120), a memory (130), an input module (150), an audio output module (155), a display module (160), an audio module (170), a sensor module (176), an interface (177), a connection terminal (178), a haptic module (179), a camera module (180), a power management module (188), a battery (189), a communication module (190), a subscriber identification module (196), or an antenna module (197). In some embodiments, the electronic device (101) may omit at least one of these components (e.g., the connection terminal (178)), or may have one or more other components added. In some embodiments, some of these components (e.g., the sensor module (176), the camera module (180), or the antenna module (197)) may be integrated into one component (e.g., the display module (160)).

[0038] The processor (120) may, for example, execute software (e.g., a program (140)) to control at least one other component (e.g., a hardware or software component) of the electronic device (101) connected to the processor (120) and perform various data processing or operations. According to one embodiment, as at least a part of the data processing or operations, the processor (120) may store commands or data received from other components (e.g., a sensor module (176) or a communication module (190)) in a volatile memory (132), process the commands or data stored in the volatile memory (132), and store the resulting data in a non-volatile memory (NV) (134). According to one embodiment, the processor (120) may include a main processor (121) (e.g., a central processing unit or an application processor) or an auxiliary processor (123) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor) that can operate independently or together with the main processor (121). For example, when the electronic device (101) includes the main processor (121) and the auxiliary processor (123), the auxiliary processor (123) may be configured to use less power than the main processor (121) or to be specialized for a given function. The auxiliary processor (123) may be implemented separately from the main processor (121) or as a part thereof.

[0039] The auxiliary processor (123) may control at least a portion of functions or states associated with at least one component (e.g., a display module (160), a sensor module (176), or a communication module (190)) of the electronic device (101), for example, on behalf of the main processor (121) while the main processor (121) is in an inactive (e.g., sleep) state, or together with the main processor (121) while the main processor (121) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (123) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (180) or a communication module (190)). In one embodiment, the auxiliary processor (123) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, in the electronic device (101) itself where artificial intelligence is performed, or can be performed through a separate server (e.g., server (108)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0040] The memory (130) can store various data used by at least one component (e.g., the processor (120) or the sensor module (176)) of the electronic device (101). The data can include, for example, software (e.g., the program (140)) and input data or output data for commands related thereto. The memory (130) can include a volatile memory (132) or a nonvolatile memory (134). For example, the nonvolatile memory (134) can include a built-in memory (136) or an external memory (138).

[0041] The program (140) may be stored as software in memory (130) and may include, for example, an operating system (142), middleware (144), or an application (146).

[0042] The input module (150) can receive commands or data to be used in a component of the electronic device (101) (e.g., a processor (120)) from an external source (e.g., a user) of the electronic device (101). The input module (150) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0043] The audio output module (155) can output audio signals to the outside of the electronic device (101). The audio output module (155) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. In one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

[0044] The display module (160) can visually provide information to an external party (e.g., a user) of the electronic device (101). The display module (160) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling the device. In one embodiment, the display module (160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0045] The audio module (170) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to one embodiment, the audio module (170) can acquire sound through the input module (150), output sound through the sound output module (155), or an external electronic device (e.g., electronic device (102)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (101).

[0046] The sensor module (176) can detect the operating status (e.g., power or temperature) of the electronic device (101) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (176) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0047] The interface (177) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (101) with an external electronic device (e.g., the electronic device (102)). In one embodiment, the interface (177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0048] The connection terminal (178) may include a connector through which the electronic device (101) may be physically connected to an external electronic device (e.g., electronic device (102)). According to one embodiment, the connection terminal (178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0049] A haptic module (179) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. In one embodiment, the haptic module (179) can include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0050] The camera module (180) can capture still images and videos. According to one embodiment, the camera module (180) may include one or more lenses, image sensors, image signal processors, or flashes.

[0051] The power management module (188) can manage power supplied to the electronic device (101). According to one embodiment, the power management module (188) can be implemented, for example, as at least a part of a power management integrated circuit (PMIC).

[0052] A battery (189) may power at least one component of the electronic device (101). In one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0053] The communication module (190) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (101) and an external electronic device (e.g., electronic device (102), electronic device (104), or server (108)), and the performance of communication through the established communication channel. The communication module (190) may operate independently from the processor (120) (e.g., application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (190) may include a wireless communication module (192) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (194) (e.g., a local area network (LAN) communication module, or a power line communication module). Among these communication modules, the corresponding communication module can communicate with an external electronic device (104) via a first network (198) (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network (199) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules can be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (192) can verify or authenticate the electronic device (101) within a communication network such as the first network (198) or the second network (199) by using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (196).

[0054] The wireless communication module (192) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). The NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and connection of multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (192) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (192) can support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (192) can support various requirements specified in the electronic device (101), an external electronic device (e.g., the electronic device (104)), or a network system (e.g., the second network (199)). According to one embodiment, the wireless communication module (192) can support a peak data rate (e.g., 20 Gbps or more) for eMBB realization, a loss coverage (e.g., 164 dB or less) for mMTC realization, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 1 ms or less for round trip) for URLLC realization.

[0055] The antenna module (197) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). In one embodiment, the antenna module (197) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). In one embodiment, the antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (198) or the second network (199), may be selected from the plurality of antennas, for example, by the communication module (190). A signal or power may be transmitted or received between the communication module (190) and an external electronic device via the selected at least one antenna. In some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (197).

[0056] According to various embodiments, the antenna module (197) may form a mmWave antenna module. According to one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high-frequency band.

[0057] At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

[0058] According to one embodiment, commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) via a server (108) connected to a second network (199). Each of the external electronic devices (102 or 104) may be the same or a different type of device as the electronic device (101). According to one embodiment, all or part of the operations executed in the electronic device (101) may be executed in one or more of the external electronic devices (102, 104, or 108). For example, when the electronic device (101) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (101) may, instead of or in addition to executing the function or service itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (101). The electronic device (101) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (101) may provide an ultra-low latency service by using distributed computing or mobile edge computing, for example. In another embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server utilizing machine learning and / or a neural network. According to one embodiment, the external electronic device (104) or the server (108) may be included in the second network (199).The electronic device (101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

[0059] FIG. 2a, FIG. 2b or FIG. 2c are exemplary diagrams of installation of a subscriber identity module (SIM) in an electronic device (e.g., the electronic device (101) of FIG. 1) according to various embodiments.

[0060] Referring to FIG. 2A, FIG. 2B, or FIG. 2C, an electronic device (101) may include at least one SIM. The at least one SIM may have a profile installed or stored therein, which is connection information for the electronic device (101) to access a specific network. The at least one SIM included in the electronic device (101) may be an embedded SIM (eSIM). The eSIM is a type of programmable SIM card directly embedded in the device. The eSIM may be configured with software installed in an embedded UICC (eUICC) chip permanently connected to the device, instead of a universal SIM (USIM) configured as an integrated circuit in a universal integrated circuit card (UICC). The eSIM may be permanently mounted on a product during a process for releasing the product before the release. The eSIM does not require a relatively bulky connector compared to a USIM, and thus, in addition to design flexibility, may improve stability and network security.

[0061] According to one example, the electronic device (101a) may have one embedded SIM (eSIM) (201a) mounted on one internal board (e.g., main board) (200a) (e.g., see FIG. 2a). The one eSIM (201a) may be mounted on the internal board (200a) so that it cannot be physically removed from the internal board (200a). The electronic device (101a) may download a profile for accessing a communication network (111a) and install or store it on the one eSIM (201a).

[0062] According to one example, the electronic device (101b) may be coupled so that multiple SIMs (e.g., a first SIM (201b), a second SIM (203b)) are mounted on one internal board (e.g., a main board) (200b) or are electrically connected via a predetermined connector (e.g., see FIG. 2b). For example, at least one SIM (e.g., the first SIM (201b)) among the multiple SIMs (201b, 203b) may be an eSIM mounted on the internal board (200a) so that it is impossible to physically remove it from the internal board (200a).

[0063] For example, the first SIM (201b) may be an eSIM, and the second SIM (203b) may be a USIM. The second SIM (203b), which is a USIM, may be inserted into a mounting slit provided in the electronic device (101b) in the form of a card and electrically connected to the internal board (200b). The electronic device (101b) may download a profile for accessing the first communication network (111b) and install or store it in the first SIM (201b), which is an eSIM. The electronic device (101b) may access the second communication network (113b) using the profile recorded in the second SIM (203b), which is a USIM, without having to download and install the profile.

[0064] For example, both the first SIM (201b) and the second SIM (203b) may be eSIMs. The electronic device (101b) may download a profile for accessing the first communication network (111b) and install or store it in the first SIM (201b), which is an eSIM. The electronic device (101b) may download a profile for accessing the second communication network (113b), and install or store it in the second SIM (203b), which is an eSIM.

[0065] According to one example, the electronic device (101b) may be coupled such that a plurality of SIMs (e.g., a first SIM (201b), a second SIM (203b)) are mounted one-to-one on a plurality of internal boards (e.g., a main board, a sub-board) (210c, 220c) or are electrically connected through a predetermined connector (e.g., see FIG. 2c). For example, at least one SIM (e.g., the first SIM (211c)) among the plurality of SIMs (211c, 221c) may be an eSIM mounted on one of the plurality of internal boards (e.g., the first internal board (210c)) so as to be physically impossible to remove.

[0066] For example, the first SIM (211c) may be an eSIM, and the second SIM (221c) may be a USIM. The first SIM (211c), which is an eSIM, may be mounted on the first internal board (210c) so as to be physically impossible to remove. The second SIM (221c), which is a USIM, may be inserted into a mounting slit provided in the electronic device (101c) in the form of a card and electrically connected to the second internal board (220c). The electronic device (101c) may download a profile for accessing the first communication network (111c) and install or store the profile in the first SIM (211c), which is an eSIM. The electronic device (101c) may access the second communication network (113c) using the profile recorded in the second SIM (221c), which is a USIM, without having to download and install the profile.

[0067] For example, both the first SIM (211c) and the second SIM (221c) may be eSIMs. The electronic device (101c) may download a profile for accessing the first communication network (111c) and install or store it in the first SIM (211c), which is an eSIM. The electronic device (101b) may download a profile for accessing the second communication network (113c), and install or store it in the second SIM (221c), which is an eSIM.

[0068] The technical configurations and / or operations related to the various embodiments described later in this document may be applied substantially identically or with simple modifications to an electronic device (101a, 101b, or 101c) having at least one SIM installed as suggested by FIG. 2a, FIG. 2b, or FIG. 2c. In addition, even if not suggested by FIG. 2a, FIG. 2b, or FIG. 2c, they may be applied substantially identically or with simple modifications to eSIMs implemented in various forms. For example, as suggested by FIG. 2b, a binding procedure (e.g., binding procedure (410) of FIG. 4) and / or an authentication procedure (e.g., authentication procedure (420) of FIG. 4) that can be applied to an electronic device (101b or 101c) in which two eSIMs are mounted on one internal board (200b), or in which one eSIM is independently mounted on each of multiple internal boards (211c, 221c), as suggested by FIG. 2c, will be described in more detail below. The binding procedure (410) can be performed, for example, during a mass production process before product launch. The authentication procedure (420) can be performed, for example, after the binding procedure (410) has been completed during the mass production process. The authentication procedure (420) can be performed, for example, at the time when the CP (313) boots up after product launch. The above authentication procedure (420) may be performed, for example, when the eSIM (350) is soft reset. The above authentication procedure (420) may be performed, for example, when the eSIM (350) is refreshed. In the description of various embodiments to be described below, the detailed operations will be described by distinguishing between the binding procedure (410) and the authentication procedure (420). However, as defined above, all operations according to the binding procedure (410) and the authentication procedure (420) may be performed continuously, or may be performed separately at different times.

[0069] FIG. 3 is a block diagram of an exemplary electronic device (e.g., electronic device (101) of FIG. 1) capable of performing the operations described in this document.

[0070] Referring to FIG. 3, the electronic device (101) may be one of various forms of electronic devices, such as a laptop, smartphones having various form factors (e.g., a bar-type smartphone, a foldable-type smartphone, or a slider-type (or rollable) smartphone), tablets, cellular phones, wearable devices (e.g., a smart watch, a smart ring, a Bluetooth earphone, or a Bluetooth headset), and other similar computing devices. The components, their relationships, and their functions illustrated in FIG. 3 are merely exemplary and do not limit the implementations described or claimed in this document. The electronic device (101) may be referred to as a mobile device, a user device, a multi-function device, a portable device, or a server.

[0071] The electronic device (101) includes at least one processor (310) (hereinafter, referred to as 'processor (310)') (e.g., processor (120) of FIG. 1), at least one memory (340) (hereinafter, referred to as 'memory (340)') (e.g., memory (130) of FIG. 1), at least one display (330) (hereinafter, referred to as 'display (330)'), at least one communication circuit (320) (hereinafter, referred to as 'communication circuit (320)') (e.g., communication module (190) of FIG. 1), and / or at least one eSIM (350) (hereinafter, referred to as 'eSIM (350)') (e.g., at least one of eSIM (201a) of FIG. 2a, the first or second SIM (201b, 203b) of FIG. 2b, or the first or second SIM (211c, 221c) may include components that include at least one of the following. The components are merely exemplary. For example, the electronic device (101) may include other components (e.g., power management integrated circuitry (PMIC), audio processing circuitry, an antenna, a rechargeable battery, or an input / output interface). For example, some components may be omitted from the electronic device (101). For example, some components may be integrated into one component.

[0072] The processor (310) may be implemented as one or more IC (integrated circuit (or circuitry)) chips and may perform various data processing. The processor (310) may include at least one electrical circuit and may individually or collectively perform distributed processing of instructions (or programs, data, etc.) stored in the memory (340). The processor (310) may include a processor assembly including one or more processing circuits. The processor (310) may include any processing circuit that is operative to control the performance and operations of one or more components (e.g., the memory (340), the display (330), the communication circuit (320), and / or the eSIM (350)) of the electronic device (101). For example, the processor (310) (e.g., an application processor (AP) (311) or a communication processor (CP) (313)) may be implemented as a system on chip (SoC) (e.g., a single chip or chipset). For example, the processor (310) may be implemented as a plurality of cores (or at least one core circuit), a plurality of chips, or a plurality of chipsets. For example, the processor (310) may include one or more processing circuits. For example, the processor (310) may include one or more processing circuits configured to individually and / or collectively perform various functions of the present disclosure. As a non-limiting example, at least a portion of the processor (310) may be included in a first chip of the electronic device (101), and at least another portion of the processor (310) may be included in a second chip of the electronic device (101) that is different from the first chip of the electronic device (101).

[0073] The processor (310) can cause other components of the electronic device (101) to perform various operations by executing instructions stored in the memory (340).

[0074] The AP (311) included in the processor (310) may be configured to control related components based on the execution of instructions stored in the memory (340) (e.g., volatile memory (e.g., volatile memory (132) of FIG. 1) and / or nonvolatile memory (e.g., nonvolatile memory (134) of FIG. 1)) due to installation of an application. The AP (311) may include nonvolatile memory therein. The AP (311) may record data to be maintained in the nonvolatile memory even when the power supply is cut off. The AP (311) may read out information recorded in the nonvolatile memory when necessary and provide it to the related components.

[0075] The CP (313) included in the processor (310) may be configured to process data acquired from a related component into a format suitable for transmitting the data to another electronic device through the communication circuit (320), or to process data acquired from another electronic device through the communication circuit (320) into a format suitable for processing by the related component.

[0076] The processor (310) may include, for example, a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit (NPU), an image signal processor (ISP), a display controller, a memory controller, a storage controller, and / or a sensor interface. These components of the processor (310) are merely exemplary. For example, the processor (310) may further include other components. For example, some components of the processor (310) may be omitted from the processor (310). For example, some components of the processor (310) may be included as separate components of the electronic device (101) outside the processor (310). For example, some components of the processor (310) (e.g., a memory controller) may be included within other components (e.g., at least a portion of the memory (340), an interface (e.g., available for connection to at least one component of the electronic device (101)), and / or a display (330).

[0077] The memory (340) may include one or more storage media (or one or more storage devices). For example, the memory (340) may include a memory assembly including one or more storage media. For example, the one or more storage media may include permanent memory (e.g., non-volatile memory) such as a hard drive, flash memory, read-only memory (ROM), semi-permanent memory (e.g., volatile memory) such as random access memory (RAM), any other suitable type of storage (or storage assembly), or any combination thereof. The memory (340) may include a cache memory, which is one or more different types of memory used to temporarily store data for a function or feature of the electronic device (101). As a non-limiting example, the cache memory may be included within the processor (310). The memory (340) may be fixedly embedded within the electronic device (101) or incorporated into one or more suitable types of components (e.g., a subscriber identity module (SIM) card and / or a secure digital (SD) card) that may be repeatedly inserted into and removed from the electronic device (101).

[0078] The memory (340) may store one or more software applications, such as an operating system (or system) software application, a firmware software application, a driver software application, a plug-in (e.g., add-in, add-on, and / or applet) software application, and / or any other suitable software applications. For example, the one or more software applications may include instructions executable by the processor (310). For example, the memory (340) may store instructions callable by an application programming interface (API). For example, the memory (340) may store instructions within a library.

[0079] The eSIM (350) may take the form of a programmable SIM card directly embedded in the electronic device (101). The eSIM (350) may be configured with software installed in an eUICC chip permanently connected to the electronic device (101) instead of a USIM configured as an integrated circuit in the UICC. The eSIM (350) may be permanently mounted on a product during a process for releasing the product before the model is released. The eSIM (350) may improve stability and network security in addition to design flexibility because it does not require a relatively bulky connector compared to a USIM. The eSIM (350) may include a recording medium (351) for installing or storing a profile, which is access information for accessing a specific network.

[0080] FIG. 4 is a block diagram of an exemplary electronic device (e.g., electronic device (101) of FIG. 1) capable of performing operations according to various embodiments described in this document.

[0081] Referring to FIG. 4, the electronic device (101) may provide a procedure for authentication of the eSIM (350) between a CP (e.g., CP (313) of FIG. 3) and an eSIM (e.g., eSIM (350) of FIG. 3). As an example, the procedure for authentication of the eSIM (350) may include a binding procedure (410) or an authentication procedure (420).

[0082] The electronic device (101) may perform a binding procedure (410) in response to a binding request. The binding request may occur, for example, at a specific point in the process for product shipment prior to mass production of the electronic device (101). The binding request may occur, for example, during product initialization. The binding request may occur, for example, during product repair. The binding request may occur, for example, when a network to be accessed is changed. The binding request may occur, for example, according to conditions set at the time of product shipment (e.g., binding execution cycle).

[0083] In one example, the electronic device (101) may perform a binding procedure (410) to allow a shared value or a shared key to be shared between the CP (313) and the eSIM (350). The shared value or shared key to be shared between the CP (313) and the eSIM (350) by the electronic device (101) performing the binding procedure (410) may be collectively referred to as 'shared information'. The shared information to be used in this document may be understood as either a shared value or a shared key depending on the authentication method for the eSIM (350). For example, when authenticating an eSIM (350) based on a non-encryption method, the shared value may be the shared information. For example, when authenticating an eSIM (350) based on an encryption method, the shared key may be the shared information. For example, the shared key may be generated by encrypting the shared value based on a specific encryption algorithm for key generation.

[0084] The shared information may be used directly or indirectly for authentication during encryption / decryption of the CP (313) or eSIM (350). For example, the shared information may be a non-accessible shared key (CP-eSIM) to be directly transmitted between the CP (313) and the eSIM (350) during authentication of the eSIM (350). The non-accessible shared key may be a shared key stored in a physically inaccessible memory area. For example, the shared key may be a secret key that the CP (313) and / or the eSIM (350) use to encrypt or decrypt a nonce during authentication of the eSIM (350). The nonce may be a number used once for authentication. The nonce may be randomly generated, for example, using a random number generator. In this document, the shared information will be used in a technical sense to collectively refer to the shared value or the shared key.

[0085] The electronic device (101) may perform an authentication procedure (420) in response to an authentication request. The authentication request may occur, for example, in response to the booting of the CP (313). The authentication request may occur, for example, in response to a soft reset of the eSIM (350). The authentication request may occur, for example, in response to a refresh of the eSIM (350). The refresh operation may be an operation for changing information (e.g., a profile) stored in the eSIM (350).

[0086] In one example, the electronic device (101) may perform an authentication procedure (420) to check whether the shared information acquired for performing the authentication procedure in the CP (313) and the eSIM (350) matches. For example, if the information (e.g., a shared value or a temporary value) acquired in response to the CP (313) matches the information (e.g., a shared value or a temporary value) acquired in response to the eSIM (350), the electronic device (101) may allow access to a network (e.g., a communication network (111a) of FIG. 2A) and / or use of the CP (313). For example, the electronic device (101) may connect to the network (111a) based on a profile installed or stored in the eSIM (350). For example, the electronic device (101) may not limit functions and / or operations that may be provided by the CP (313). For example, if the information (e.g., shared value or temporary value) acquired in response to the CP (313) does not match the information (e.g., shared value or temporary value) acquired in response to the eSIM (350), the electronic device (101) may disallow access to a network (e.g., communication network (111a) of FIG. 2A) and / or suggest use of the CP (313). For example, the electronic device (101) may not be able to access the network (111a) based on a profile installed or stored in the eSIM (350). For example, the electronic device (101) may block or restrict use of the CP (313).

[0087] FIG. 5a is a control flowchart for performing binding in an electronic device (e.g., the electronic device (101) of FIG. 1) according to one embodiment, and FIG. 5b is a control flowchart for performing authentication in an electronic device (101) according to one embodiment.

[0088] Referring to FIG. 5A, the electronic device (101) can determine, in operation 510, whether a binding request has occurred. The binding request may occur, for example, at a specific point in the process for product shipment prior to mass production of the electronic device (101). The binding request may occur, for example, during product initialization. The binding request may occur, for example, during product repair. The binding request may occur, for example, when a network to be accessed is changed. The binding request may occur, for example, according to conditions set at the time of product shipment (e.g., binding execution cycle).

[0089] The electronic device (101), when the binding request occurs, may perform a binding operation in operation 520. The binding operation is an operation for allowing a CP (e.g., CP (313) of FIG. 3) and an eSIM (350) to share shared information (e.g., a shared value or a shared key). The shared information may be directly used for authentication of the eSIM (350) after the binding operation, or may be used indirectly. For example, the shared information may be a shared value to be directly transferred between the CP (313) and the eSIM (350) when authenticating the eSIM (350). For example, the shared information may be a shared key, which is a secret key to be used by the CP (313) and / or the eSIM (350) to encrypt or decrypt a nonce when authenticating the eSIM (350). The nonce may be a number used once for authentication. The above temporary value can be randomly generated, for example, using a random number generator. In this document, the shared information will be used in a technical sense to collectively refer to the shared value or the shared key.

[0090] According to an example, the CP (313) may perform a binding operation to obtain a shared value and transfer the obtained shared value to the eSIM (350). The shared value may be directly used for authentication of the eSIM (350). The shared value may be recorded in a non-access memory (e.g., an electronic fuse (eFUSE) memory or a one-time programmable (OTP) memory (820, 840) of FIG. 8A or 8B) accessible by the CP (313) (hereinafter referred to as a 'non-access memory (820, 840)'). The non-access memory may be an eFUSE memory or an OTP memory to which only the CP (313) is permitted to access. The shared value may be a fixed value recorded in the non-access memory of the electronic device (101). The above eFuse memory or OTP memory may have an eFUSE or OTP cell structure. The eFuse memory or OTP memory may record a shared value corresponding to a specific code, for example, depending on whether an eFuse line wired within a memory cell is short-circuited. The shared value recorded in the eFuse memory or OTP memory is not deleted or changed. The eFuse memory or OTP memory may be provided, for example, inside the CP (313). The eFuse memory or OTP memory may be provided, for example, outside the CP (313). The CP (313) may read out and use the shared value recorded in the eFuse memory or OTP memory when necessary. The shared value transmitted by the CP (313) in the binding operation may be stored in the internal memory of the eSIM (350) (e.g., the internal memory (830, 850) of FIG. 8A or 8B). In this document, non-accessible memory will be used to refer to either eFuse memory or OTP memory.

[0091] For example, the CP (313) may perform a binding operation to obtain a shared key and transfer the obtained shared key to the eSIM (350). The shared key may be a shared key to be indirectly used for encryption and / or decryption of data for the eSIM (350). As an example, the CP (313) may obtain a shared key by applying a shared value recorded in a non-access memory (820, 840) (e.g., e-fuse memory or OTP memory) to a specific cryptographic algorithm (e.g., key derivation function, KDF). The non-access memory may be, for example, e-fuse memory or OTP memory. The non-access memory may be provided, for example, inside the CP (313). The non-access memory may be provided, for example, outside the CP (313). The CP (313) can encrypt the shared key and store it in an internal memory (e.g., non-volatile memory) (830, 850) or an external memory (e.g., non-volatile memory of the AP (e.g., the AP (311) of FIG. 3). The CP (313) can decrypt and use the encrypted and stored shared key for authentication of the eSIM (350). The shared key can be shared, for example, by an object (e.g., CP (313) or eSIM (350)) that performs encryption of information (e.g., temporary value for authentication) and an object (e.g., eSIM (350) or CP (313)) that performs decryption of encrypted information (e.g., encrypted temporary value). The shared key can be shared, for example, by an object (e.g., CP (313) or eSIM (350)) that performs encryption of information (e.g., temporary value for authentication) and an object (e.g., It may be a symmetric key to be used together with eSIM (350) or CP (313).

[0092] Referring to FIG. 5B, the electronic device (101) may determine, at operation 530, whether an authentication request has occurred. The authentication request may, for example, occur in response to the booting of the CP (313). The authentication request may, for example, occur in response to the eSIM (350) being soft reset. The authentication request may, for example, occur in response to the eSIM (350) being refreshed.

[0093] The electronic device (101), when the authentication request occurs, may perform an authentication operation in operation 540. For example, the electronic device (101) may perform an authentication operation using the first shared information (e.g., the first shared value or the first shared key) acquired by the CP (313) and the second shared information (e.g., the second shared value or the second shared key) acquired by the eSIM (350). The authentication operation in the electronic device (101) may include a procedure for confirming that the first shared information and the second shared information are the same information shared during the binding operation.

[0094] According to one embodiment, the electronic device (101) can perform an authentication operation for the eSIM (350) using the shared value shared during the binding operation.

[0095] As an example, the CP (313) may obtain a first shared value in response to an authentication request and transmit the obtained first shared value to the eSIM (350). The eSIM (350) may obtain a second shared value in response to an authentication request and determine whether authentication succeeds or fails based on whether the obtained second shared value and the first shared value transmitted by the CP (313) are identical. The eSIM (350) may transmit the determination result to the CP (313).

[0096] As an example, the eSIM (350) may obtain a third shared value in response to an authentication request and transmit the obtained third shared value to the CP (313). The CP (313) may obtain a fourth shared value in response to an authentication request and determine whether authentication succeeds or fails based on whether the obtained fourth shared value and the third shared value transmitted by the eSIM (350) are identical.

[0097] According to one embodiment, the electronic device (101) can perform an authentication operation for the eSIM (350) using a shared key shared during a binding operation.

[0098] As an example, the CP (313) may generate a first nonce value (nonce #1) in response to an authentication request. The CP (313) may receive a second nonce value (nonce #2) from the eSIM (350) in response to an authentication request. The first and second nonce values ​​may be numbers used only once for authentication. The first and second nonce values ​​may be randomly generated, for example, using a random number generator. The CP (313) may decrypt the encrypted first shared key, and may encrypt the first nonce value (nonce #1) and / or the second nonce value (nonce #2) using the decrypted first shared key and transmit the encrypted first nonce value (nonce #1) and / or the second nonce value (nonce #2) to the eSIM (350). The eSIM (350) may obtain a second nonce value (nonce #2) in response to an authentication request, and transmit the obtained second nonce value (nonce #2) to the CP (313). The eSIM (350) can receive encrypted data, in which first and second temporary values ​​are encrypted, using the first shared key from the CP (313). The eSIM (350) can obtain the stored second shared key by the binding operation, and decrypt the encrypted data received from the CP (313) using the obtained second shared key. The eSIM (350) can determine authentication success or failure based on whether the decrypted second temporary value is identical to the second temporary value that it has transmitted to the CP (313). For example, if the second shared key (e.g., the secret key that the eSIM (350) used for decryption) is identical to the first shared key (e.g., the secret key that the CP (313) used for encryption), the decrypted second temporary value will be identical to the second temporary value that it has transmitted to the CP (313). The above eSIM (350) can transmit the determination result to the CP (313).

[0099] As an example, the CP (313) may generate a first nonce value (nonce #1) in response to an authentication request. The CP (313) may transmit the first nonce value (nonce #1) to the eSIM (350) in response to an authentication request. The eSIM (350) may receive the first nonce value (nonce #1) from the CP (313). The eSIM (350) may obtain a second nonce value (nonce #2) in response to an authentication request. The eSIM (350) may obtain a third shared key stored by a binding operation, and may encrypt the first nonce value (nonce #1) and / or the second nonce value (nonce #2) using the obtained third shared key and transmit the encrypted first nonce value (nonce #1) and / or the second nonce value (nonce #2) to the CP (313). The CP (313) can receive encrypted data, in which the first and second temporary values ​​are encrypted, from the eSIM (350) using a third shared key. The CP (313) can decrypt the encrypted shared key to obtain a fourth shared key, and decrypt the encrypted data received from the eSIM (350) using the obtained fourth shared key. The CP (313) can determine authentication success or failure based on whether the decrypted first temporary value is identical to the first temporary value that it has transmitted to the eSIM (350). For example, if the fourth shared key (e.g., a secret key used by the CP (313) for decryption) is identical to the third shared key (e.g., a secret key used by the eSIM (350) for encryption), the decrypted first temporary value will be identical to the first temporary value that it has transmitted to the eSIM (350).

[0100] When the authentication operation is completed, the electronic device (101) can determine whether authentication for the eSIM (350) was successful in operation 550.

[0101] If the electronic device (101) succeeds in authentication for the eSIM (350), in operation 560, the electronic device (101) may allow access to a network (e.g., the communication network (111a) of FIG. 2A) and / or may not restrict the use of the CP (313). For example, the electronic device (101) may connect to the network (111a) based on a profile installed or stored in the eSIM (350). For example, the electronic device (101) may not restrict the function and / or operation of the CP (313).

[0102] If authentication for the eSIM (350) fails, the electronic device (101) may, at operation 570, disallow access to the network or restrict the use of the CP (313). For example, the electronic device (101) may not be able to access the network (111a) based on a profile installed or stored in the eSIM (350). For example, the electronic device (101) may suggest the use of the CP (313).

[0103] FIG. 6a is a signal flow diagram for performing binding in an electronic device (e.g., the electronic device (101) of FIG. 4) according to one embodiment, and FIG. 6b is a signal flow diagram for performing authentication in an electronic device (101) according to one embodiment.

[0104] Referring to FIG. 6A, in operation 610, a CP (e.g., CP (313) of FIG. 4) may monitor the occurrence of a binding event. The binding event may occur in response to a binding request. The binding request may occur, for example, at a specific point in the process for product shipment prior to mass production of the electronic device (101). The binding request may occur, for example, during product initialization. The binding request may occur, for example, during product repair. The binding request may occur, for example, when a network to be accessed is changed. The binding request may occur, for example, according to a condition set at the time of product shipment (e.g., a binding execution cycle).

[0105] The CP (313) may perform a binding procedure (e.g., binding procedure (410) of FIG. 4) in response to the occurrence of the binding event. For example, in operation 620, the CP (313) may acquire a shared value in response to the occurrence of the binding event. The shared value may be a fixed value to be shared between the CP (313) and the eSIM (350). The shared value may be recorded in a non-accessible memory (820, 840) (e.g., e-fuse memory or OTP memory) accessible by the CP (313). The CP (313) may read the shared value recorded in the non-accessible memory without restriction. The non-accessible memory (820, 840) may be a memory to which only the CP (313) is permitted to access. For example, the non-accessible memory (820, 840) may be a memory in which information once recorded cannot be deleted and / or cannot be changed. The non-access memory may be provided, for example, within the CP (313). The non-access memory may be provided, for example, outside the CP (313). The CP (313) may obtain a shared value from the non-access memory when necessary, such as when performing an authentication operation. The shared value may be used for authentication of an eSIM (e.g., eSIM (350) of FIG. 3) after a binding operation.

[0106] In operation 630, the CP (313) may request the eSIM (350) to perform a binding procedure. When the binding request is made, the CP (313) may read the shared value from the non-accessible memory (820, 840) and transmit the shared value to the eSIM (350).

[0107] In operation 630, the eSIM (350) may receive a binding request from the CP (313). In operation 640, the eSIM (350) may store the shared value received from the CP (313) at the time of the binding request in an internal memory (e.g., the internal memory (830, 850) of FIG. 8A or FIG. 8B). The eSIM (350) may allocate an area in the internal memory (830, 850) for storing the shared value. The eSIM (350) may obtain the shared value from the internal memory (830, 850) at a time when the shared value is required, such as when performing an authentication operation. In operation 650, the eSIM (350) may transmit a binding response corresponding to the binding request to the CP (313). The above binding response may have a notification function to notify that the shared value received from the CP (313) has been stored in the internal memory (830, 850).

[0108] Referring to FIG. 6B, at operation 660, the CP (313) may monitor the occurrence of an authentication event. The authentication event may occur in response to an authentication request. The authentication request may occur, for example, in response to the booting of the CP (313). The authentication request may occur, for example, in response to the eSIM (350) being soft reset. The authentication request may occur, for example, in response to the eSIM (350) being refreshed.

[0109] The CP (313) may perform an authentication procedure (e.g., authentication procedure (420) of FIG. 4) in response to the occurrence of the authentication event. For example, in operation 670, the CP (313) may obtain a shared value from a non-access memory (820, 840) in response to the occurrence of the authentication event. For example, the CP (313) may read and obtain a shared value recorded in the non-access memory (820, 849).

[0110] In operation 680, the CP (313) and the eSIM (350) can perform an authentication procedure. For example, the CP (313) can transfer a first shared value obtained from a non-accessible memory (820, 840) to the eSIM (350). The eSIM (350) can obtain a second shared value from an internal memory (e.g., the internal memory (830, 850) of FIG. 8A or 8B). The eSIM (350) can determine whether the authentication succeeds or fails based on whether the first shared value received from the CP (313) matches the second shared value obtained by the eSIM. The eSIM (350) can transfer the determination result to the CP (313). For example, the CP (313) can request that the shared value be transferred to the eSIM (350). The eSIM (350) can obtain a third shared value from the internal memory (830, 850) in response to a shared value transfer request from the CP (313). The eSIM (350) can transfer the obtained third shared value to the CP (313). The CP (313) can determine whether authentication succeeds or fails based on whether the fourth shared value obtained in response to the occurrence of the authentication event is the same as the third shared value transferred by the eSIM (350).

[0111] The CP (313) may be able to access a specific network (e.g., communication network (111a) of FIG. 2a) when the authentication is successful. The functions and / or operations that the CP (313) may be able to provide may not be restricted when the authentication is successful. The CP (313) may be unable to access a specific network (e.g., communication network (111a) of FIG. 2a) when the authentication fails. The functions and / or operations that the CP (313) may be able to provide may be restricted when the authentication fails.

[0112] FIG. 7a is a signal flow diagram for performing binding in an electronic device (e.g., the electronic device (101) of FIG. 4) according to one embodiment, and FIG. 7b is a signal flow diagram for performing authentication in an electronic device (101) according to one embodiment.

[0113] Referring to FIG. 7A, in operation 711, a CP (e.g., CP (313) of FIG. 4) may monitor the occurrence of a binding event. The binding event may occur in response to a binding request. The binding request may occur, for example, at a specific point in the process for product shipment prior to mass production of the electronic device (101). The binding request may occur, for example, during product initialization. The binding request may occur, for example, during product repair. The binding request may occur, for example, when a network to be accessed is changed. The binding request may occur, for example, according to a condition set at the time of product shipment (e.g., a binding execution cycle).

[0114] The CP (313) may perform a binding procedure (e.g., binding procedure (410) of FIG. 4) in response to the occurrence of the binding event. For example, in operation 713, the CP (313) may obtain a shared key in response to the occurrence of the binding event. The shared key may be indirectly used for authentication of the eSIM (350). The shared key may be shared, for example, by an object (e.g., CP (313) or eSIM (350)) that performs encryption of information (e.g., a nonce for authentication) and an object (e.g., eSIM (350) or CP (313)) that performs decryption of encrypted information (e.g., an encrypted nonce). The shared key may be, for example, a symmetric key to be used by an object (e.g., CP (313) or eSIM (350)) that performs encryption of information (e.g., a nonce for authentication) and an object (e.g., eSIM (350) or CP (313)) that performs decryption of encrypted information (e.g., an encrypted nonce). The CP (313) may, for example, read a shared value stored in a non-access memory (820, 840) (e.g., e-fuse memory or OTP memory) and apply the read shared value to a specific encryption algorithm (e.g., a key derivation function, KDF) to obtain a shared key to be shared with the eSIM (350). The CP (313) can encrypt the acquired shared key and store it in an internal memory (e.g., non-volatile memory) (e.g., internal memory (830, 850) of FIG. 8a or FIG. 8b) or an external memory (e.g., non-volatile memory of AP (e.g., AP (311) of FIG. 3)).

[0115] In operation 715, the CP (313) may request the eSIM (350) to perform a binding procedure. The CP (313) may transmit the shared key to the eSIM (350) when requesting the binding.

[0116] In operation 715, the eSIM (350) may receive a binding request from the CP (313). In operation 717, the eSIM (350) may store the shared key received from the CP (313) at the time of the binding request in the internal memory (830, 850). The eSIM (350) may allocate an area in the internal memory (830, 850) for storing the shared key. The eSIM (350) may obtain the shared key from the internal memory (830, 850) at a time when the shared key is required, such as when performing an authentication operation. In operation 719, the eSIM (350) may transmit a binding response corresponding to the binding request to the CP (313). The binding response may have a notification function for notifying that the shared key received from the CP (313) has been stored in the internal memory (830, 850).

[0117] Referring to FIG. 7B, at operation 721, the CP (313) may monitor the occurrence of an authentication event. The authentication event may occur in response to an authentication request. The authentication request may occur, for example, in response to the booting of the CP (313). The authentication request may occur, for example, in response to the eSIM (350) being soft reset. The authentication request may occur, for example, in response to the eSIM (350) being refreshed.

[0118] The CP (313) may perform an authentication procedure (e.g., authentication procedure (420) of FIG. 4) in response to the occurrence of the authentication event. For example, in operation 723, the CP (313) may transmit an authentication initiation request to the eSIM (350) in response to the occurrence of the authentication event. The authentication initiation request may notify the eSIM (350) of the occurrence of the authentication event.

[0119] In operation 725, the eSIM (350) may generate a second nonce value (nonce #2) in response to the authentication initiation request. The second nonce value may be a value used only once for authentication. The second nonce value may be randomly generated, for example, using a random number generator. In operation 727, the eSIM (350) may transmit an authentication initiation response to the CP (313) in response to the authentication initiation request.

[0120] In operation 727, the CP (313) may receive the authentication initiation response from the eSIM (350). In operation 729, the CP (313) may generate a first nonce value (nonce #1). The first nonce value may be a randomly generated value for performing an authentication operation. The CP (313) may generate the first nonce value, for example, in response to receiving the authentication initiation response.

[0121] In operation 731, the CP (313) can obtain the first or fourth shared key. For example, the CP (313) can read out the encrypted shared key stored by the previously performed binding operation and decrypt the read out encrypted shared key to obtain the first or fourth shared key.

[0122] In operation 733, the eSIM (350) may obtain a second or third shared key. For example, the eSIM (350) may read the second or third shared key stored in the internal memory (830, 850) through a previously performed binding operation.

[0123] In operation 735, the CP (313) and the eSIM (350) can perform an authentication procedure.

[0124] Although FIG. 7b illustrates that the CP (313) generates the first temporary value after receiving the authentication initiation response, this is merely exemplary. For example, the CP (313) can generate the first temporary value at any point in time, regardless of the passage of time, between operation 721, in which the authentication event occurs, and operation 735, in which authentication is performed.

[0125] According to an example, the CP (313) can receive a second temporary value from the eSIM (350). The CP (313) can, for example, receive the second temporary value from the eSIM (350) together with the authentication initiation response. The CP (313) can encrypt the first temporary value and the second temporary value that it generated using a first shared key and transmit them to the eSIM (350). The eSIM (350) can receive encrypted data, in which the first and second temporary values ​​are encrypted using the first shared key, from the CP (313). The eSIM (350) can decrypt the encrypted data received from the CP (313) using a second shared key. The eSIM (350) can determine whether authentication succeeds or fails based on whether the decrypted second temporary value is identical to the second temporary value that it transmitted to the CP (313). For example, if the second shared key (e.g., the shared key used by the eSIM (350) for decryption) is the same as the first shared key (e.g., the shared key used by the CP (313) for encryption), the decrypted second temporary value will be the same as the second temporary value that it transmitted to the CP (313). The eSIM (350) can determine whether authentication succeeds or fails based on whether the decrypted second temporary value is the same as the second temporary value that it transmitted to the CP (313). The eSIM (350) can transmit the determination result to the CP (313).

[0126] In one example, the CP (313) may transmit a first temporary value to the eSIM (350). The CP (313) may, for example, transmit the first temporary value to the eSIM (350) together with the authentication initiation request. The eSIM (350) may receive the first temporary value from the CP (313). The eSIM (350) may encrypt the first temporary value and / or the second temporary value using a third shared key and transmit the encrypted data to the CP (313). The CP (313) may receive encrypted data from the eSIM (350) in which the first and second temporary values ​​are encrypted using the third shared key. The CP (313) may decrypt the encrypted data received from the eSIM (350) using a fourth shared key obtained by decrypting a shared key that is encrypted and stored in advance. The CP (313) can determine whether the authentication success or failure is based on whether the decrypted first temporary value is identical to the first temporary value that it transmitted to the eSIM (350). For example, if the fourth shared key (e.g., the shared key used by the CP (313) for decryption) is identical to the third shared key (e.g., the shared key used by the eSIM (350) for encryption), the decrypted first temporary value will be identical to the first temporary value that it transmitted to the eSIM (350). The CP (313) can determine whether the authentication success or failure is based on whether the decrypted first temporary value is identical to the first temporary value that it transmitted to the eSIM (350).

[0127] The CP (313) may be installed in the eSIM (350) or may be able to access a specific network (e.g., a communication network (111a) of FIG. 2a) based on a stored profile when the authentication is successful. The CP (313) may not be limited in the functions and / or operations it can provide when the authentication is successful. The CP (313) may be blocked from accessing a specific network (e.g., a communication network (111a) of FIG. 2a) based on a stored profile when the authentication is unsuccessful. The CP (313) may be limited in the functions and / or operations it can provide when the authentication is unsuccessful.

[0128] FIG. 8A or FIG. 8B is a block diagram of an exemplary electronic device (e.g., electronic device (101) of FIG. 1) capable of performing operations according to one embodiment.

[0129] Referring to FIG. 8a or FIG. 8b, a CP (e.g., CP (313) of FIG. 4) and an eSIM (e.g., eSIM (350) of FIG. 4) may be connected to a data bus (810) to enable exchange of data.

[0130] The CP (313) may include a non-access memory (820) (e.g., an e-fuse memory or an OTP memory) inside (Fig. 8a) or may include a non-access memory (840) outside (Fig. 8b). For example, the CP (313) may read a shared value recorded in the non-access memory (820 or 840) without restriction. The non-access memory P (820 or 840) may be a memory accessible by the CP (313). The non-access memory may be, for example, an e-fuse memory or an OTP memory.

[0131] The eSIM (350) may include an internal memory (830, 850). The eSIM (350) may store shared information (e.g., a shared value or a temporary key) obtained by performing a binding procedure (e.g., the binding procedure (410) of FIG. 4). The obtained shared information may be directly or indirectly used for authentication of the eSIM (350) after the binding operation. For example, the shared information may be a non-access key (e.g., a shared value) to be directly transferred between the CP (313) and the eSIM (350) when authenticating the eSIM (350). For example, the shared information may be a shared key that the CP (313) and / or the eSIM (350) use to encrypt or decrypt a temporary value (nonce) when authenticating the eSIM (350). In this document, the shared information will be used in a technical sense to collectively refer to the shared value or the shared key.

[0132] FIG. 9 is a signal flow diagram for performing a binding procedure (e.g., binding procedure (410) of FIG. 4) in an electronic device (e.g., electronic device (101) of FIG. 4) according to one embodiment.

[0133] Referring to FIG. 9, in operation 910, a CP (e.g., CP (313) of FIG. 4) may transmit a binding initiation request to an eSIM (e.g., 350 of FIG. 4) in response to the occurrence of a binding event. The binding event may occur, for example, at a specific point in the process for product shipment prior to mass production of the electronic device (101). The binding event may occur, for example, during product initialization. The binding event may occur, for example, during product repair. The binding event may occur, for example, when a network to be accessed is changed. The binding event may occur, for example, according to a condition set at the time of product shipment (e.g., binding execution cycle). In operation 920, the eSIM (350) may transmit a binding readiness notification to the CP (313) in response to the binding initiation request.

[0134] In operation 930, the CP (313) may request a shared value from an eFuse memory or an OTP memory (e.g., a non-access memory (820, 840) of FIG. 8A or FIG. 8B) based on receiving the binding preparation notification from the eSIM (530). In operation 940, the CP (313) may receive a shared value from the non-access memory (820, 840). The non-access memory (820, 840) may be a memory accessible by the CP (313). The shared value stored in the non-access memory (820, 840) may be deleted or not changed. The non-access memory may be, for example, an eFuse memory or an OTP memory. The non-access memory (820, 840) may be provided, for example, inside the CP (313). The non-access memory (820, 840) may be provided, for example, outside the CP (313). The shared value may be a non-access key. The non-access key may be recorded in the non-access memory (820, 840) that is accessible by the CP (313). The shared value may be a fixed value recorded in the non-access memory (820, 840) of the electronic device (101). The CP (313) may read the shared value recorded in the non-access memory (820, 840) without restriction.

[0135] In operation 950, the CP (313) may transmit the shared value to the eSIM (350). In operation 960, the eSIM (350) may store the shared value received from the CP (313) in an internal memory (e.g., the internal memory (830, 850) of FIG. 8A or FIG. 8B). The eSIM (350) may allocate an area in the internal memory (830, 850) for storing the shared value. In operation 970, the eSIM (350) may transmit a binding completion response to the CP (313). The binding completion response may have a notification function for notifying that the shared value received from the CP (313) has been stored in the internal memory (830, 850) of the eSIM (350).

[0136] FIG. 10 is a signal flow diagram for performing an authentication procedure (e.g., the authentication procedure (420) of FIG. 4) in an electronic device (e.g., the electronic device (101) of FIG. 4) according to one embodiment.

[0137] Referring to FIG. 10, at operation 1010, a CP (e.g., CP (313) of FIG. 4) may transmit an authentication initiation request to an eSIM (e.g., 350 of FIG. 4) in response to the occurrence of an authentication event. The authentication event may occur, for example, in response to the booting of the CP (313). The authentication event may occur, for example, in response to the eSIM (350) being soft reset. The authentication event may occur, for example, in response to the eSIM (350) being refreshed. At operation 1020, the eSIM (350) may transmit an authentication readiness notification to the CP (313) in response to the authentication initiation request.

[0138] In operation 1030, the CP (313) may request a shared value from a non-access memory (820, 840) based on receiving the authentication preparation notification. The non-access memory (820, 840) may be a non-access memory that is only allowed to be accessed by the CP (313). The non-access memory (820, 840) may be, for example, an e-fuse memory or an OTP memory. The non-access memory (820, 840) may be provided, for example, inside the CP (313). The non-access memory (820, 840) may be provided, for example, outside the CP (313). The shared value may be a non-access key. The shared value may be recorded in the non-access memory (820, 840) that is accessible by the CP (313). The shared value may be a fixed value recorded in the non-access memory (820, 840) of the electronic device (101). The CP (313) can read the shared value recorded in the non-access memory (820, 840) without restriction. In operation 1040, the non-access memory (820, 840) may provide the recorded shared value to the CP (313) in response to a shared value request from the CP (313).

[0139] In operation 1050, the CP (313) may transmit the shared value to the eSIM (350). The eSIM (350) may read and obtain the shared value stored in an internal memory (e.g., the internal memory (830, 850) of FIG. 8A or 8B). In operation 1060, the eSIM (350) may compare the shared value received from the CP (313) with the shared value acquired from the internal memory (830, 850), and determine whether authentication is performed based on the comparison result. For example, the eSIM (350) may determine authentication success or failure based on whether the first shared value received from the CP (313) matches the second shared value acquired by the eSIM. In operation 1070, the eSIM (350) may transmit the authentication result to the CP (313).

[0140] The CP (313) may be installed in the eSIM (350) or, based on a stored profile, may be able to access a specific network (e.g., a communication network (111a) of FIG. 2a) when authentication is successful. The CP (313) may not be limited in the functions and / or operations it can provide when authentication is successful. The CP (313) may be installed in the eSIM (350) or, based on a stored profile, may be blocked from accessing a specific network (e.g., a communication network (111a) of FIG. 2a) when authentication fails. The CP (313) may be limited in the functions and / or operations it can provide when authentication fails.

[0141] FIG. 11 is a signal flow diagram for performing an authentication procedure (e.g., the authentication procedure (420) of FIG. 4) in an electronic device (e.g., the electronic device (101) of FIG. 4) according to one embodiment.

[0142] Referring to FIG. 11, at operation 1110, a CP (e.g., CP (313) of FIG. 4) may transmit an authentication initiation request to an eSIM (e.g., 350 of FIG. 4) in response to the occurrence of an authentication event. The authentication event may occur, for example, in response to the booting of the CP (313). The authentication event may occur, for example, in response to the eSIM (350) being soft reset. The authentication event may occur, for example, in response to the eSIM (350) being refreshed. At operation 1120, the eSIM (350) may transmit an authentication readiness notification to the CP (313) in response to the authentication initiation request.

[0143] In operation 1130, the CP (313) may request a shared value from a non-access memory (820, 840) (e.g., e-fuse memory or OTP memory) based on receiving the authentication preparation notification. The non-access memory (820, 840) may be a non-access memory that can only be accessed by the CP (313). The non-access memory (820, 840) may be, for example, an e-fuse memory or an OTP memory. The non-access memory (820, 840) may be provided, for example, inside the CP (313). The non-access memory (820, 840) may be provided, for example, outside the CP (313). The shared value may be a non-access key. The shared value may be written in the non-access memory (820, 840) that can be accessed by the CP (313). The shared value may be a fixed value recorded in the non-access memory (820, 840) of the electronic device (101). The CP (313) can read the shared value recorded in the non-access memory (820, 840) without restriction. In operation 1140, the non-access memory (820, 840) may provide the recorded shared value to the CP (313) in response to a shared value request from the CP (313).

[0144] In operation 1150, the CP (313) may request the transmission of a shared value to the eSIM (350). In operation 1160, the eSIM (350) may obtain the shared value from an internal memory (e.g., the internal memory (830, 850) of FIG. 8A or FIG. 8B) in response to the request for transmission of the shared value. In operation 1170, the eSIM (350) may transmit the obtained shared value to the CP (313).

[0145] In operation 1180, the CP (313) can compare the shared value received from the eSIM (350) with the shared value it has acquired, and determine whether authentication is required based on the comparison result. For example, the CP (313) can determine whether authentication is successful or unsuccessful based on whether the shared value received from the eSIM (350) matches the shared value it has acquired.

[0146] The CP (313) may be installed in the eSIM (350) or, based on a stored profile, may be able to access a specific network (e.g., a communication network (111a) of FIG. 2a) when authentication is successful. The CP (313) may not be limited in the functions and / or operations it can provide when authentication is successful. The CP (313) may be installed in the eSIM (350) or, based on a stored profile, may be blocked from accessing a specific network (e.g., a communication network (111a) of FIG. 2a) when authentication fails. The CP (313) may be limited in the functions and / or operations it can provide when authentication fails.

[0147] FIG. 12a12a is a control flowchart for performing binding in an electronic device (e.g., the electronic device (101) of FIG. 1) according to one embodiment, and FIG. 12b is a control flowchart for performing authentication in an electronic device (101) according to one embodiment.

[0148] Referring to FIG. 12a12a, the electronic device (101) may determine whether a binding initiation event occurs in operation 1210. The binding initiation event may occur in response to a binding request. The binding request may occur, for example, at a specific point in the process for product shipment prior to mass production of the electronic device (101). The binding request may occur, for example, during product initialization. The binding request may occur, for example, during product repair. The binding request may occur, for example, when a network to be accessed is changed. The binding request may occur, for example, according to conditions set at the time of product shipment (e.g., binding execution cycle).

[0149] When a binding initiation event occurs, the electronic device (101) may obtain a shared value in operation 1220. The shared value may be a non-access key. The non-access key may be recorded in a non-access memory accessible to the electronic device (101). The non-access key may be a shared value recorded in a non-access memory of the electronic device (101) (e.g., the non-access memory (820, 840) of FIG. 8A or FIG. 8B). The electronic device (101) may read the shared value recorded in the non-access memory (820, 840) without restriction. The non-access memory (820, 840) may be a non-access memory accessible to the electronic device (101). The non-access memory (820, 840) may be, for example, a fuse memory or an OTP memory. The e-fuse memory or OTP memory may be provided, for example, within the CP (e.g., CP (313) of FIG. 4). The e-fuse memory or OTP memory may be provided, for example, outside the CP (313). The electronic device (101) may cause the CP (313) to obtain a shared value from the non-access memory (820, 840) when necessary, such as when performing an authentication operation. The shared value may be used for authentication of an eSIM (e.g., eSIM (350) of FIG. 3) after a binding operation.

[0150] The electronic device (101) may, in operation 1230, perform a binding procedure (e.g., binding procedure (410) of FIG. 4) between the CP (1230) and the eSIM (e.g., eSIM (350) of FIG. 4) based on the acquired shared value. For example, the binding procedure may be performed according to the signal flow procedure described based on FIG. 9. A detailed description thereof will be omitted as it has been described above.

[0151] Referring to FIG. 12B, the electronic device (101) may determine, at operation 1240, whether an authentication initiation event occurs. The authentication initiation event may occur in response to an authentication request. The authentication request may occur, for example, in response to the booting of the CP (313). The authentication request may occur, for example, in response to the eSIM (350) being soft reset. The authentication request may occur, for example, in response to the eSIM (350) being refreshed.

[0152] When the authentication initiation event occurs, the electronic device (101) can check whether the shared value acquired by the CP (313) and the shared value acquired by the eSIM (350) match in operation 1250.

[0153] The electronic device (101), in operation 1260, can determine whether authentication of the eSIM (350) is successful based on whether the shared value acquired by the CP (313) and the shared value acquired by the eSIM (350) match. For example, if the shared value acquired by the CP (313) and the shared value acquired by the eSIM (350) match, the electronic device (101) can determine that authentication of the eSIM (350) is successful. For example, if the shared value acquired by the CP (313) and the shared value acquired by the eSIM (350) do not match, the electronic device (101) can determine that authentication of the eSIM (350) has failed.

[0154] If the authentication is successful, the electronic device (101) may allow access to a specific network (e.g., the communication network (111a) of FIG. 2A) by the CP (313) based on the profile installed or stored in the eSIM (350) in operation 1270. The functions and / or operations that the electronic device (101) may provide may not be limited when the authentication is successful. If the authentication fails, the electronic device (101) may block access to a specific network (e.g., the communication network (111a) of FIG. 2A) by the CP (313) based on the profile installed or stored in the eSIM (350) in operation 1280. The functions and / or operations that the electronic device (101) may provide may be limited when the authentication fails.

[0155] FIG. 13 is a block diagram of an exemplary electronic device (e.g., electronic device (101) of FIG. 1) capable of performing operations according to one embodiment.

[0156] Referring to FIG. 13, the electronic device (101) may include an AP (e.g., an AP (311) of FIG. 3), a CP (e.g., a CP (313) of FIG. 3 or FIG. 4), or at least one eSIM (e.g., an eSIM (350) of FIG. 3 or FIG. 4 (hereinafter, referred to as 'eSIM (350)'). The AP (311) may include a nonvolatile memory (1321). The nonvolatile memory (1321) may be located outside the AP (311). The eSIM (350) may be mounted on one internal board (200) (e.g., the internal board (200a) of FIG. 2a). The eSIM (350) may include an application (1331) (or applet) or an internal memory (1333) (e.g., the internal memory (830) of FIG. 8a or FIG. 8b). 850)) may be included.

[0157] According to an example, the CP (313) may include a processing module (1311), a non-access memory (e.g., e-fuse memory or OTP memory) (1313) (e.g., non-access memory (820, 840) of FIG. 8a or 8b), an interface module (1315), an encryption module (1317), or a temporary storage module (1319).

[0158] The processing module (1311) may request the encryption module (1317) to generate a shared key in response to the occurrence of a binding event. The processing module (1311) may receive a shared key from the encryption module (1317) in response to the shared key generation request. The processing module (1311) may request the interface module (1315) to store the shared key received from the encryption module (1317). The shared key transmitted to the interface module (1315) may be encrypted and stored in the temporary storage module (1319), or may be stored in the non-volatile memory (1321) of the AP (e.g., the AP (311) of FIG. 3). The processing module (1311) may request the interface module (1315) to generate a shared key for binding with the eSIM (350). The processing module (1311) can receive a shared key from the interface module (1315). The processing module (1311) can transmit the shared key received from the interface module (1315) to the eSIM (350). The shared key can be stored in the internal memory (1333) of the eSIM (350).

[0159] In one example, the processing module (1311) may receive an encrypted shared key from the AP (311) in response to the occurrence of an authentication event. If the CP (313) includes a secure non-volatile memory (NV), the encrypted shared key may be stored in the secure NV. The processing module (1311) may transmit the encrypted shared key to the encryption module (1317) via the interface module (1315). The processing module (1311) may receive the shared key decrypted by the encryption module (1317). The processing module (1311) may generate a first nonce value (nonce #1). The processing module (1311) may receive a second nonce value (nonce #2) generated by the eSIM (350). The processing module (1311) may encrypt the first temporary value (nonce #1) and the second temporary value (nonce #2) using the shared key, and transmit the encrypted data 'ENC shared key {nonce #1 | nonce #2}' to the eSIM (350). The processing module (1311) may receive an authentication result from the eSIM (350).

[0160] In one example, the processing module (1311) may receive an encrypted shared key from the AP (311) in response to the occurrence of an authentication event. If the CP (313) includes a secure non-volatile memory, the encrypted shared key may be stored in the secure NV. The processing module (1311) may transmit the encrypted shared key to the encryption module (1317) via the interface module (1315). The processing module (1311) may receive the shared key decrypted by the encryption module (1317). The processing module (1311) may generate a first nonce value (nonce #1). The processing module (1311) may transmit the first nonce value to the eSIM (350). The processing module (1311) may receive encrypted data 'ENC shared key {nonce #1 | The processing module (1311) may receive 'nonce #2'. Here, nonce #2 may be a temporary value generated by the eSIM (350). The processing module (1311) may request decryption of the encrypted data to the encryption module (1317). The processing module (1311) may determine whether to authenticate the eSIM (350) based on the result of the decryption processing by the encryption module (1317).

[0161] The non-access memory (1313) stores a shared value to be used for authentication of the eSIM (350). The non-access memory (1313) may be a non-access memory that can be accessed by the CP (313). For example, the non-access memory (1313) may be an eFUSE memory or an OTP memory. The eFUSE memory or the OTP memory may have an eFUSE OTP cell structure. The eFUSE memory or the OTP memory may record a shared value corresponding to a specific code, for example, depending on whether an eFUSE line wired within a memory cell is short-circuited. The shared value recorded in the eFUSE memory or the OTP memory is not deleted or changed. The eFUSE memory or the OTP memory may be provided, for example, within the CP (313). The eFUSE memory or the OTP memory may be provided, for example, outside the CP (313).

[0162] The interface module (1315) may relay signal transmission between the processing module (1311), the encryption module (1317), the temporary storage module (1319), or the AP (311) for a binding operation (e.g., the binding procedure (410) of FIG. 4) or an authentication operation (e.g., the authentication procedure (420) of FIG. 4). The interface module (1315) may be a necessary component because a file system does not exist in the CP (313). For example, when the file system does not exist, the CP (313) needs to be provided with the interface module (1315), which is a component for reading or writing data.

[0163] The encryption module (1317) may generate a shared key using a shared value in response to a request from the processing module (1311). The encryption module (1317) may transmit the shared key to the processing module (1311). The encryption module (1317) may encrypt the shared key in response to a request from the processing module (1311) and transmit the encrypted shared key to the processing module (1311). For example, the encryption module (1317) may encrypt a first temporary value and a second temporary value using a shared key in response to a request from the processing module (1311) and transmit the encrypted data to the processing module (1311). For example, the encryption module (1317) may receive data encrypted by the eSIM (350) from the processing module (1311) and decrypt it using a shared key. The encryption module (1317) may transmit the decrypted result value (e.g., the decrypted first temporary value and / or the decrypted second temporary value) to the processing module (1311).

[0164] The above temporary storage module (1319) can temporarily store an encrypted shared key provided from the above processing module (1311).

[0165] The AP (311) may receive an encrypted shared key from the interface module (1315) in response to a request from the processing module (1311) and store the encrypted shared key in a non-volatile memory (1321). If the CP (313) includes a secure non-volatile memory (secure NV), the encrypted shared key may be stored in the secure NV. The encrypted shared key transmitted by the interface module (1315) may be encrypted by the encryption module (1317) and stored in a temporary storage module (1319).

[0166] The above AP (311) can read out the encrypted shared key stored in the non-volatile memory (1321) and transmit it to the interface module (1315) in response to a request from the interface module (1315) upon occurrence of a binding event.

[0167] The above AP (311) can read out the encrypted shared key stored in the non-volatile memory (1321) and transmit it to the interface module (1315) in response to a request from the interface module (1315) upon occurrence of an authentication event.

[0168] The above eSIM (200) can store the shared key transmitted by the processing module (1311) in the internal memory (1333) in response to the occurrence of a binding event.

[0169] For example, the eSIM (200) may generate a nonce in response to an authentication initiation request from the CP (313) and transmit the nonce to the CP (313). The eSIM (200) may receive 'ENC shared key {nonce #1 | nonce #2}', which is data encrypted with a shared key by the CP (313). Here, nonce #1 is a nonce value generated by the CP (313), and nonce #2 is a nonce value generated by the eSIM (200) and transmitted to the CP (313). The eSIM (350) may perform the encrypted data 'ENC shared key {nonce #1 | nonce #2}' using the shared key stored in the internal memory (1333). The eSIM (350) may obtain 'nonce #1' and 'nonce #2' through the decryption. Here, nonce #1' is a temporary value predicted to have been generated by the CP (313), and nonce #2' is a temporary value predicted to have been generated by the eSIM and transmitted to the CP (313). The eSIM (350) can determine whether the predicted nonce #2' matches the nonce #2 that it generated and transmitted to the CP (313). The eSIM (350) can transmit an authentication result based on the judgment result to the CP (313).

[0170] According to an example, the eSIM (200) may generate a second nonce value (nonce #2) in response to an authentication initiation request from the CP (313). The eSIM (200) may receive a first nonce value (nonce #1) generated by the CP (313) together with a nonce value request from the CP (313). The eSIM (350) may transmit encrypted data 'ENC shared key {nonce #1 | nonce #2}' obtained by encrypting the first nonce value (nonce #1) and the second nonce value (nonce #2) to the CP (313) in response to the nonce value request. The eSIM (350) may use a shared key stored in the internal memory (1333) for the encryption.

[0171] FIG. 14 is a signal flow diagram for generating a shared key included in a binding procedure (e.g., binding procedure (410) of FIG. 4) in an electronic device (e.g., electronic device (101) of FIG. 4) according to one embodiment.

[0172] Referring to FIG. 14, in operation 1410, a processing module (e.g., the processing module (1311) of FIG. 13) may request generation of a shared key from an encryption module (e.g., the encryption module (1317) of FIG. 13). The shared key may be used for authentication of an eSIM (e.g., the eSIM (350) of FIG. 4). The shared key may be, for example, a secret key that a specific object (e.g., the CP (313) or the eSIM (350)) uses to encrypt information (e.g., a nonce for authentication), or that a specific object (e.g., the eSIM (350) or the CP (313)) uses to decrypt encrypted information (e.g., an encrypted nonce). The shared key may be, for example, a symmetric key to be used by an object (e.g., CP (313) or eSIM (350)) that performs encryption of information (e.g., a nonce for authentication) and an object (e.g., eSIM (350) or CP (313)) that performs decryption of encrypted information (e.g., an encrypted nonce). The processing module (1311) and the encryption module (1317) may be components included in a CP (e.g., CP (313) of FIG. 3).

[0173] In operation 1420, the encryption module (1317) may request a shared value from a non-access memory (e.g., e-fuse memory or OTP memory) (1313) in response to the shared key generation request, and may receive the shared value from the non-access memory (1313) in response to the request. The shared value may be a fixed value recorded in the non-access memory (1313). The shared value recorded in the non-access memory (1313) may be read without restriction by the processing module (1311) and / or the encryption module (1317). The non-access memory (1313) may be an e-fuse memory or an OTP memory. The e-fuse memory or the OTP memory may be provided, for example, inside the CP (313). The e-fuse memory or the OTP memory may be provided, for example, outside the CP (313).

[0174] In operation 1430, the encryption module (1317) may generate a shared key by applying a shared value obtained from the non-accessible memory (1313) to a specific encryption algorithm (e.g., KDF). In operation 1440, the encryption module (1317) may transmit the generated shared key to the processing module (1311).

[0175] FIG. 15 is a signal flow diagram for encrypting and storing a shared key included in a binding procedure (e.g., binding procedure (410) of FIG. 4) in an electronic device (e.g., electronic device (101) of FIG. 4) according to one embodiment.

[0176] Referring to FIG. 15, in operation 1510, a processing module (e.g., the processing module (1311) of FIG. 13) may request an interface module (e.g., the interface module (1315) of FIG. 13) to encrypt and store a shared key. The processing module (1311) may transmit the shared key, which is the target for encryption, to the interface module (1315). The processing module (1311) and the interface module (1315) may be included in a CP (e.g., the CP (313) of FIG. 4).

[0177] In operation 1520, the interface module (1315) may transmit a request for encryption of the shared key to an encryption module (e.g., the encryption module (1317) of FIG. 13) in response to a request from the processing module (1311). The interface module (1315) may provide the shared key received from the processing module (1311) to the encryption module (1317). The interface module (1315) may call an encryption algorithm to perform encryption of the public key.

[0178] In operation 1530, the encryption module (1317) may perform encryption on the shared key in response to an encryption request from the interface module (1315). The encryption module (1317) may perform the encryption to generate an encrypted shared key. In operation 1540, the encryption module (1317) may transfer the generated encrypted shared key to a temporary storage module (e.g., the temporary storage module (1319) of FIG. 13). The temporary storage module (1319) may temporarily store the encrypted shared key transferred from the encryption module (1317). The encryption module (1317) and the temporary storage module (1319) may be included in the CP (313).

[0179] In operation 1550, the temporary storage module (1319) can read out the temporarily stored encrypted shared key and transmit it to the interface module (1315). In operation 1560, the interface module (1315) can transmit the read out encrypted shared key to an AP (e.g., AP (311) of FIG. 13). The AP (311) can store the encrypted shared key received from the interface module (1315) in a non-volatile memory (e.g., non-volatile memory (1321) of FIG. 13).

[0180] FIG. 16 is a signal flow diagram for binding a shared key included in a binding procedure (e.g., binding procedure (410) of FIG. 4) in an electronic device (e.g., electronic device (101) of FIG. 4) according to one embodiment.

[0181] Referring to FIG. 16, in operation 1610, a processing module (e.g., the processing module (1311) of FIG. 13) may request provision of a shared key from an interface module (e.g., the interface module (1315) of FIG. 13). The processing module (1311) and the interface module (1315) may be included in a CP (e.g., the CP (313) of FIG. 4).

[0182] In operation 1620, the interface module (1315) may request provision of an encrypted shared key from an AP (e.g., AP (311) of FIG. 13) in response to a request from the processing module (1311). In operation 1630, the AP (311) may transmit an encrypted shared key stored in a non-volatile memory (e.g., non-volatile memory (1321) of FIG. 13) provided therein to the interface module (1315) in response to the request for the encrypted shared key. If the CP (313) includes a secure non-volatile memory, the encrypted shared key may be stored in the secure non-volatile memory. In this case, the interface module (1315) may also obtain the encrypted shared key from the secure non-volatile memory.

[0183] In operation 1640, the interface module (1315) may request decryption of the encrypted shared key received from the AP (311) to an encryption module (e.g., the encryption module (1317) of FIG. 13). The interface module (1315) may transmit the encrypted shared key to the encryption module (1317) for decryption.

[0184] In operation 1650, the encryption module (1317) may perform decryption on the encrypted shared key received from the interface module (1315) in response to a request from the interface module (1315). In operation 1660, the encryption module (1317) may transmit the decrypted shared key to the interface module (1315). The encryption module (1317) may be included in the CP (313).

[0185] In operation 1670, the interface module (1315) may transmit the shared key received from the encryption module (1317) to the processing module (1311). In operation 1680, the processing module (1311) may transmit the shared key received from the interface module (1315) to an eSIM (e.g., an eSIM (350) of FIG. 13). The eSIM (350) may store the shared key received from the processing module (1311) in an internal memory (e.g., an internal memory (1333) of FIG. 13). In operation 1690, the eSIM (350) may transmit a binding result indicating that the shared key has been stored in the internal memory (1333) to the processing module (1311).

[0186] FIG. 17 is a signal flow diagram for performing an authentication procedure (e.g., the authentication procedure (420) of FIG. 4) in an electronic device (e.g., the electronic device (101) of FIG. 4) according to one embodiment.

[0187] Referring to FIG. 17, in operation 1711, a CP (e.g., CP (313) of FIG. 13) may transmit an authentication initiation request to an eSIM (e.g., eSIM (350) of FIG. 13) in response to an occurrence of an authentication event. The authentication event may occur in response to an authentication request. The authentication request may, for example, occur in response to booting of the CP (313). The authentication request may, for example, occur in response to a soft reset of the eSIM (350). The authentication request may, for example, occur in response to a refresh of the eSIM (350). The authentication initiation request may notify the eSIM (350) that an authentication event has occurred.

[0188] In operation 1713, the eSIM (350) may generate a second nonce value (nonce #2) in response to the authentication initiation request. The second nonce value may be a randomly generated number for performing the authentication operation. In operation 1715, the eSIM (350) may transmit an authentication preparation notification corresponding to the authentication initiation request to the CP (313). The eSIM (350) may transmit the second nonce value to the CP (313) at the time of the authentication preparation notification.

[0189] In operation 1715, the CP (313) may receive the authentication preparation notification from the eSIM (350). The CP (313) may receive the second temporary value from the eSIM (350) together with the authentication preparation notification.

[0190] In operation 1717, the CP (313) may request provision of an encrypted shared key from an AP (e.g., AP (311) of FIG. 13) as the authentication preparation notification is transmitted. In operation 1719, the AP (311) may transmit an encrypted shared key stored in a non-volatile memory (e.g., non-volatile memory (1321) of FIG. 13) provided internally to the CP (313) in response to the request for the encrypted shared key. If the CP (313) includes a secure non-volatile memory, the encrypted shared key may be stored in the secure non-volatile memory. In this case, the CP (313) may obtain the encrypted shared key from the secure non-volatile memory.

[0191] In operation 1721, the CP (313) may decrypt the received encrypted shared key to obtain a first shared key (shared key #1). In operation 1723, the CP (313) may generate a first nonce value (nonce #1). The first nonce value may be a randomly generated number for performing an authentication operation. The CP (313) may generate the first nonce value, for example, in response to receiving the authentication preparation notification.

[0192] In operation 1725, the CP (313) may encrypt the first nonce value (nonce #1) and / or the second nonce value (nonce #2) using the first shared key (shared key #1) to generate encrypted data (ENC shared key#1 {nonce #1 | nonce #2}). In operation 1727, the CP (313) may transmit the generated encrypted data (ENC shared key#1 {nonce #1 | nonce #2}) to the eSIM (350).

[0193] In operation 1729, the eSIM (350) may obtain a second shared key (shared key #2) stored by the binding operation, and may decrypt (DEC shared key #2 {nonce #1 | nonce #2}) the encrypted data received from the CP (313) using the obtained second shared key (shared key #2). The eSIM (350) may perform the decryption to obtain a decrypted first temporary value and a decrypted second temporary value.

[0194] In operation 1729, the eSIM (350) can determine whether the authentication succeeds or fails based on whether the decrypted second temporary value is identical to the second temporary value that it transmitted to the CP (313). For example, if the second shared key (e.g., the shared key that the eSIM (350) used for decryption) is identical to the first shared key (e.g., the shared key that the CP (313) used for encryption), the decrypted second temporary value will be identical to the second temporary value that it transmitted to the CP (313). In operation 1731, the eSIM (350) can transmit the determination result to the CP (313).

[0195] The CP (313) may be installed in the eSIM (350) or may be able to access a specific network (e.g., a communication network (111a) of FIG. 2a) based on a stored profile when the authentication is successful. The CP (313) may not be limited in the functions and / or operations it can provide when the authentication is successful. The CP (313) may be blocked from accessing a specific network (e.g., a communication network (111a) of FIG. 2a) based on a stored profile when the authentication is unsuccessful. The CP (313) may be limited in the functions and / or operations it can provide when the authentication is unsuccessful.

[0196] FIG. 18 is a signal flow diagram for performing an authentication procedure (e.g., the authentication procedure (420) of FIG. 4) in an electronic device (e.g., the electronic device (101) of FIG. 4) according to one embodiment.

[0197] Referring to FIG. 18, in operation 1811, a CP (e.g., CP (313) of FIG. 13) may transmit an authentication initiation request to an eSIM (e.g., eSIM (350) of FIG. 13) in response to the occurrence of an authentication event. The authentication event may occur in response to an authentication request. The authentication request may, for example, occur in response to the booting of the CP (313). The authentication request may, for example, occur in response to the eSIM (350) being soft reset. The authentication request may, for example, occur in response to the eSIM (350) being refreshed. The authentication initiation request may notify the eSIM (350) that an authentication event has occurred.

[0198] In operation 1813, the eSIM (350) may generate a second nonce value (nonce #2) in response to the authentication initiation request. The second nonce value may be a randomly generated number for performing the authentication operation. In operation 1815, the eSIM (350) may transmit an authentication readiness notification in response to the authentication initiation request to the CP (313).

[0199] In operation 1815, the CP (313) may receive the authentication preparation notification from the eSIM (350). In operation 1817, the CP (313) may request provision of an encrypted shared key from an AP (e.g., AP (311) of FIG. 13) as the authentication preparation notification is transmitted. In operation 1819, the AP (311) may transmit an encrypted shared key stored in a non-volatile memory (e.g., non-volatile memory (1321) of FIG. 13) provided internally to the CP (313) in response to the request for the encrypted shared key. If the CP (313) includes a secure non-volatile memory, the encrypted shared key may be stored in the secure non-volatile memory. In this case, the CP (313) may obtain the encrypted shared key from the secure non-volatile memory.

[0200] In operation 1821, the CP (313) may decrypt the received encrypted shared key to obtain a first shared key (shared key #1). In operation 1823, the CP (313) may generate a first nonce value (nonce #1). The first nonce value may be a randomly generated number for performing an authentication operation. The CP (313) may generate the first nonce value, for example, in response to receiving the authentication preparation notification.

[0201] In operation 1825, the CP (313) may request a temporary value from the eSIM (350). When requesting the temporary value, the CP (313) may transmit the first temporary value it has generated to the eSIM (350).

[0202] In operation 1827, the eSIM (350) may perform encryption according to a nonce value request from the CP (313). For example, the eSIM (350) may obtain a second shared key (shared key #2) stored in an internal memory (e.g., the internal memory (1333) of FIG. 13), and may use the obtained second secret key (shared key #2) to encrypt the first nonce value (nonce #1) and / or the second nonce value (nonce #2) to generate encrypted data (ENC shared key #2 {nonce #1 | nonce #2}). In operation 1829, the CP (313) may transmit the generated encrypted data (ENC shared key #2 {nonce #1 | nonce #2}) to the CP (313).

[0203] In operation 1831, the CP (313) can decrypt (DEC shared key#1 {nonce #1 | nonce #2}) the encrypted data received from the eSIM (350) using the first shared key (shared key #1). The CP (313) can perform the decryption to obtain a decrypted first temporary value and a decrypted second temporary value.

[0204] In operation 1831, the CP (313) can determine authentication success or failure by whether the decrypted first temporary value is identical to the first temporary value that it transmitted to the eSIM (350). For example, if the first shared key (e.g., the shared key used by the CP (313) for encryption) is identical to the second shared key (e.g., the shared key used by the eSIM (350) for decryption), the decrypted first temporary value will be identical to the first temporary value that it transmitted to the eSIM (350).

[0205] The CP (313) may be installed in the eSIM (350) or may be able to access a specific network (e.g., a communication network (111a) of FIG. 2a) based on a stored profile when the authentication is successful. The CP (313) may not be limited in the functions and / or operations it can provide when the authentication is successful. The CP (313) may be blocked from accessing a specific network (e.g., a communication network (111a) of FIG. 2a) based on a stored profile when the authentication is unsuccessful. The CP (313) may be limited in the functions and / or operations it can provide when the authentication is unsuccessful.

[0206] FIG. 19 is a signal flow diagram for performing authentication for multiple eSIMs (e.g., first and second SIMs (201b, 203b) of FIG. 2a) in an electronic device (e.g., electronic device (101) of FIG. 4) according to one embodiment.

[0207] In the description referring to FIG. 19, it is assumed that the binding procedure and the authentication procedure are performed sequentially as an example, but operations 1910, 1930a, and / or 1930b corresponding to the binding procedure may be performed before product launch, and operations 1920, 1940a, and / or 1940b corresponding to the authentication procedure may be performed after product launch.

[0208] Referring to FIG. 19, in operation 1910, a CP (e.g., CP (313) of FIG. 4) may monitor the occurrence of a binding event. The binding event may occur in response to a binding request. The binding request may occur, for example, at a specific point in the process for product shipment prior to mass production of the electronic device (101). The binding request may occur, for example, during product initialization. The binding request may occur, for example, during product repair. The binding request may occur, for example, when a network to be accessed is changed. The binding request may occur, for example, according to a condition set at the time of product shipment (e.g., a binding execution cycle).

[0209] The CP (313) may perform a binding procedure (e.g., binding procedure (410) of FIG. 4) in response to the occurrence of the binding event. The CP (313) may perform a binding procedure with at least one of a first SIM (e.g., the first SIM (201b) of FIG. 2b) or a second SIM (e.g., the second SIM (203b) of FIG. 2b) mounted together on one internal board (e.g., the internal board (200b) of FIG. 2b). For example, in operation 1930a, the CP (313) may perform a binding procedure with the first SIM (201b) mounted together on one internal board (200b). For example, in operation 1930b, the CP (313) may perform a binding procedure with the second SIM (203b) mounted together on one internal board (200b). For example, in operations 1930a and 1930b, the CP (313) may perform a binding procedure with the first SIM (201b) and the second SIM (203b) mounted together on one internal board (200b). The binding procedure performed between the CP (313) and at least one of the first SIM (201b) or the second SIM (203b) may be performed based on what has been described with reference to at least one of the drawings of FIGS. 6, 7, 9, 14 to 16.

[0210] In operation 1920, the CP (313) may monitor the occurrence of an authentication event. The authentication event may occur in response to an authentication request. The authentication request may occur, for example, in response to the booting of the CP (313). The authentication request may occur, for example, in response to a soft reset of at least one of the first SIM (201b) or the second SIM (203b). The authentication request may occur, for example, in response to a refresh of at least one of the first SIM (201b) or the second SIM (203b).

[0211] The CP (313) may perform an authentication procedure (e.g., the authentication procedure (420) of FIG. 4) in response to the occurrence of the authentication event. The CP (313) may perform an authentication procedure with at least one of the first SIM (201b) or the second SIM (203b) mounted together on one internal board (200b). For example, in operation 1940a, the CP (313) may perform an authentication procedure with the first SIM (201b) mounted together on one internal board (200b). For example, in operation 1940b, the CP (313) may perform an authentication procedure with the second SIM (203b) mounted together on one internal board (200b). For example, in operations 1940a and 1940b, the CP (313) may perform an authentication procedure with the first SIM (201b) and the second SIM (203b) mounted together on one internal board (200b). The authentication procedure performed between the CP (313) and at least one of the first SIM (201b) or the second SIM (203b) may be performed based on what has been described with reference to at least one of the drawings of FIG. 6, FIG. 7, FIG. 10, FIG. 11, FIG. 17, or FIG. 18.

[0212] For example, when the CP (313) performs both the binding procedure and the authentication procedure with the first SIM (201b) and the second SIM (203b), the CP (313) may perform authentication for the first SIM (201b) and / or the second SIM (203b) by using a shared value (or temporary value) acquired from the first SIM (201b) and a shared value (or temporary value) acquired from the second SIM (203b). For example, when the shared value (or temporary value) acquired from the first SIM (201b) and the shared value (or temporary value) acquired from the second SIM (203b) match, the CP (313) may determine that authentication for both the first SIM (201b) and the second SIM (203b) is successful. For example, if the shared value (or temporary value) obtained from the first SIM (201b) and the shared value (or temporary value) obtained from the second SIM (203b) do not match, the CP (313) may determine that authentication for both the first SIM (201b) and the second SIM (203b) has failed.

[0213] The CP (313) may be able to access a specific network (e.g., the first communication network (111b) and / or the second communication network (113b) of FIG. 2b) when the authentication is successful. The CP (313) may not be limited in the functions and / or operations that it can provide when the authentication is successful. The CP (313) may not allow access to a specific network (e.g., the first communication network (111b) and / or the second communication network (113b) of FIG. 2b) when the authentication fails. The CP (313) may be limited in the functions and / or operations that it can provide when the authentication fails.

[0214] FIG. 20 is a signal flow diagram for performing authentication for multiple eSIMs (e.g., first and second SIMs (201b, 203b) of FIG. 2a) in an electronic device (e.g., electronic device (101) of FIG. 4) according to one embodiment.

[0215] In the description referring to FIG. 20, it is assumed that the binding procedure and the authentication procedure are performed sequentially as an example, but operations 2010, 2030 and 2040 corresponding to the binding procedure may be performed before the product is launched, and operations 2020, 2050 and 2060 corresponding to the authentication procedure may be performed after the product is launched.

[0216] Referring to FIG. 20, in operation 2010, a CP (e.g., CP (313) of FIG. 4) may monitor the occurrence of a binding event. The binding event may occur in response to a binding request. The binding request may occur, for example, at a specific point in the process for product shipment prior to mass production of the electronic device (101). The binding request may occur, for example, during product initialization. The binding request may occur, for example, during product repair. The binding request may occur, for example, when a network to be accessed is changed. The binding request may occur, for example, according to conditions set at the time of product shipment (e.g., binding execution cycle).

[0217] The CP (313) may perform a binding procedure (e.g., binding procedure (410) of FIG. 4) in response to the occurrence of the binding event. The CP (313) may perform a binding procedure with each of a first SIM (e.g., the first SIM (211c) of FIG. 2c) or a second SIM (e.g., the second SIM (221c) of FIG. 2c) independently mounted on separate internal boards (210c, 220c). In operation 2030, the CP (313) may perform a first binding procedure with the first SIM (211c) mounted on the first internal board (210c). In operation 2040, the CP (313) may perform a binding procedure with the second SIM (221c) mounted on the second internal board (220c). The binding procedure performed with the CP (313) and the first SIM (211c) or the second SIM (221c) may be performed based on what has been described above with reference to at least one of the drawings of FIGS. 6, 7, 9, 14 to 16.

[0218] In operation 2020, the CP (313) may monitor the occurrence of an authentication event. The authentication event may occur in response to an authentication request. The authentication request may occur, for example, in response to the booting of the CP (313). The authentication request may occur, for example, in response to a soft reset of at least one of the first SIM (211c) or the second SIM (221c). The authentication request may occur, for example, in response to a refresh of at least one of the first SIM (211c) or the second SIM (221c).

[0219] The CP (313) may perform an authentication procedure (e.g., the authentication procedure (420) of FIG. 4) in response to the occurrence of the authentication event. The CP (313) may perform an authentication procedure with each of the first SIM (211c) and the second SIM (221c) independently mounted on separate internal boards (210c, 220c). In operation 2050, the CP (313) may perform a first authentication procedure with the first SIM (211c) mounted on the first internal board (210c). In operation 2060, the CP (313) may perform an authentication procedure with the second SIM (221c) mounted on the second internal board (220c). The authentication procedure performed with the CP (313) and the first SIM (211c) or the second SIM (221c) may be performed based on what has been described above with reference to at least one of the drawings of FIG. 6, FIG. 7, FIG. 10, FIG. 11, FIG. 17, or FIG. 18.

[0220] For example, when the CP (313) performs both the binding procedure and the authentication procedure with the first SIM (211c) and the second SIM (221c), the CP (313) may perform authentication for the first SIM (211c) and / or the second SIM (221c) by using a shared value (or temporary value) acquired from the first SIM (211c) and a shared value (or temporary value) acquired from the second SIM (221c). For example, when the shared value (or temporary value) acquired from the first SIM (211c) and the shared value (or temporary value) acquired from the second SIM (221c) match, the CP (313) may determine that authentication for both the first SIM (211c) and the second SIM (221c) is successful. For example, if the shared value (or temporary value) obtained from the first SIM (211c) and the shared value (or temporary value) obtained from the second SIM (221c) do not match, the CP (313) may determine that authentication for both the first SIM (211c) and the second SIM (221c) has failed.

[0221] The CP (313) may be able to access a specific network (e.g., the first communication network (111c) and / or the second communication network (113c) of FIG. 2c) when the authentication is successful. The functions and / or operations that the CP (313) may provide may not be restricted when the authentication is successful. The CP (313) may not allow access to a specific network (e.g., the first communication network (111c) and / or the second communication network (113c) of FIG. 2c) when the authentication fails. The functions and / or operations that the CP (313) may provide may be restricted when the authentication fails.

[0222] FIG. 21 is an example diagram of a user interface that indicates whether network access is available based on authentication of an eSIM (e.g., an eSIM (350) of FIG. 4) in an electronic device (e.g., an electronic device (101) of FIG. 4), according to one embodiment.

[0223] Referring to FIG. 21, a display of an electronic device (101) (e.g., display (330) of FIG. 3) may include identifiers (2110, 2120) indicating whether a network (e.g., communication network (111a) of FIG. 2a) is accessible. As an example, the electronic device (101) may perform an authentication operation for an eSIM (350) and, in response to a successful authentication for the eSIM (350), display a first identifier (2110) through the display (330). The first identifier (2110) may be, for example, an indicator indicating the strength of a received signal. As an example, the electronic device (101) may perform an authentication operation for an eSIM (350) and, in response to a failure in authentication for the eSIM (350), display a second identifier (2120) through the display (330). The second identifier (2120) may be, for example, an indicator indicating that no received signal exists.

[0224] According to one example, an electronic device (101) may include an embedded subscriber identity module (eSIM) (350) having an internal memory and configured to store a profile in the internal memory. The electronic device (101) may include one or more recording media and a memory (340) storing instructions. The electronic device (101) may include a communication processor (CP) (313) including processing circuitry, wherein shared information is shared between the CP (313) and the eSIM (350). When the instructions are individually or collectively executed by at least one processor including the CP (313), they may cause the electronic device (101) to perform at least one operation. The at least one operation may include an operation (operation 420) of performing authentication on the eSIM (350) using the first shared information obtained by the CP (313) and the second shared information stored in the eSIM (350) in response to an authentication request. The at least one operation may include an operation of restricting the use of the CP (313) depending on whether authentication on the eSIM (350) is successful.

[0225] For example, the first shared information may be a first shared value recorded in a specific memory accessible to the CP (313).

[0226] In one example, the second shared information may be a second shared value recorded in the internal memory of the eSIM.

[0227] In one example, the particular memory may be one of a one-time programmable (OTP) memory (820, 840) or an electronic fuse (eFUSE) memory.

[0228] According to an example, the operation of performing the authentication may include an operation (operation 1060, operation 1180) of determining that authentication for the eSIM (350) is successful if the second shared key obtained by the CP (313) in response to the authentication request is stored in the eSIM (350).

[0229] According to an example, the operation of performing the authentication may include an operation (operation 1060, operation 1180) of determining that authentication for the eSIM (350) has failed if the second shared key obtained by the CP (313) in response to the authentication request is not stored in the eSIM (350).

[0230] In one example, the second shared key may be a shared value that is substantially the same as the first shared key.

[0231] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of obtaining the first shared value in response to the authentication request.

[0232] In one example, when the instructions are individually or collectively executed by at least one processor, they may cause the electronic device (101) to perform an operation of transmitting the first shared value acquired by the CP to the eSIM.

[0233] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may be caused to perform an operation of identifying whether the first shared value received by the eSIM from the CP and the second shared value stored in the internal memory are substantially the same.

[0234] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of transmitting information indicating authentication success or failure to the CP based on the identification result.

[0235] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of obtaining the first shared value in response to the authentication request.

[0236] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of transmitting the second shared value stored in the internal memory to the CP in response to the authentication request.

[0237] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may be caused to perform an operation of identifying whether the first shared value obtained by the CP and the second shared value received from the eSIM are substantially the same.

[0238] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of determining authentication success or failure based on the identification result.

[0239] For example, the first shared information may be a first shared key obtained by applying a first shared value recorded in a specific memory accessible to the CP (313) to a specific encryption algorithm.

[0240] In one example, the second shared information may be a second shared key recorded in the internal memory of the eSIM.

[0241] In one example, the particular memory may be one of a one-time programmable (OTP) memory (820, 840) or an electronic fuse (eFUSE) memory.

[0242] For example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP (313) to perform an operation of encrypting and storing the first shared key.

[0243] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of generating a first nonce in response to the authentication request.

[0244] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of transmitting the generated first temporary value to the CP.

[0245] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of generating a second nonce.

[0246] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of encrypting the first temporary value received from the eSIM and the generated second temporary value with the first shared key and transmitting the encrypted data to the eSIM.

[0247] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of decrypting the encrypted data received from the CP with the second shared key to obtain a third nonce.

[0248] In one example, when the instructions are individually or collectively executed by at least one processor, they may cause the electronic device (101) to perform an operation of identifying whether the eSIM acquired third temporary value and the generated first temporary value are substantially the same.

[0249] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of transmitting information indicating authentication success or failure to the CP based on the identification result.

[0250] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of generating a first nonce in response to the authentication request.

[0251] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of transmitting the generated first temporary value to the CP.

[0252] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of generating a second nonce.

[0253] For example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of decrypting the encrypted first shared key to obtain the first shared key.

[0254] According to an example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of encrypting the first temporary value and the generated second temporary value received from the eSIM with the acquired first shared key and transmitting the encrypted data to the eSIM.

[0255] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of decrypting the encrypted data received from the CP with the second shared key to obtain a third nonce.

[0256] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may perform an operation to identify whether the eSIM acquired third temporary value and the generated first temporary value are substantially the same.

[0257] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of transmitting information indicating authentication success or failure to the CP based on the identification result.

[0258] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of generating a first nonce in response to the authentication request.

[0259] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of transmitting the generated first temporary value to the eSIM.

[0260] In one example, when the instructions are individually or collectively executed by at least one processor, they may cause the electronic device (101) to perform an operation that causes the eSIM to generate a second nonce.

[0261] According to one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of encrypting the first temporary value received from the CP and the generated second temporary value with the second shared key and transmitting the encrypted data to the CP.

[0262] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of decrypting the encrypted data received from the eSIM with the first shared key to obtain a third nonce.

[0263] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may be caused to perform an operation of identifying whether the CP acquired the third temporary value and the generated first temporary value are substantially the same.

[0264] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of determining authentication success or failure based on the identification result.

[0265] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of generating a first nonce in response to the authentication request.

[0266] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of transmitting the generated first temporary value to the eSIM.

[0267] In one example, when the instructions are individually or collectively executed by at least one processor, they may cause the electronic device (101) to perform an operation that causes the eSIM to generate a second nonce.

[0268] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of decrypting the encrypted first shared key to obtain the first shared key.

[0269] According to one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM to perform an operation of encrypting the first temporary value and the generated second temporary value received from the CP with the acquired first shared key and transmitting the encrypted data to the CP.

[0270] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of decrypting the encrypted data received from the eSIM with the second shared key to obtain a third nonce.

[0271] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may be caused to perform an operation of identifying whether the CP acquired the third temporary value and the generated first temporary value are substantially the same.

[0272] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP to perform an operation of determining authentication success or failure based on the identification result.

[0273] In one example, the authentication request may occur in response to the booting of the CP.

[0274] In one example, the authentication request may occur in response to a soft reset of the eSIM.

[0275] In one example, the authentication request may occur in response to a refresh of the eSIM.

[0276] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the CP (313) to perform an operation of transmitting the shared information to the eSIM (350) in response to a binding request.

[0277] In one example, when the instructions are individually or collectively executed by at least one processor, the electronic device (101) may cause the eSIM (350) to perform an operation of storing the shared information received from the CP (313) in the internal memory.

[0278] In one example, when the instructions are individually or collectively executed by at least one processor, they may cause the electronic device (101) to perform an operation that does not restrict the use of a profile stored in the eSIM (350) by the CP (313) upon successful authentication of the eSIM (350).

[0279] In one example, when the instructions are individually or collectively executed by at least one processor, they may cause the electronic device (101) to perform an action to restrict the use of a profile stored in the eSIM (350) by the CP (313) if authentication for the eSIM (350) fails.

[0280] According to one example, when the instructions are individually or collectively executed by at least one processor, they may cause the electronic device (101) to perform an operation of allowing access to the network (111a) by the CP (313) if authentication for the eSIM (350) is successful.

[0281] In one example, when the instructions are individually or collectively executed by at least one processor, they may cause the electronic device (101) to perform an operation of restricting access to the network (111a) by the CP (313) or an operation of restricting use of some or all functions of the CP (313) if authentication for the eSIM (350) fails.

[0282] According to one example, a recording medium storing computer-readable instructions may be provided. The instructions, when executed by at least a part of at least one processor including a communication processor (CP) (313) included in an electronic device (101), may cause the electronic device (101) to perform at least one operation. The at least one operation may include an operation (operation 420) of performing authentication on an embedded subscriber identity module (eSIM) (350) using first shared information acquired by the CP (313) and second shared information stored in the eSIM (350) in response to an authentication request. The at least one operation may include an operation of restricting the use of the CP (313) depending on whether the authentication on the eSIM (350) is successful.

[0283] For example, the first shared information may be a first shared value recorded in a specific memory accessible to the CP (313).

[0284] In one example, the second shared information may be a second shared value recorded in the internal memory of the eSIM.

[0285] In one example, the particular memory may be one of a one-time programmable (OTP) memory (820, 840) or an electronic fuse (eFUSE) memory.

[0286] According to an example, the operation of performing the authentication may include an operation (operation 1060, operation 1180) of determining that authentication for the eSIM (350) is successful if the second shared key obtained by the CP (313) in response to the authentication request is stored in the eSIM (350).

[0287] According to an example, the operation of performing the authentication may include an operation (operation 1060, operation 1180) of determining that authentication for the eSIM (350) has failed if the second shared key obtained by the CP (313) in response to the authentication request is not stored in the eSIM (350).

[0288] In one example, the second shared key may be a shared value that is substantially the same as the first shared key.

[0289] In one example, the at least one operation may include an operation in which the CP obtains the first shared value in response to the authentication request.

[0290] In one example, the at least one operation may include an operation of the CP transmitting the acquired first shared value to the eSIM.

[0291] In one example, the at least one operation may include an operation of identifying whether the first shared value received by the eSIM from the CP and the second shared value stored in the internal memory are substantially the same.

[0292] In one example, the at least one operation may include an operation in which the eSIM transmits information indicating authentication success or failure to the CP based on the identification result.

[0293] In one example, the at least one operation may include an operation in which the CP obtains the first shared value in response to the authentication request.

[0294] In one example, the at least one operation may include an operation in which the eSIM transmits the second shared value stored in the internal memory to the CP in response to the authentication request.

[0295] In one example, the at least one operation may include an operation of identifying whether the first shared value obtained by the CP and the second shared value received from the eSIM are substantially the same.

[0296] In one example, the at least one action may cause the CP to perform an action that determines authentication success or failure based on the identification result.

[0297] For example, the first shared information may be a first shared key obtained by applying a first shared value recorded in a specific memory accessible to the CP (313) to a specific encryption algorithm.

[0298] In one example, the second shared information may be a second shared key recorded in the internal memory of the eSIM.

[0299] In one example, the particular memory may be one of a one-time programmable (OTP) memory (820, 840) or an electronic fuse (eFUSE) memory.

[0300] In one example, the at least one operation may include an operation in which the CP (313) encrypts and stores the first shared key.

[0301] In one example, the at least one action may include, in response to the authentication request, the eSIM generating a first nonce.

[0302] In one example, the at least one operation may include an operation in which the eSIM transmits the generated first temporary value to the CP.

[0303] In one example, the at least one operation may include an operation in which the CP generates a second nonce.

[0304] In one example, the at least one operation may include an operation in which the CP encrypts the first temporary value received from the eSIM and the generated second temporary value with the first shared key and transmits the encrypted data to the eSIM.

[0305] In one example, the at least one operation may include the eSIM decrypting the encrypted data received from the CP with the second shared key to obtain a third nonce.

[0306] In one example, the at least one operation may include an operation of the eSIM identifying whether the acquired third temporary value and the generated first temporary value are substantially identical.

[0307] In one example, the at least one operation may include an operation in which the eSIM transmits information indicating authentication success or failure to the CP based on the identification result.

[0308] In one example, the at least one action may cause the eSIM to generate a first nonce in response to the authentication request.

[0309] In one example, the at least one operation may include an operation in which the eSIM transmits the generated first temporary value to the CP.

[0310] In one example, the at least one operation may include an operation in which the CP generates a second nonce.

[0311] In one example, the at least one operation may include an operation in which the CP decrypts the encrypted first shared key to obtain the first shared key.

[0312] According to an example, the at least one operation may include an operation in which the CP encrypts the first temporary value received from the eSIM and the second temporary value generated with the obtained first shared key and transmits the encrypted data to the eSIM.

[0313] In one example, the at least one operation may include the eSIM decrypting the encrypted data received from the CP with the second shared key to obtain a third nonce.

[0314] In one example, the at least one operation may cause the eSIM to perform an operation of identifying whether the acquired third temporary value and the generated first temporary value are substantially the same.

[0315] In one example, the at least one operation may include an operation in which the eSIM transmits information indicating authentication success or failure to the CP based on the identification result.

[0316] In one example, the at least one operation may include, in response to the authentication request, the CP generating a first nonce.

[0317] In one example, the at least one operation may include an operation in which the CP transmits the generated first temporary value to the eSIM.

[0318] In one example, the at least one operation may include the eSIM generating a second nonce.

[0319] In one example, the at least one operation may cause the eSIM to perform an operation of encrypting the first temporary value received from the CP and the generated second temporary value with the second shared key and transmitting the encrypted data to the CP.

[0320] In one example, the at least one operation may include an operation in which the CP decrypts the encrypted data received from the eSIM with the first shared key to obtain a third nonce.

[0321] In one example, the at least one operation may include an operation of identifying whether the CP's acquired third temporary value and the generated first temporary value are substantially the same.

[0322] In one example, the at least one operation may include an operation in which the CP determines authentication success or failure based on the identification result.

[0323] In one example, the at least one operation may include an operation in which the CP generates a first nonce in response to the authentication request.

[0324] In one example, the at least one operation may include an operation in which the CP transmits the generated first temporary value to the eSIM.

[0325] In one example, the at least one operation may include the eSIM generating a second nonce.

[0326] In one example, the at least one operation may include an operation in which the eSIM decrypts the encrypted first shared key to obtain the first shared key.

[0327] In one example, the at least one operation may include an operation in which the eSIM encrypts the first temporary value received from the CP and the second temporary value generated with the acquired first shared key and transmits the encrypted data to the CP.

[0328] In one example, the at least one operation may include an operation in which the CP decrypts the encrypted data received from the eSIM with the second shared key to obtain a third nonce.

[0329] In one example, the at least one operation may include an operation of identifying whether the CP's acquired third temporary value and the generated first temporary value are substantially the same.

[0330] In one example, the at least one operation may include an operation in which the CP determines authentication success or failure based on the identification result.

[0331] In one example, the authentication request may occur in response to the booting of the CP.

[0332] In one example, the authentication request may occur in response to a soft reset of the eSIM.

[0333] In one example, the authentication request may occur in response to a refresh of the eSIM.

[0334] In one example, the at least one action may include an action in which the CP (313) transmits the shared information to the eSIM (350) in response to a binding request.

[0335] In one example, the at least one operation may include an operation of the eSIM (350) storing the shared information received from the CP (313) in the internal memory.

[0336] In one example, the at least one operation may include an operation that does not restrict the use of a profile stored in the eSIM (350) by the CP (313) if authentication for the eSIM (350) is successful.

[0337] In one example, the at least one action may include an action of restricting use of a profile stored in the eSIM (350) by the CP (313) if authentication for the eSIM (350) fails.

[0338] According to an example, the at least one operation may include an operation of allowing access to the network (111a) by the CP (313) if authentication for the eSIM (350) is successful.

[0339] According to an example, the at least one action may cause the CP (313) to perform an action of restricting access to the network (111a) or an action of restricting use of some or all functions of the CP (313) if authentication for the eSIM (350) fails.

[0340] According to one example, the authentication method of the electronic device (101) may include an operation (operation 420) of performing authentication on an embedded subscriber identity module (eSIM) (350) using first shared information acquired by a communication processor (CP) and second shared information stored in the eSIM (350) in response to an authentication request. The authentication method may include an operation of restricting the use of the CP (313) depending on whether authentication on the eSIM (350) is successful.

[0341] For example, the first shared information may be a first shared value recorded in a specific memory accessible to the CP (313).

[0342] In one example, the second shared information may be a second shared value recorded in the internal memory of the eSIM.

[0343] In one example, the particular memory may be one of a one-time programmable (OTP) memory (820, 840) or an electronic fuse (eFUSE) memory.

[0344] According to an example, the operation of performing the authentication may include an operation (operation 1060, operation 1180) of determining that authentication for the eSIM (350) is successful if the second shared key obtained by the CP (313) in response to the authentication request is stored in the eSIM (350).

[0345] According to an example, the operation of performing the authentication may include an operation (operation 1060, operation 1180) of determining that authentication for the eSIM (350) has failed if the second shared key obtained by the CP (313) in response to the authentication request is not stored in the eSIM (350).

[0346] In one example, the second shared key may be a shared value that is substantially the same as the first shared key.

[0347] In one example, the authentication method may include an operation in which the CP obtains the first shared value in response to the authentication request.

[0348] In one example, the authentication method may include an operation in which the CP transmits the acquired first shared value to the eSIM.

[0349] In one example, the authentication method may include an operation of identifying whether the first shared value received by the eSIM from the CP and the second shared value stored in the internal memory are substantially the same.

[0350] In one example, the authentication method may include an operation in which the eSIM transmits information indicating authentication success or failure to the CP based on the identification result.

[0351] In one example, the authentication method may include an operation in which the CP obtains the first shared value in response to the authentication request.

[0352] In one example, the authentication method may include an operation in which the eSIM transmits the second shared value stored in the internal memory to the CP in response to the authentication request.

[0353] In one example, the authentication method may include an operation of identifying whether the first shared value obtained by the CP and the second shared value received from the eSIM are substantially the same.

[0354] In one example, the authentication method may cause the CP to perform an operation of determining authentication success or failure based on the identification result.

[0355] For example, the first shared information may be a first shared key obtained by applying a first shared value recorded in a specific memory accessible to the CP (313) to a specific encryption algorithm.

[0356] In one example, the second shared information may be a second shared key recorded in the internal memory of the eSIM.

[0357] In one example, the particular memory may be one of a one-time programmable (OTP) memory (820, 840) or an electronic fuse (eFUSE) memory.

[0358] According to an example, the authentication method may include an operation in which the CP (313) encrypts and stores the first shared key.

[0359] In one example, the authentication method may include an operation in which, in response to the authentication request, the eSIM generates a first nonce.

[0360] In one example, the authentication method may include an operation in which the eSIM transmits the generated first temporary value to the CP.

[0361] In one example, the authentication method may include an operation in which the CP generates a second nonce.

[0362] According to an example, the authentication method may include an operation in which the CP encrypts the first temporary value received from the eSIM and the second temporary value generated with the first shared key and transmits the encrypted data to the eSIM.

[0363] In one example, the authentication method may include an operation in which the eSIM decrypts the encrypted data received from the CP using the second shared key to obtain a third nonce.

[0364] In one example, the authentication method may include an operation of identifying whether the eSIM's acquired third temporary value and the generated first temporary value are substantially identical.

[0365] In one example, the authentication method may cause the eSIM to perform an operation of transmitting information indicating authentication success or failure to the CP based on the identification result.

[0366] In one example, the authentication method may cause the eSIM to perform an operation of generating a first nonce in response to the authentication request.

[0367] In one example, the authentication method may cause the eSIM to perform an operation of transmitting the generated first temporary value to the CP.

[0368] In one example, the authentication method may cause the CP to perform an operation of generating a second nonce.

[0369] In one example, the authentication method may include an operation in which the CP decrypts the encrypted first shared key to obtain the first shared key.

[0370] According to an example, the authentication method may include an operation in which the CP encrypts the first temporary value received from the eSIM and the second temporary value generated with the acquired first shared key and transmits the encrypted data to the eSIM.

[0371] In one example, the authentication method may include an operation in which the eSIM decrypts the encrypted data received from the CP using the second shared key to obtain a third nonce.

[0372] In one example, the authentication method may include an operation of identifying whether the eSIM's acquired third temporary value and the generated first temporary value are substantially identical.

[0373] In one example, the authentication method may include an operation in which the eSIM transmits information indicating authentication success or failure to the CP based on the identification result.

[0374] In one example, the authentication method may include an operation in which, in response to the authentication request, the CP generates a first nonce.

[0375] In one example, the authentication method may include an operation in which the CP transmits the generated first temporary value to the eSIM.

[0376] In one example, the authentication method may include an operation in which the eSIM generates a second nonce.

[0377] According to an example, the authentication method may include an operation in which the eSIM encrypts the first temporary value received from the CP and the second temporary value generated with the second shared key and transmits the encrypted data to the CP.

[0378] In one example, the authentication method may include an operation in which the CP decrypts the encrypted data received from the eSIM using the first shared key to obtain a third nonce.

[0379] In one example, the authentication method may include an operation of identifying whether the CP's acquired third temporary value and the generated first temporary value are substantially identical.

[0380] In one example, the authentication method may include an operation in which the CP determines authentication success or failure based on the identification result.

[0381] In one example, the authentication method may include an operation in which the CP generates a first nonce in response to the authentication request.

[0382] In one example, the authentication method may include an operation in which the CP transmits the generated first temporary value to the eSIM.

[0383] In one example, the authentication method may include an operation in which the eSIM generates a second nonce.

[0384] In one example, the authentication method may include an operation in which the eSIM decrypts the encrypted first shared key to obtain the first shared key.

[0385] According to an example, the authentication method may include an operation in which the eSIM encrypts the first temporary value and the generated second temporary value received from the CP with the acquired first shared key and transmits the encrypted data to the CP.

[0386] In one example, the authentication method may include an operation in which the CP decrypts the encrypted data received from the eSIM using the second shared key to obtain a third nonce.

[0387] In one example, the authentication method may include an operation of identifying whether the CP's acquired third temporary value and the generated first temporary value are substantially identical.

[0388] In one example, the authentication method may include an operation in which the CP determines authentication success or failure based on the identification result.

[0389] In one example, the authentication request may occur in response to the booting of the CP.

[0390] In one example, the authentication request may occur in response to a soft reset of the eSIM.

[0391] In one example, the authentication request may occur in response to a refresh of the eSIM.

[0392] In one example, the authentication method may cause the CP (313) to perform an operation of transmitting the shared information to the eSIM (350) in response to a binding request.

[0393] According to an example, the authentication method may include an operation in which the eSIM (350) stores the shared information received from the CP (313) in the internal memory.

[0394] According to an example, the authentication method may include an operation that does not restrict the use of a profile stored in the eSIM (350) by the CP (313) if authentication for the eSIM (350) is successful.

[0395] In one example, the authentication method may include an operation of restricting the use of a profile stored in the eSIM (350) by the CP (313) if authentication for the eSIM (350) fails.

[0396] According to an example, the authentication method may include an operation of allowing access to the network (111a) by the CP (313) when authentication for the eSIM (350) is successful.

[0397] According to an example, the authentication method may include an operation of restricting access to the network (111a) by the CP (313) or an operation of restricting use of some or all functions of the CP (313) if authentication for the eSIM (350) fails.

[0398] It should be understood that the embodiments of this document and the terminology used herein are not intended to limit the technical features described in this document to a specific embodiment, but include various modifications, equivalents, or substitutes of the embodiment. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the item, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0399] The term "module" used in one embodiment of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0400] An embodiment of the present document may be implemented as software including one or more instructions stored in a storage medium (e.g., memory (340)) readable by a machine (e.g., electronic device (101)). For example, a processor (e.g., processor (310)) of the machine (e.g., electronic device (101)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the recording medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the recording medium.

[0401] According to one embodiment, the method according to one embodiment disclosed in the present document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable recording medium (e.g., compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated on a machine-readable recording medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0402] According to one embodiment, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to one embodiment, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to one embodiment, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. In an electronic device (101), An embedded subscriber identity module (eSIM) (350) comprising an internal memory and configured to store a profile in the internal memory; A memory (340) including one or more recording media and storing instructions; and A communication processor (CP) (313) including a processing circuit - shared information is shared between the CP (313) and the eSIM (350), When the above instructions are individually or collectively executed by at least one processor including the CP (313), they cause the electronic device (101) to perform at least one operation, At least one of the above actions: In response to an authentication request, an operation (operation 420) of performing authentication on the eSIM (350) using the first shared information obtained by the CP (313) and the second shared information stored in the eSIM (350); and An electronic device (101) including an operation for restricting the use of the CP (313) depending on whether authentication for the eSIM (350) is successful.

2. In paragraph 1, The above first shared information is a first shared value recorded in a specific memory accessible to the CP (313), The above second shared information is a second shared value recorded in the internal memory of the eSIM, An electronic device (101), wherein the above-mentioned specific memory is one of a one-time programmable (OTP) memory (820, 840) or an electronic fuse (eFUSE) memory.

3. In paragraph 1, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: If the second shared key obtained by the CP (313) in response to the authentication request is stored in the eSIM (350), an operation for determining that authentication for the eSIM (350) is successful (operation 1060, operation 1180); and If the second shared key obtained by the CP (313) in response to the authentication request is not stored in the eSIM (350), it causes an operation (operation 1060, operation 1180) to be performed to determine that authentication for the eSIM (350) has failed. Here, the second shared key is an electronic device (101) having a shared value substantially identical to the first shared key.

4. In paragraph 2, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: An operation in which the CP obtains the first shared value in response to the authentication request; An operation in which the CP transmits the first shared value obtained to the eSIM; An operation of identifying whether the first shared value received by the eSIM from the CP and the second shared value stored in the internal memory are substantially the same; and An operation in which the eSIM transmits information indicating authentication success or failure to the CP based on the identification result. An electronic device (101) that causes the device to perform a function.

5. In paragraph 2, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: An operation in which the CP obtains the first shared value in response to the authentication request; An operation in which the eSIM transmits the second shared value stored in the internal memory to the CP in response to the authentication request; An operation for identifying whether the first shared value obtained by the CP and the second shared value received from the eSIM are substantially the same; and The above CP determines the success or failure of authentication based on the above identification result. An electronic device (101) that causes the device to perform a function.

6. In paragraph 1, The above first shared information is a first shared key obtained by applying a first shared value recorded in a specific memory accessible to the CP (313) to a specific encryption algorithm. The above second shared information is the second shared key recorded in the internal memory of the eSIM, An electronic device (101), wherein the above-mentioned specific memory is one of a one-time programmable (OTP) memory (820, 840) or an electronic fuse (eFUSE) memory.

7. In paragraph 6, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: In response to the authentication request, the eSIM generates a first nonce; An operation in which the eSIM transmits the generated first temporary value to the CP; The above CP generates a second nonce; An operation in which the CP encrypts the first temporary value received from the eSIM and the second temporary value generated using the first shared key and transmits the encrypted data to the eSIM; An operation in which the eSIM decrypts the encrypted data received from the CP using the second shared key to obtain a third nonce; An operation of identifying whether the third temporary value obtained by the eSIM and the first temporary value generated are substantially the same; and An operation in which the eSIM transmits information indicating authentication success or failure to the CP based on the identification result. An electronic device (101) that causes the device to perform a function.

8. In paragraph 6, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: The above CP (313) encrypts and stores the first shared key; An operation in which the eSIM generates a first nonce in response to the authentication request; An operation in which the eSIM transmits the generated first temporary value to the CP; The above CP generates a second nonce; An operation in which the CP decrypts the encrypted first shared key to obtain the first shared key; An operation in which the CP encrypts the first temporary value received from the eSIM and the second temporary value generated using the acquired first shared key and transmits the encrypted data to the eSIM; An operation in which the eSIM decrypts the encrypted data received from the CP using the second shared key to obtain a third nonce; An operation of identifying whether the third temporary value obtained by the eSIM and the first temporary value generated are substantially the same; and An operation in which the eSIM transmits information indicating authentication success or failure to the CP based on the identification result. An electronic device (101) that causes the device to perform a function.

9. In paragraph 6, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: In response to the above authentication request, the CP generates a first nonce; An operation in which the CP transmits the generated first temporary value to the eSIM; The above eSIM generates a second nonce; An operation in which the eSIM encrypts the first temporary value received from the CP and the second temporary value generated using the second shared key and transmits the encrypted data to the CP; An operation in which the CP decrypts the encrypted data received from the eSIM using the first shared key to obtain a third nonce; An operation for identifying whether the third temporary value obtained by the CP and the first temporary value generated are substantially the same; and The above CP determines the success or failure of authentication based on the above identification result. An electronic device (101) that causes the device to perform a function.

10. In paragraph 6, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: The above CP (313) encrypts and stores the first shared key; An operation in which the CP generates a first nonce in response to the authentication request; An operation in which the CP transmits the generated first temporary value to the eSIM; The above eSIM generates a second nonce; An operation in which the eSIM decrypts the encrypted first shared key to obtain the first shared key; An operation in which the eSIM encrypts the first temporary value received from the CP and the second temporary value generated using the acquired first shared key and transmits the encrypted data to the CP; An operation in which the CP decrypts the encrypted data received from the eSIM using the second shared key to obtain a third nonce; An operation for identifying whether the third temporary value obtained by the CP and the first temporary value generated are substantially the same; and The above CP determines the success or failure of authentication based on the above identification result. An electronic device (101) that causes the device to perform a function.

11. In any one of paragraphs 1 to 10, An electronic device (101), wherein the authentication request occurs in response to at least one of a booting of the CP, a soft reset of the eSIM, or a refresh of the eSIM.

12. In any one of paragraphs 1 to 10, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: In response to a binding request, the CP (313) transmits the shared information to the eSIM (350); and An operation in which the eSIM (350) stores the shared information received from the CP (313) in the internal memory. An electronic device (101) that causes the device to perform a function.

13. In any one of paragraphs 1 to 10, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: If authentication for the eSIM (350) is successful, an operation that does not restrict the use of the profile stored in the eSIM (350) by the CP (313); and If authentication for the eSIM (350) fails, an operation to restrict the use of the profile stored in the eSIM (350) by the CP (313) An electronic device (101) that causes the device to perform a function.

14. In any one of paragraphs 1 to 10, When the above instructions are individually or collectively executed by at least one processor, the electronic device (101) causes: If authentication for the above eSIM (350) is successful, an operation of allowing access to the network (111a) by the CP (313); and If authentication for the above eSIM (350) fails, an operation to restrict access to the network (111a) by the CP (313) or an operation to restrict use of some or all functions of the CP (313) An electronic device (101) that causes the device to perform a function.

15. In the authentication method of an electronic device (101), In response to an authentication request, an operation (operation 420) of performing authentication on the eSIM (350) using first shared information acquired by a communication processor (CP) and second shared information stored in the embedded subscriber identity module (eSIM) (350); and An authentication method including an operation of restricting the use of the CP (313) depending on whether authentication of the eSIM (350) is successful.

Images