Managing firmware updates for integrated components within mobile devices

Abstract

Herein is disclosed a technique for updating the firmware of an embedded universal integrated circuit card (eUICC) included in a mobile device.The technique includes steps of (1) receiving, from a firmware provider, a notification that updated firmware is available for the eUICC, (2) in response to the notification, providing to the firmware provider (i) a unique identifier (ID) associated with the eUICC, and (ii) a nonce value, (3) following the provision, receiving from the firmware provider a firmware update package, wherein the firmware update package includes (i) authentication information and (ii) the updated firmware, (4) following verification of the authentication information, persistently storing to memory included in the mobile device a hash value corresponding to the updated firmware, and (5) installing the updated firmware on the eUICC.

Description

Area

[0001] The described embodiments provide a technique for managing firmware updates for integrated components, such as embedded universal integrated circuit cards (eUICCs) configured to manage electronic subscriber identity modules (eSIMs) within mobile devices. background

[0002] Most mobile devices are configured to receive removable universal integrated circuit cards (UICCs), which allow the mobile devices to access services provided by mobile network operators (MNOs). Specifically, each UICC includes at least a microprocessor and read-only memory (ROM), with the ROM configured to store an MNO profile that the mobile device can use to register with and interact with the MNO. Typically, a UICC is in the form of a small removable card (usually called a SIM card) configured to be inserted into a UICC receiver slot within a mobile device. However, in more recent implementations, UICCs are embedded directly into the system board of mobile devices.In particular, these embedded UICCs (eUICCs) can offer several advantages over traditional, removable UICCs. For example, eUICCs can include rewritable memory, facilitating eSIM updates to access advanced features provided by the MNO. eUICCs can also eliminate the need for UICC receiving slots within mobile devices. The adoption of eUICCs thus not only increases the flexibility of mobile devices but also simplifies their design and frees up space for other components.

[0003] The prior art document US 2015 / 0072726A1 describes a mobile communication device with multiple operating states, comprising a housing and an input device connected to the housing. By actuating the input device, a user can change and verify at least one operating state of the mobile communication device. The mobile communication device also includes a display connected to the input device and configured to provide feedback to the user based on the operating state of the mobile communication device.

[0004] The prior art document US 2015 / 0143125A1 describes a module with an embedded universal integrated circuit board (eUICC) that includes a received eUICC profile and a set of cryptographic algorithms. The prior art document US 2015 / 0220319A1 describes a method for updating the firmware of a security module in a device.

[0005] The state of the art document US 2009 / 0313472A1 describes a method and device for securing an interface between a Universal Integrated Circuit Card (UICC) and an end device in wireless communication.

[0006] In some cases, it may be desirable to update the firmware of an eUICC so that the eUICC can provide new or improved services to a user of the mobile device containing the eUICC. However, firmware updates can be quite risky, as hardware components can become permanently inoperable if the update is not performed correctly. This drawback is particularly significant for eUICCs, as they are embedded inside mobile devices and cannot be easily replaced if firmware corruption occurs.

[0007] It is an object of the present invention to eliminate or at least reduce the disadvantages of the prior art concerning firmware updates. Summary

[0008] The present invention solves the problem with a method for updating firmware and with a mobile device according to independent claims 1 and 10. Advantageous further developments are specified in the dependent claims. Representative embodiments shown herein disclose various techniques for managing the firmware of an eUICC included in a mobile device. In particular, the eUICC is configured to manage primary firmware and backup firmware and to implement a firmware loader to keep current and functional firmware intact within the eUICC. When the primary firmware is functional and enabled within the eUICC, the firmware loader can obtain and perform a primary firmware update.If the primary firmware is not functioning—for example, if it becomes corrupted during normal operation or if a primary firmware update was not performed correctly—the firmware loader can receive the backup firmware and replace the primary firmware with it. Conversely, the backup firmware can be used to restore the eUICC to working order, after which the firmware loader can attempt to restore a functioning primary firmware within the eUICC. In some cases, it may be desirable to update the backup firmware, so the firmware loader is also configured to receive and install updated backup firmware within the eUICC. It should be noted that the aforementioned firmware management techniques can be implemented without affecting other data (e.g.,eSIMs), which are managed by the eUICC, further contributing to the promotion of robust functionality of the eUICC.

[0009] One embodiment presents a method for updating the firmware of an embedded universal integrated circuit card (eUICC) included in a mobile device.In particular, the procedure is implemented by the eUICC and includes the steps of (1) receiving, from a firmware provider, a notification that updated firmware is available for the eUICC, (2) in response to the notification, providing to the firmware provider (i) a unique identifier (ID) associated with the eUICC, and (ii) a nonce value, (3) after providing, receiving from the firmware provider a firmware update package, wherein the firmware update package includes (i) authentication information and (ii) the updated firmware, (4) after verifying the authentication information, persistently storing in a memory included in the mobile device a hash value corresponding to the updated firmware, and (5) installing the updated firmware on the eUICC.

