JP7463943B2 - Embedded Subscriber Identity Module - Google Patents

Description

The present invention relates to an embedded subscriber identity module that is installed inside a mobile device with mobile communication capabilities.

Mobile devices with mobile communication capabilities require a subscriber identity module that is pre-provisioned with a profile (sometimes called a communication profile) to receive mobile services provided by a mobile network operator (MNO).

Conventional subscriber identity modules are card-type media. A subscriber identity module, which is a card-type medium, is provisioned with a profile of a specific MNO at the time of manufacture. For this reason, in order to change the MNO, it is necessary to replace the card-type subscriber identity module attached to the mobile device with another card-type subscriber identity module provisioned with the profile of the MNO to which the change is to be made.

If it is necessary to replace a card-type subscriber identity module in order to change MNOs, the consumer must obtain a card-type subscriber identity module provisioned with the profile of the MNO to which the consumer is to change, meaning that the consumer cannot easily change MNOs. In addition, from the MNO's perspective, there are disadvantages, such as the costs associated with managing the inventory of card-type subscriber identity modules provisioned with the MNO's own information.

To solve this problem, the specifications for embedded subscriber identity modules that support remote provisioning via OTA (Over The Air) have been standardized by the standardization organization GSMA (GSM Association) (for example, Non-Patent Document 1).

Figure 3 is a diagram explaining the embedded subscriber identity module 2, and the structure of the embedded subscriber identity module 2 illustrated in Figure 3 is based on standards such as Non-Patent Document 1. Note that this is merely a brief explanation of the structure of the embedded subscriber identity module 2, and for details on the embedded subscriber identity module 2, please refer to documents such as Non-Patent Document 1.

As shown in FIG. 3, the embedded subscriber identity module 2 is implemented with an operating system (OS), which is software that provides various platform functions to applications (sometimes called applets), and hardware as a platform 22.

The embedded subscriber identity module 2 also implements one ECASD25 (eUICC Controlling Authority Security Domain), one ISD-R24 (Issuer Security Domain Root), and at least one ISD-P21 (Issuer Security Domain Profile) as security domains (SDs) realized by applications that use the platform functions.

The ISD-R24 is the SD that serves as the root of the embedded subscriber identity module 2. The ISD-R24 has functions such as building a secure OTA channel and functions related to the generation and deletion of ISD-P21.

The ISD-P21 is an SD that stores the profile 20 of the MNO that provides the mobile service. The ISD-P21 corresponds to a conventional subscriber identity module. The profile 20 stored in the ISD-P21 includes data and applications required to receive the mobile services provided by the MNO, as well as applications that add value to the mobile services provided by the MNO (for example, NFC (Near Field Communication) applications).

The number of profiles that can be stored in a card-type subscriber identity module is limited to one. In contrast, an embedded subscriber identity module 2 can store multiple ISP-Ps 21, but only one ISP-P 21 can be set as valid. In Figure 3, three ISD-Ps 21 are stored in the embedded subscriber identity module 2. In Figure 3, the ISD-Ps 21 that have been set as valid are surrounded by solid lines, and the ISD-Ps 21 that have been set as invalid are surrounded by dashed lines. As shown in Figure 3, even if three ISD-Ps 21 are stored in the embedded subscriber identity module 2, only one ISD-P 21 can be set as valid, and the other ISD-Ps 21 are set as invalid.

Security devices with security functions are at risk of being subjected to external fault attacks by attackers. For this reason, security devices are required to be tamper-resistant against fault attacks. Since embedded subscriber identity modules are classified as security devices, embedded subscriber identity modules are also required to be tamper-resistant against fault attacks.

A fault attack on a security device is an attack that causes the IC chip installed in the security device to malfunction and reads security-critical information. A typical fault attack method for a security device is, for example, a laser attack method in which a laser is irradiated on the IC chip to change the data stored in the memory.

Various countermeasures against such fault attacks have already been considered. For example, in order to reduce the risk of malfunction due to a fault attack that tampers with memory contents, the security device disclosed in Patent Document 1 executes a process to stop the operation of the virtual machine when the execution opcode is a designated opcode and verification of the validity of the execution opcode fails. In the invention disclosed in Patent Document 1, when the memory contents are tampered with due to a fault attack, the risk of malfunction due to a fault attack that tampers with memory contents can be reduced by designating as the designated opcode an opcode that is the same value as the memory contents that are easily converted, or an opcode that may cause security problems if erroneously converted and executed.

However, if the embedded subscriber identity module 2 detects a fault attack from an attacker and the use of the embedded subscriber identity module 2 is stopped, if multiple profiles 20 are stored in the embedded subscriber identity module 2, the profiles 20 that have not been subjected to the fault attack, i.e., the invalid profiles 20, will also become unusable, which is a problem.

Japanese Patent No. 5200664

Remote Provisioning Architecture for Embedded UICC Technical Specification (GSM Association)

The present invention aims to provide an embedded subscriber identity module that can specify a profile to be deleted when a fault attack is detected.

The first invention for solving the problems related to the present invention is an embedded subscriber identity module characterized by comprising: a profile that stores policy rules that define actions to be taken when a fault attack is detected; a security domain that detects fault attacks received during execution of command processing using a predetermined attack detection algorithm related to the fault attack and sets the profile state of the profile to an attack detection state when a fault attack is detected; and a policy enforcement unit that monitors the profile state of enabled profiles and, when the profile state of the profile becomes an attack detection state, deletes all profiles for which the action is to delete the profile, regardless of whether the profile is enabled or disabled.
In the present invention, it is preferable that for each command processing to which the attack detection algorithm is applied to detect a fault attack, a degree of danger when subjected to a fault attack is set, and the action corresponding to the degree of danger is defined for each degree of danger in the policy rule, the security domain indicates the degree of danger corresponding to the command processing when subjected to a fault attack in the attack detection status, and the policy enforcement unit deletes all profiles for which the action corresponding to the degree of danger indicated in the attack detection status is to delete the profile.
Furthermore, in the present invention, the content of the attack detection algorithm is arbitrary, but it is preferable to use an attack detection algorithm that detects a fault attack by utilizing the time required for command processing.

The present invention described above provides an embedded subscriber identity module that can specify a profile to be deleted when a fault attack is detected.

FIG. 2 is a diagram for explaining the structure of an eUICC according to the present embodiment. FIG. 2 is a diagram for explaining the operation of the eUICC according to the embodiment. FIG. 2 illustrates an embedded subscriber identity module.

From here, an embodiment of the present invention will be described. This embodiment is intended to facilitate understanding of the present invention, and the present invention is not limited to this embodiment. Furthermore, unless otherwise specified, the drawings are schematic diagrams drawn to facilitate understanding of the present invention.

The present invention relates to an embedded subscriber identity module. The embedded subscriber identity module is sometimes called an eSIM (embedded subscriber identity module), but in this embodiment, the embedded subscriber identity module is referred to as an eUICC (embedded Universal Integrated Circuit Card) in accordance with the GSMA standard.

Figure 1 is a diagram explaining the structure of an eUICC 1 according to this embodiment. In Figure 3, the hardware 16 and the operating system 12 (OS) are described without distinction, but in Figure 1, the hardware 16 and the OS 12 are described separately.

In the configuration of hardware 16 illustrated in FIG. 1, a CPU 160 (short for Central Processing Unit) is connected to a RAM 162 (Random Access Memory), a ROM 161 (Read Only Memory), a NVM 164 (Non-volatile memory), a UART 166 (Universal Asynchronous Receiver/Transmitter), a timer 165, and an accelerator 163 via a bus 167. The RAM 162 is a volatile memory that serves as the main memory of the eUICC 1, and the ROM 161 is a non-volatile memory that cannot be electrically rewritten. The NVM 164 is a non-volatile memory that can be electrically rewritten. The UART 166 is a circuit that controls communication with a mobile device in which the eUICC 1 is embedded, the timer 165 is a circuit that measures time, and the accelerator 163 is a circuit that increases the processing speed of cryptographic operations.

In the eUICC1, the following software is implemented: OS 12 and multiple security domains (SD) that operate based on OS 12. The program code of OS 12 is mainly stored in ROM 161. The program code of the SD is stored in NVM 164.

The OS 12 provides various platform functions to the SD that operates based on the OS 12. The OS 12 according to this embodiment includes a policy enforcement unit 13 that executes processing in accordance with the policy rules 100 stored in the profile 10.

SD is an application that provides domain separation and domain-related security functions. The eUICC 1 shown in Figure 1 implements one ECASD 15 (eUICC Controlling Authority Security Domain), one ISD-R 14 (Issuer Security Domain Root), and one ISD-P 11 (Issuer Security Domain Profile).

ECASD15 will be the SD of the eUICC1 certification authority. ECASD15 is associated with ISD-R14, which establishes a secure OTA channel, and has the function of generating cryptographic key pairs for the public cryptography used by ISD-P11 and ISD-R14.