[0010] Another embodiment is an embedded universal integrated circuit card (eUICC) configured to perform a firmware recovery procedure. Specifically, the eUICC includes non-volatile memory and a processor configured to perform the steps of: (1) detecting a fault in the primary firmware of the eUICC, (2) retrieving a backup firmware for the eUICC from the non-volatile memory, and (3) replacing the primary firmware with the backup firmware, the backup firmware enabling the subsequent installation of a different primary firmware.

[0011] Yet another embodiment presents a mobile device that includes an eUICC configured to perform a firmware update.Specifically, the eUICC is configured to perform the following steps: (1) receiving a notification from a firmware vendor that updated backup firmware is available for the eUICC; (2) in response to the notification, providing to the firmware vendor (i) a unique identifier (ID) associated with the eUICC and (ii) a nonce value; (3) receiving from the firmware vendor a firmware update package, the firmware update package containing (i) authentication information and (ii) the updated backup firmware; and (4) after verifying the authentication information, continuously storing (i) the updated backup firmware and (ii) a hash value based on the updated backup firmware into memory included in the mobile device.

[0012] This summary serves only to encapsulate some example implementations in order to provide a basic understanding of some aspects of the subject matter described herein. Accordingly, it should be understood that the features described above are merely examples and are not intended to limit in any way the scope or spirit of the subject matter described herein. Other features, aspects, and advantages of the subject matter described herein will become clear from the subsequent detailed description, figures, and claims.

[0013] Other aspects and advantages of the embodiments described herein will become apparent from the following detailed description, together with the accompanying drawings, which exemplify the principles of the described embodiments. Brief description of the drawings

[0014] The accompanying drawings are for illustrative purposes only and serve to provide examples of possible structures and arrangements for the disclosed inventive devices and methods for providing wireless computing devices. These drawings do not in any way limit any changes in form and detail that a person skilled in the art could make to the embodiments without departing from the spirit and scope of the embodiments. The embodiments are readily understood from the detailed description below in conjunction with the accompanying drawings, where the same reference numerals denote the same structural elements. Fig. Figure 1 illustrates a block diagram of different components of a system configured to implement the various techniques described herein according to some embodiments. Fig. Figure 2 illustrates a block diagram in a more detailed view of specific components of the system. Fig. 1 according to some embodiments. Fig. Figure 3 illustrates a flowchart of a procedure for updating a primary firmware of an eUICC included in a mobile device, according to one embodiment. Fig. Figure 4 illustrates a flowchart of a procedure for using a backup firmware of the eUICC to perform a recovery technique when the primary firmware of the eUICC is corrupted, according to one embodiment. Fig. Figure 5 illustrates a flowchart of a procedure for updating the backup firmware of the eUICC according to one embodiment. Fig. Figure 6 illustrates a procedure for a high-level technique that implements various techniques associated with Fig. 3, Fig. 4 to Fig. 5 described in order to keep current and functional firmware intact within the eUICC according to one embodiment. Fig. Figure 7 illustrates a detailed view of a computing device that can be used to implement various components described herein according to some embodiments. Detailed description

[0015] Representative applications of devices and methods corresponding to the embodiments described herein are provided in this section. These examples are provided only to add context and aid in understanding the described embodiments. Therefore, it will be clear to those skilled in the art that the embodiments described herein can be carried out without some or all of these specific details. In other cases, generally known process steps have not been described in detail to avoid unnecessary ambiguity regarding the embodiments described herein. Other applications are possible, so the examples provided should not be considered limiting.

[0016] The embodiments described herein provide various techniques for managing the firmware of an eUICC that is included in a mobile device. According to one embodiment, the eUICC is configured to implement a firmware loader that maintains current and functional firmware within the eUICC. To achieve this, the firmware loader is configured to manage primary firmware and backup firmware. The primary firmware is the firmware used by the eUICC when the eUICC is operating in normal mode and provides various functionalities for the mobile device in which the eUICC is included. Conversely, the backup firmware is the firmware used by the eUICC when the primary firmware becomes unusable (e.g., due to a device failure).(If the primary firmware becomes corrupted), the backup firmware restores the eUICC's functionality and allows the eUICC to attempt a new primary firmware installation. Depending on some implementations, the firmware loader can be configured to update both the primary and backup firmware and perform the firmware updates within the eUICC. This might involve, for example, an interface with an external entity—such as a manufacturer or management unit of the eUICC / mobile device—and the secure downloading of firmware updates specific to the eUICC / mobile device.