ISD-R14 is the root SD in eUICC1. ISD-R14 has functions such as building a secure OTA channel and generating and deleting ISD-P11.

The ISD-P11 is an SD that stores a profile 10 of an MNO (Mobile Network Operator). The ISD-P11 in this embodiment corresponds to the SD according to the present invention.

Multiple ISD-P11s can be stored in one eUICC1, but the number of ISD-P11s that can be set as valid is limited to one. The profile 10 stored in an ISD-P11 that is set as valid becomes valid in the eUICC1. In Figure 1, three ISD-P11s are stored in the eUICC1. In Figure 1, ISD-P11s that are set as valid are surrounded by solid lines, and ISD-P11s that are set as invalid are surrounded by dashed lines. As shown in Figure 1, even if multiple ISD-P11s are stored in the eUICC1, only one ISD-P11 can be set as valid, and the other ISD-P11s are set as invalid.

The profile 10 stored in the ISD-P 11 stores data and applications required to receive mobile services provided by the MNO. In FIG. 1, the profile 10 includes an MNO-SD 101, which is the SD of the MNO. The profile 10 also includes a file system 102, an NAA (Network Access application) 103, which is an application for connecting to a mobile communication network provided by the MNO, and an application 104 (e.g., an NFC application) for adding value to the MNO's mobile services.

Furthermore, the profile 10 includes policy rules 100, which are metadata for the profile 10. The policy rules 100, which are metadata for the profile 10, are not associated with the MNO-SD 101, and can be accessed by the ISD-R 14 and the OS 12.

The policy rule 100 according to this embodiment defines the action to be taken when a fault attack is detected. The policy rule 100 that defines the action to be taken when a fault attack is detected is set by the MNO that corresponds to the profile 10.

As one of the security functions related to the profile 10 stored in the ISD-P11, the ISD-P11 has a function of transitioning the profile state of the profile 10. The ISD-P11 according to this embodiment uses a predetermined attack detection algorithm related to fault attacks to detect fault attacks received during command processing, and when a fault attack is detected, it sets the profile state of the profile 10 from valid to attack detection state.

The specific contents of the attack detection algorithm are arbitrary, but the ISD-P11 according to this embodiment detects external fault attacks by utilizing the change in the time required for command processing when a fault attack occurs during command processing. By detecting external fault attacks by utilizing the change in the time required for command processing, external fault attacks can be detected by software without the need for a special circuit in the eUICC1.

The policy enforcement unit 13 provided in the OS 12 implemented in the eUICC 1 monitors the profile status of the ISD-P 11 that is enabled in the eUICC 1. When the profile status of the ISD-P 11 becomes an attack detection status, the policy enforcement unit 13 executes a process to delete all profiles 10 implemented in the eUICC 1 for which the action to be taken when a fault attack is detected is set to delete, regardless of whether the profile 10 is enabled or disabled. Note that deleting a profile 10 means deleting the profile 10 and the ISD-P 11 that stores it.

Figure 2 is a diagram explaining the operation of the eUICC1 according to this embodiment. As described above, in the eUICC1 according to this embodiment, the entity that detects external fault attacks is the valid ISD-P11, and the entity that deletes the profile 10 is the policy enforcement unit 13 provided in the OS 12.

When the command sent to the eUICC1 is a command to detect a fault attack by applying an attack detection algorithm, the ISD-P11 provided in the eUICC1 uses the timer 165 to start measuring the time required to process the command sent to the eUICC1 (step S1) and then executes the command sent to the eUICC1 (step S2). A command to detect a fault attack by applying an attack detection algorithm is a command that performs security-critical processing, such as an authentication command that performs cryptographic calculations using the accelerator 163. In addition, the application that executes the command sent to the eUICC1 is the application (including the ISD-P11) that corresponds to the command sent to the eUICC1.

When the processing of the command sent to eUICC1 is completed, ISD-P11 stops measuring the time required to process the command sent to eUICC1 (step S3), and determines whether the time required for the command is normal or abnormal by comparing the time required for the command with the average time required for the command (step S4).

In this embodiment, the comparison of the required time of a command with the average required time of a command uses a lower limit value of the required time (a time less than 100% of the average processing time) or an upper limit value of the required time (a time greater than 100% of the average processing time). The lower limit value and the upper limit value can be set arbitrarily as values relative to the average required time.