[0017] If the primary firmware is functional and enabled within the eUICC, the firmware loader can receive and perform a primary firmware update. If the primary firmware is not functional—for example, if it becomes corrupted during normal operation or if a primary firmware update was not performed correctly—the firmware loader can receive the backup firmware and replace the primary firmware with it. Conversely, the backup firmware can be used to restore the eUICC to functionality, after which the firmware loader can attempt to restore a functional primary firmware within the eUICC. In some cases, it may be desirable to update the backup firmware; therefore, the firmware loader is also configured to receive and install updated backup firmware within the eUICC.The preceding techniques are described in more detail below in conjunction with the . Fig. 1, Fig. 2, Fig. 3, Fig. 4, Fig. 5, Fig. 6 to Fig. 7 described.

[0018] In accordance with various embodiments described herein, the terms "wireless communication device," "wireless device," "mobile device," "mobile station," and "user equipment" (UE) may be used interchangeably herein to describe one or more common consumer electronic devices capable of performing the methods associated with various embodiments of the disclosure. In accordance with various implementations, any of these consumer electronic devices may refer to: a cellular phone or smartphone, a tablet computer, a laptop computer, a notebook computer, a personal computer, a netbook computer, a media player device, an electronic book device, a MiFi® device, a body-worn computing device, and any other type of electronic computing device.which has a wireless communication capability, which may include communication via one or more wireless communication protocols, for example, for communication on: a wireless wide area network (WWAN), a wireless metro area network (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN), near field communication (NFC), a cellular wireless network, a fourth generation (4G) LTE network, an LTE Advanced (LTE-A) network and / or a 5G network or other current or future advanced cellular wireless networks.

[0019] In some embodiments, the wireless communication device can operate as part of a wireless communication system, which may include a set of client devices, also referred to as stations, wireless client devices, or wireless client communication devices, connected to an access point (AP), such as as part of a WLAN and / or to each other, e.g., as part of a WPAN and / or an ad-hoc wireless network. In some embodiments, the client device may be any wireless communication device capable of communicating via WLAN technology, e.g., in accordance with a wireless local area network communication protocol. In some embodiments, the WLAN technology may include a WiFi (or more generally, a WLAN) wireless communication subsystem or radio device, wherein the WiFi radio device is an 802.can implement IEEE 802.11 technologies of the Institute of Electrical and Electronics Engineers (IEEE), such as one or more of: IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; or other current or future IEEE 802.11 technologies.

[0020] Additionally, it should be understood that the UEs described herein can be configured as multi-mode wireless communication devices capable of communicating over different third-generation (3G) and / or second-generation (2G) RATs. In these scenarios, a multi-mode UE may be configured to prioritize connectivity to LTE networks, which offer faster data rate throughput than other legacy 3G networks, which offer lower data rate throughput. For example, in some implementations, a multi-mode UE may be configured to fall back to a legacy 3G network, such as an Evolved High Speed ​​Packet Access (HSPA+) network or a Code Division Multiple Access (CDMA)-2000 Evolution-Data Only (EV-DO) network, if LTE and LTE-A networks are otherwise unavailable.

[0021] Fig. Figure 1 illustrates a block diagram of different components of a system 100 configured to implement the various techniques described herein, according to some embodiments. In particular, it illustrates Fig. 1 A high-level overview of the system 100, which, as shown, includes a mobile device 102, a group of base stations 112 managed by different MNOs 114, and a firmware provider 116. According to the illustration of the Fig. 1. The mobile device 102 can be a mobile computing device (e.g., an Apple® iPhone® or iPad®), the base stations 112 can be different radio towers configured to communicate with the mobile device 102, and the MNOs 114 can be different wireless service providers offering specific services (e.g., voice and data) for which the mobile device 102 can register. Additionally, the firmware provider 116, as described in more detail below, can be one or more servers configured to communicate with the mobile device 102 and to securely deliver firmware updates to the mobile device 102.

[0022] As in Fig. As shown in Figure 1, the mobile device 102 can include a processor 104, a memory 106, an eUICC 108, and a baseband module 110. These components work together to enable the mobile device 102 to provide useful functions to a user of the mobile device 102, such as location-based computing, location-based services, and internet connectivity. As described in more detail below, the eUICC 108 can be configured to store multiple eSIMs to access the different MNOs 114 via the base stations 112. For example, the eUICC 108 can be configured to store one eSIM 208 for each MNO 114 to which the mobile device 102 is registered.As described in more detail below, the mobile device 102 - in particular the eUICC 108 included in the mobile device 102 - can be configured to receive and process firmware updates from the firmware provider 116 in accordance with the various techniques shown herein.

[0023] Fig. Figure 2 illustrates a block diagram of a more detailed view of certain components of the mobile device 102. Fig. 1 according to some embodiments. As in Fig. As shown in Figure 2, the processor 104, in conjunction with the memory 106, can implement a main operating system (OS) 202, which is configured to run applications (e.g., native OS applications and user applications). According to one embodiment, the main OS 202 can be configured to run an eUICC firmware update checker 204, which is configured to enable firmware updates between the firmware provider 116 and the eUICC 108. In particular, the eUICC firmware update checker 204 can be configured to periodically query the firmware provider 116 to detect when firmware updates are available for the eUICC 108.This can involve, for example, the eUICC firmware update checker 204 providing version information of the firmware currently used by eUICC 108, so that the firmware provider 116 can successfully determine whether a firmware update is available for eUICC 108. In some embodiments, the eUICC firmware update checker 204 can be configured to receive push notifications from the firmware provider 116 to improve the efficiency with which firmware update information is communicated between the eUICC firmware update checker 204 and the firmware provider 116.

[0024] As in Fig. As shown in Figure 2, the eUICC 108 can be configured to implement an eUICC OS 206, which is configured to manage the hardware resources of the eUICC 108 (e.g., a processor, random access memory (RAM), non-volatile memory, not in Fig. 2 shown). The eUICC OS 206 can be configured to manage eSIMs 208 stored by the eUICC 108, for example by enabling the eSIMs 208 within the eUICC 108 and providing the baseband module 110 with access to the eSIMs 208. As illustrated in Fig. As shown in Figure 2, each eSIM 208 can be associated with a unique identifier and can contain multiple applets that define how the eSIM 208 operates. For example, one or more of the applets, when implemented by the baseband module 110 and the eUICC 108, can be configured to allow the mobile device 102 to communicate with an MNO 114 to activate functions (e.g., phone calls and internet) of the mobile device 102.

[0025] As in Fig. As shown in Figure 2, the eUICC 108 can implement a firmware loader 210 configured to execute the various firmware update techniques shown herein. In particular, the firmware loader 210 can be configured to interface with the eUICC firmware update verifier 204 and to provide / receive information for the secure execution of a transmission and processing of firmware updates for the eUICC (illustrated as eUICC update packets 220 in Figure 2). Fig. 2) For example, and as described in more detail below, the firmware loader 210 can be configured to be notified by the eUICC firmware update checker 204 when firmware updates become available for the eUICC 108. It should be noted that in some embodiments, the functionality provided by the eUICC firmware update checker 204 may instead be provided by the firmware loader 210, so that the firmware loader 210 is configured to interface directly with the firmware provider 116.

[0026] As described in more detail below, upon receiving a notification that a firmware update is available, the firmware loader 210 can be configured to provide (i) a unique identifier associated with eUICC 108 and (ii) a nonce value that can be used by the firmware provider 116 when it generates a firmware update specific to eUICC 108. In return, the provider 116 delivers the firmware update to the firmware loader 210, whereupon the firmware loader 210 can analyze components of the firmware update (e.g., digital signatures) to ensure that the firmware provider 116—and the firmware update itself—are genuine and can be trusted by eUICC 108.As will be described in more detail below, the firmware loader 210 can also be configured to manage hash values ​​216 and certificates 218, further enabling the firmware loader 210 to perform the firmware update procedure securely.

[0027] Additionally and also in Fig. As shown in Figure 2, the baseband module 110 of the mobile device 102 can include a baseband OS 222 configured to manage the various hardware resources - in Fig. Figure 2 illustrates components 224 – e.g., a processor, memory, various radio transmitters / receivers, etc. – of the baseband module 110. According to one embodiment, the baseband OS 222 can be configured to implement various services that can be instantiated in accordance with one or more of the eSIMS 208 managed by the eUICC. For example, the baseband OS 222 can be configured to manage various connections between the mobile device 102 and the MNOs 114 corresponding to the different eSIMS 208 enabled by the mobile device 102.

[0028] Fig. Figure 3 illustrates a flowchart of a procedure 300 for updating the primary eUICC firmware 212, which is in Fig. Figure 2 illustrates one embodiment. Before step 302, the eUICC 108 operates in normal mode; for example, the eUICC 108 runs the primary eUICC firmware 212 and provides typical functionality to the mobile device 102. As shown, the method 300 begins at step 302, in which the firmware provider 116 indicates the availability of an updated primary firmware that can replace the primary eUICC firmware 212. According to one embodiment, the firmware provider 116 makes this notification available to the mobile device 102—in particular, to the eUICC firmware update checker 204—whereupon the eUICC firmware update checker 204 provides the notification from the eUICC 108 (e.g., by one or more commands). In an alternative embodiment, the eUICC firmware update checker 204 can be omitted and the firmware provider 116 can communicate directly with the firmware loader 210.