For example, in the case of a command whose required time becomes extremely short when subjected to a fault attack, the ISD-P11 determines that the required time of the command is abnormal if the required time of the command is less than the lower limit of the required time of the command calculated using the average required time. In the case of a command whose processing time becomes extremely long when subjected to a fault attack, the ISD-P11 determines that the required time of the command is abnormal if the required time of the command exceeds the upper limit of the required time of the command calculated using the average required time.

If the ISD-P11 determines that the time required for the command sent to the eUICC1 is not abnormal, it updates the average time required for the command using the time required for the command measured this time (step S5), and then the procedure in Figure 2 ends.

If the ISD-P11 determines that the time required for the command sent to the eUICC1 is abnormal, it determines that the ISD-P11 or the profile 10 stored in the ISD-P11 has been subjected to a fault attack, and sets the profile state of the ISD-P11 to an attack detection state (step S6).

The policy enforcement unit 13 of the OS 12, which monitors the profile status of the ISD-P 11 enabled in the eUICC 1, executes a process (step S7) to delete the profile 10 implemented in the eUICC 1 when the profile status of the ISD-P 11 enabled in the eUICC 1 becomes an attack detection status, and then the procedure in FIG. 2 ends.

In the process of deleting the profile 10 implemented in the eUICC 1 (step S7), the policy enforcement unit 13 of the OS 12 executes a loop process (step S10) that is repeatedly executed for each profile 10 implemented in the eUICC 1 (which is for each ISD-P 11).

In the loop processing (step S10), first, the policy enforcement unit 13 of the OS 12 reads the policy rule 100 contained in the profile 10 of the ISD-P 11 (step S11). Next, the policy enforcement unit 13 of the OS 12 determines whether the action to be taken when a fault attack is detected is deletion (step S12). Next, if the policy rule 100 indicates that the profile 10 should be deleted, the policy enforcement unit 13 of the OS 12 deletes the profile 10 and the ISD-P 11 that stores it (step S13). Note that if the policy rule 100 does not indicate that the profile 10 should be deleted, the profile 10 and the ISD-P 11 that stores it are not deleted.

The explanation so far has not taken into account the degree of risk when a fault attack occurs, but in reality, the degree of risk when a fault attack occurs varies depending on the command processing. For this reason, in this invention, it is desirable to be able to change the measures taken when a fault attack is detected depending on the degree of risk of the command processing that has been subjected to the fault attack.

When changing the action taken when a fault attack is detected depending on the risk of the command process subjected to the fault attack, the risk of a fault attack is set for each command process that detects a fault attack by applying the attack detection algorithm. For example, a command process that is highly dangerous when subjected to a fault attack may be a command process related to an authentication command that performs cryptographic calculations using an accelerator. Furthermore, the policy rule 100 defines the action to be taken for each risk level.

In this case, in step S6 of FIG. 2, the ISD-P11 sets the profile state of the profile 10 to an attack detection state that indicates the risk level corresponding to the command processing when a fault attack is received. For example, the risk level can be indicated in the attack detection state by changing the attack detection state set in the profile state of the profile 10 for each risk level corresponding to the command processing when a fault attack is received. The risk level can also be indicated in the attack detection state by including the risk level corresponding to the command processing when a fault attack is received. In addition, in step S13 of FIG. 2, the policy enforcement unit 13 deletes all profiles 10 for which the action corresponding to the risk level indicated in the attack detection state is to delete the profile 10.

1. eUICC
10 Profile 100 Policy rule 11 ISD-P
110 Profile Status 12 Operating System (OS)
13. Policy Enforcement Division

Claims (3)

An embedded subscriber identity module characterized by comprising: a profile that stores policy rules that define the action to be taken when a fault attack is detected; a security domain that detects a fault attack received during execution of a command process using a predetermined attack detection algorithm related to the fault attack, and sets the profile state of the profile to an attack detection state when a fault attack is detected; and a policy enforcement unit that monitors the profile state of the enabled profile, and deletes all profiles for which the action is to delete the profile, regardless of whether the profile is enabled or disabled, when the profile state of the profile becomes an attack detection state. The embedded subscriber identity module according to claim 1, characterized in that for each command process to which the attack detection algorithm is applied to detect a fault attack, a degree of danger when a fault attack is received is set, and the action corresponding to the degree of danger is defined for each degree of danger in the policy rule, the security domain indicates the degree of danger corresponding to the command process when a fault attack is received in an attack detection state, and the policy enforcement unit deletes all the profiles for which the action corresponding to the degree of danger indicated in the attack detection state is to delete the profile. An embedded subscriber identity module as described in claim 1 or claim 2, characterized in that it uses an attack detection algorithm that detects fault attacks by utilizing the time required for command processing.

Images