[0029] Conversely, at step 304, the eUICC 108 – in particular the firmware loader 210 which is executed within the eUICC – provides the eUICC firmware update checker 204 (i) with a unique identifier of the eUICC 108 (“EUICC ID” in Fig. 3) and (ii) a nonce value (“NONCE” in Fig. 3) Ready. The unique identifier can take any form that can be used to uniquely identify the eUICC 108 (e.g., an alphanumeric serial number) and allows the firmware provider 116 to at least partially identify that the mobile device 102 is genuine. For example, the firmware provider 116 can check the unique identifier against a database of known eUICC identifiers to determine whether the unique identifier is recognized. The nonce value can take any form that can be used to communicate a one-time value (e.g., a large integer) to secure the transmission of the updated primary firmware from the firmware provider 116 to the firmware loader 210.In particular, the nonce value can be used to help protect against replay attacks that could potentially be used by malicious parties to deliver corrupt updated primary firmware to the eUICC 108 without detection. To achieve the aforementioned benefits, and as will be described in more detail, the firmware provider 116 can attach digital signatures to the updated primary firmware, which can be verified by the firmware loader 120. These digital signatures are based on one or more of the unique identifier and the nonce. The digital signatures can be provided by various entities associated with the mobile device 102, such as a manufacturer or administrator of the mobile device 102, a manufacturer or administrator of the eUICC 108, and similar entities.In this way, the firmware loader 210 can verify, based on the digital signatures, that the updated primary firmware delivered by the firmware provider 116 is authentic and specific to the eUICC 108.

[0030] In step 306, the firmware provider 116 generates a primary firmware update package in accordance with the unique identifier and nonce value. According to one embodiment, and as illustrated here, the primary firmware update package may include various components that facilitate the secure delivery of the updated primary firmware. For example, the primary firmware update package may include digital credentials of an owner of the updated primary firmware (e.g., a manufacturer or governing body of eUICC 108, a provider of eUICC OS 206, etc.), digital credentials of a distributor (e.g., the firmware provider 116, a manufacturer of the mobile device 102, etc.) of the primary firmware update package, the updated primary firmware itself, and similar components.As previously described herein, the firmware loader 210 can manage various certificates 218 that establish different entities trusted by the eUICC 108, and the authenticity of the digital signatures included within the primary firmware update package can be verified by checking the digital signatures against one or more of the certificates 218. According to some embodiments, the primary firmware update package can be transmitted encrypted between the firmware provider 116 and the firmware loader 210 by means of one or more certificates 218.

[0031] In step 308, the firmware loader 210 receives the primary firmware update package and verifies the aforementioned components included in the primary firmware update package. Assuming there are no discrepancies, the procedure 300 continues to step 310, in which the firmware loader 210 persistently stores a hash value 216 of the updated primary firmware in the single non-volatile memory accessible to the firmware loader 210. In some embodiments, a Media Access Control (MAC) address associated with the eUICC 108 (or other components included in the mobile device 102) may replace or accompany the hash value 216.As will be described in more detail below, persistently storing the hash value 216 in non-volatile memory allows the eUICC 108 to undergo a cold reset, which would otherwise result in the hash value 216 being erased if stored in volatile memory (e.g., the eUICC 108's RAM). Also as will be described in more detail below, this persistent hash value 216 is used by the firmware loader 210 to verify that the updated primary firmware that is ultimately installed is indeed the same updated primary firmware contained in the primary firmware update package verified by the firmware loader 210 in step 308.

[0032] In step 312, the eUICC 108 undergoes a cold reset and enters a recovery mode, allowing the firmware loader 210 to perform the primary firmware update. In step 314, the firmware loader 210 replaces the primary eUICC firmware 212 with the updated primary firmware included in the primary firmware update package, thus rendering a new primary eUICC firmware 212 within the eUICC 108. Next, in step 316, the firmware loader 210 accesses the hash value 216, which was continuously stored in non-volatile memory during step 310, to determine if the new primary eUICC firmware 212 matches the hash value 216.

[0033] In the event that the new primary eUICC firmware 212 does not correspond to the hash value 216, eUICC 108 remains in recovery mode and the firmware loader 210 performs a recovery technique using the backup eUICC firmware 214, which is described in more detail below in conjunction with Fig. 4 will be described. Conversely, in the case where the new eUICC firmware 212 corresponds to the hash value 216, the eUICC 108 undergoes a cold reset and returns to a normal mode, which allows the eUICC 108 to run the new primary eUICC firmware 212 and provide typical functionality of the mobile device 102.

[0034] Accordingly, it Fig. 3 presents a technique for updating the primary eUICC firmware 212 in a safe manner. In some cases, and as previously indicated, situations may arise in which the primary eUICC firmware 212 can become corrupted and render the eUICC 108 inoperable. To remedy this deficiency, the embodiments presented herein include a technique that allows the firmware loader 210 to recover from the corruption event by loading the backup eUICC firmware 214. In particular, the backup eUICC firmware 214 provides a means to restore the eUICC 108 and restore a primary eUICC firmware 212, which is described in more detail below in conjunction with Fig. 4 will be described.

[0035] Fig. Figure 4 illustrates a flowchart of a procedure 400 for recovering from a primary eUICC firmware 212 corruption event according to one embodiment. As shown in Fig. As shown in Figure 4, procedure 400 begins at step 402, in which damage to the primary eUICC firmware 212 is detected. In response, eUICC 108 is cold reset at step 404 and enters recovery mode, which is described above in conjunction with... Fig. As described in section 3, in step 406, the eUICC 108—specifically, the firmware loader 210—receives the backup eUICC firmware 214 from the non-volatile memory accessible to the firmware loader 210. According to one embodiment, the backup eUICC firmware 214 is stored in a protected / additional area of ​​the non-volatile memory, and the location of the backup eUICC firmware 214 is known to the firmware loader 210. Furthermore, a hash value 216 corresponding to the backup eUICC firmware 214 is also stored in the non-volatile memory, and the location of the hash value 216 is known to the firmware loader 210. As will be described in more detail below, this allows the firmware loader 210 to verify a restored primary eUICC firmware 212 after the corrupted primary eUICC firmware 212 has been replaced by the backup eUICC firmware 214.

[0036] In step 408, the firmware loader 210 replaces the primary eUICC firmware 212 with the backup eUICC firmware 214 to produce a primary recovery eUICC firmware 212. In step 410, the firmware loader 210 verifies the primary recovery eUICC firmware 212 using the hash value 216, which is permanently stored in non-volatile memory. Subsequently, assuming the verification is successful, the eUICC 108 undergoes a cold reset and enters normal mode, which, in conjunction with Fig. 3 was described. Consequently, in step 414, the firmware loader 210 can experience the technique described in Fig. 3 was shown to retrieve and install a primary eUICC firmware 212 that is not corrupted.

[0037] Accordingly, it Fig. 4. This describes a technique that allows the Firmware Loader 210 to recover itself in the event that the primary eUICC Firmware 212 becomes corrupted. In some cases, it may be desirable to allow the backup eUICC Firmware 214 to be updated with a different version of the backup eUICC Firmware 214. Accordingly, the Firmware Loader 210 can also be configured to implement a technique for updating the backup eUICC Firmware 214, which is described in more detail below in conjunction with Fig. 5 is described.

[0038] Fig. Figure 5 illustrates a flowchart of Procedure 500 for updating the backup eUICC firmware 214, which is in Fig. Figure 2 illustrates one embodiment. Before step 502, the eUICC 108 operates in normal mode; that is, the eUICC 108 runs the primary eUICC firmware 212 and provides typical functionalities of the mobile device 102. It should be noted that updating the backup eUICC firmware 214 does not require the eUICC 108 to enter recovery mode, since the backup eUICC firmware 214 is not actually installed for active use within the eUICC 108. Instead, the existing Backup eUICC Firmware 214, which is stored in the non-volatile memory, is replaced by an updated Backup eUICC Firmware 214 provided by the firmware provider 116, and the existing hash value 216 corresponding to the existing Backup eUICC Firmware 214 is updated by an updated hash value 216 corresponding to the updated Backup eUICC Firmware 214.In this way and in accordance with the techniques described herein above in conjunction with . Fig. 4. The firmware loader 210 can properly install and verify the updated backup eUICC firmware 214 in the event that the primary eUICC firmware 212 is corrupted.

[0039] As shown, procedure 500 begins at step 502, where firmware provider 116 indicates that an updated backup firmware is available that can replace backup eUICC firmware 214. As previously described, firmware provider 116 can be configured to provide this notification to mobile device 102—specifically, to eUICC firmware update checker 204—whereupon eUICC firmware update checker 204 provides the notification of eUICC 108 (e.g., by one or more commands). In an alternative embodiment, eUICC firmware update checker 204 can be omitted, and firmware provider 116 can communicate directly with firmware loader 210.

[0040] Conversely, at step 504, the eUICC 108 – in particular the firmware loader 210, which is executed within the eUICC 108 – provides the eUICC firmware update checker 204 (i) with a unique identifier of the eUICC 108 (“eUICC ID” in Fig. 5) and (ii) a nonce value (“NONCE” in Fig. 5) ready. At step 506, the firmware provider 116 generates a backup firmware update package in accordance with the unique identifier and nonce value. According to one embodiment and as shown above, the backup firmware update package can contain the same components as the primary firmware update package, which was described above in conjunction with Fig. 3 described - e.g. digital credentials of an owner of the updated backup firmware, digital credentials of a distributor of the backup firmware update package, the updated backup firmware itself and similar - to promote secure delivery of the updated backup firmware.

[0041] At step 508, the firmware loader 210 receives the backup firmware update package and verifies the aforementioned components contained within it. Assuming no discrepancies, procedure 500 continues at step 510, where the firmware loader 210 persistently stores a hash value 216 of the updated backup firmware in non-volatile memory accessible to the firmware loader 210. At step 512, the firmware loader 210 persistently stores the backup firmware itself in non-volatile memory. The firmware loader 210 records the location of the persistent hash value 216—as well as the persistent backup firmware—so that the firmware loader 210 can perform the recovery procedure described above in conjunction with Fig. 4 described, in the event that damage to the primary eUICC firmware 212 occurs, can be carried out properly.

[0042] Finally, at step 514, the eUICC 108 continues to operate in normal mode, which involves the eUICC 108 running the primary eUICC firmware 212 and providing typical functionality of the mobile device 102. Accordingly, Fig. 5 presents a technique for updating the backup eUICC firmware 214 in a safe manner.

[0043] Fig. Figure 6 illustrates a procedure 600 for a high-level technique that implements various techniques associated with Fig. 3, Fig. 4 to Fig. The following are described in Section 5 to maintain a current and functional firmware within the eUICC 108 according to one embodiment. As shown, the method 600 begins at step 602, in which the eUICC 108 determines whether the primary eUICC firmware 212 is functional. If, at step 602, the eUICC 108 determines that the primary eUICC firmware 212 is functional, the method then repeats step 602 until a different state occurs. If, at step 602, the eUICC 108 determines that the primary eUICC firmware 212 is not functional, the method 600 continues at step 604.

[0044] In step 604, the eUICC 108 – specifically the firmware loader 210 – receives the backup eUICC firmware 214 in accordance with the techniques described above in conjunction with Fig. 4 were described. In step 606, the firmware loader 210 installs the backup eUICC firmware 214 in accordance with the techniques described above in conjunction with Fig. 4 were described. In step 608, the firmware loader 210 activates the backup eUICC firmware 214 in accordance with the techniques described above in conjunction with Fig. 4 described, whereupon the procedure steps 612 to 618 can be carried out by the firmware loader 210 in an attempt to restore the functional primary eUICC firmware 212 within eUICC 108.

[0045] Now, referring back to step 610, if the firmware loader 210 determines that an updated primary eUICC firmware 212 is available, then procedure 600 continues at step 612, in which the firmware loader 210 loads the updated primary eUICC firmware 212 in accordance with the techniques described above in conjunction with Fig. 3 described above. In step 614, the firmware loader 210 verifies the updated primary eUICC firmware 212 in accordance with the techniques described above in conjunction with Fig. 3. In step 616, the firmware loader 210 installs the updated primary eUICC firmware 212 in accordance with the techniques described above in conjunction with Fig. 3 were described. Finally, in step 618, the firmware loader 210 activates the updated primary eUICC firmware 212 in accordance with the techniques described above in conjunction with Fig. 3 were described.

[0046] Fig. Figure 7 illustrates a detailed view of a computer device 700 that can be used to implement various components described herein according to some embodiments. In particular, the detailed view illustrates various components that can be incorporated into the mobile device 102, which is described in Fig. As illustrated in 1, they can be included. Fig. As shown in Figure 7, the computing device 700 can include a processor 702, which is a microprocessor or controller for controlling the entire operation of the computing device 700. The computing device 700 can also include a user input device 708, which allows a user of the computing device 700 to interact with it. For example, the user input device 708 can take various forms, such as a button, a keypad, a dial, a touchscreen, an audio input interface, a visual / image capture input interface, input in the form of sensor data, etc. Furthermore, the computing device 700 can include a display 710 (a screen display) which can be controlled by the processor 702 to display information to the user. A data bus 716 can enable data transfer between at least one storage device 740, the processor 702, and a controller 713.The controller 713 can be used to interface with and control various pieces of equipment via an equipment control bus 714. The computing device 700 can also include a network / bus interface 711 that connects to a data link 712. In the case of a wireless connection, the network / bus interface 711 can include a wireless transceiver.

[0047] The computing device 700 may also include a storage device 740, which may comprise a single disk or a plurality of disks (e.g., hard disks) and includes a memory management module that manages one or more partitions within the storage device 740. In some embodiments, the storage device 740 may include flash memory, semiconductor (solid-state) memory, or the like. The computing device 700 may also include random access memory (RAM) 720 and read-only memory (ROM) 722. The ROM 722 may store programs, utilities, or processes to be executed in a non-volatile manner. The RAM 720 may provide volatile data storage and stores instructions relating to the operation of the computing device 700. The computing device 700 may further include a backup element 750, which includes the eUICC 108, which is described in Fig. 1 to Fig. 2 is illustrated and described herein.

[0048] The various aspects, embodiments, implementations, or features of the described embodiments can be used separately or in combination. Different aspects of the described embodiments can be implemented by software, hardware, or a combination of hardware and software. The described embodiments can also be designed as computer-readable code on a computer-readable medium. A computer-readable medium is any data storage device capable of storing data that can subsequently be read by a computer system. Examples of computer-readable media include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tapes, hard disks, solid-state drives, and optical data storage devices. The computer-readable medium can be distributed across networked computer systems, allowing the computer-readable code to be stored and executed in a distributed manner.

[0049] The preceding description uses specific technical terms for explanatory purposes to provide a thorough understanding of the described embodiments. However, it will be clear to those skilled in the art that specific details are not necessary to implement the described embodiments. Thus, the preceding descriptions of specific embodiments are presented for illustrative and descriptive purposes only. They are not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. It will be clear to those skilled in the art that many modifications and variations of the preceding teachings are possible.

Claims

[1] Method for updating the firmware of an embedded universal integrated circuit card (eUICC) included in a mobile device, the method comprising: at the eUICC: Receiving a notification from a firmware provider that an updated firmware for the eUICC is available; In response to the instruction, provide to the firmware provider (i) a unique identifier (ID) associated with the eUICC and (ii) a nonce value; following the provision and receipt from the firmware provider of a firmware update package, wherein the firmware update package includes (i) authentication information and (ii) the updated firmware; Following verification of the authentication information, persistent storage of a hash value corresponding to the updated firmware to a memory included in the mobile device; and installation of the updated firmware on the eUICC. [2] The method of claim 1, further comprising: Following the installation of the updated firmware, attempts are made to verify the updated firmware using the hash value that is continuously stored in memory. [3] The method of claim 2, further comprising: when the updated firmware is verified: Activating the updated firmware. [4] Method according to claim 2, further comprising: if the updated firmware is not verified: Obtain a backup firmware from the storage; and install the backup firmware on the eUICC. [5] The method of claim 4, further comprising: Following the installation of the backup firmware, the backup firmware attempts to verify the backup firmware using an existing hash value that is pre-stored in memory and based on the backup firmware. [6] The method of claim 5, further comprising if the backup firmware is verified: Enabling backup firmware, whereby the backup firmware allows subsequent restoration and installation of a different updated firmware. [7] Method according to claim 1, wherein the memory is a non-volatile memory and the non-volatile memory is local to the eUICC. [8] Method according to claim 1, wherein the authentication information includes a digital signature produced by the firmware provider and based on one or more of the unique ID and the nonce value. [9] Method according to claim 8, wherein the firmware provider produces the digital signature in accordance with a public key / private key pair, wherein the public key is pre-stored in the memory of the eUICC and the eUICC verifies the digital signature using the public key. [10] Mobile device including an eUICC configured to perform a firmware update, wherein the mobile device includes: the eUICC, wherein the eUICC is configured to perform steps including: receiving from a firmware provider a notification that updated backup firmware is available for the eUICC; In response to the instruction, provide to the firmware provider (i) a unique identifier (ID) associated with the eUICC, and (ii) a nonce value; Received from the firmware provider of a firmware update package, wherein the firmware update package includes (i) authentication information and (ii) the updated backup firmware; and The following steps are required to verify the authentication information: continuous storage on a memory included in the mobile device, (i) the updated backup firmware and (ii) a hash value based on the updated backup firmware. [11] Mobile device according to claim 10, wherein, following the continuous storage of the hash value to the memory, the eUICC proceeds to operate a primary firmware that is different from the updated backup firmware. [12] Mobile device according to claim 11, further comprising, following the continuous storage of the hash value to the memory and after detecting that the primary firmware is not functioning: Install the backup firmware on the eUICC; and following the installation of the backup firmware, attempt to verify the backup firmware based on the hash value. [13] Mobile device according to claim 12, further comprising: when the backup firmware is verified: Enabling the backup firmware, whereby the backup firmware allows a subsequent retrieval and installation of a different primary firmware. [14] Mobile device according to claim 10, wherein the authentication information includes a digital signature provided by the firmware provider and is based on one or more of the unique ID and the nonce value. [15] Mobile device according to claim 14, wherein the firmware provider produces the digital signature in accordance with a public key / private key pair and the eUICC stores the public key in the memory and verifies the digital signature using the public key.

Images