Method and system for preserving per-device diversified data when replacing firmware

Abstract

A method for updating the firmware of a device while preserving a previously established set of diversification data, including creating a common firmware (FW) image for a plurality of devices and loading the FW image to the devices; generating per-device diversified data and loading the data to the devices; and for each device, generating diversified data and grouping the diversified data into a Binary Large Object (BLOB).

Description

METHOD AND SYSTEM FOR PRESERVING PER-DEVICE DIVERSIFIED DATA WHEN REPLACING FIRMWAREFIELD OF USE

[0001] The present disclosure relates, generally, to integrated circuit chips, and, more particularly, to upgrading the firmware of embedded integrated circuit chips.BACKGROUND

[0002] An integrated circuit chip may be embedded in a device that is deployed, such as to consumers. Some integrated circuit chips may have various constraints. For instance, if they are designed for a specific purpose, it may not be necessary to provide excessive resources (storage, processing power, etc.), such as for reasons of cost, size, complexity of production, etc. Such a device may be deployed with firmware that directs the operation of the integrated circuit chip and / or device. Before and during operation of the device, the device may acquire a varied set of data, such as user data, application data, operation system data, etc. When it is eventually desirable to updating the firmware of the device (aka. FW image), it may be similarly desirable to preserve the previously established set of diversification data.

[0003] Updates sometimes go beyond simple firmware patches and encompass large functional (even disruptive) updates, for which existing user data currently stored in device memory might not be usable or even not relevant anymore. It might still be desirable to preserve all or part of the diversification data established at an earlier stage, typically during some production step of the device, that might remain stable across firmware updates, e.g., a unique device identifier, a unique device cryptographic key, etc. More than interesting, retaining only specific parts of existing data might in fact be exactly what is wanted in some situations (e.g., inventory re-use).

[0004] To achieve these scenarios, it is also interesting to define a method common to all firmware images, i.e., common to the deployment process itself.SUMMARY

[0005] An aspect of the disclosure is directed toward a method for updating the firmware of a device while preserving a previously established set of diversification data, comprising creating a common firmware (FW) image for a plurality of devices and loading the FW image to the devices; generating perdevice diversified data and loading the data to the devices; and for each device, generating diversified data and grouping the diversified data into a Binary Large Object (BLOB).

[0006] The advantages provided by the disclosure are allowing updating the FW image of a device with limited but still convenient capability in order to keep existing data. The set of data that can be preserved is the set of data diversified during production. Thus, the disclosed method and system is less costly, less complex to use and offers better performances than a complete FW upgrade solution. Additionally, the disclosure provides a way to reset the device to its factory state. Retaining only specific parts of existing data might in fact be exactly what is wanted in some situations (e.g., inventory re-use). The disclosure also has the effect of extending the lifetime of embedded products and hosting devices.

[0007] In an aspect of the disclosure, the common firmware image includes the device operating system (OS), common data, programs that are initially present on all said many devices, and a piece of executable code (D.PROG) that can be executed to diversify the common firmware image based on diversified data read from a BLOB present in device memory.

[0008] An aspect of the disclosure considers the steps of loading the common firmware image to a device memory; loading the BLOB to the device memory; launching the device operating system; and executing D.PROG to diversify the common FW image based on the BLOB present in the device memory.

[0009] In an aspect of the disclosure, the program deletes the BLOB.

[0010] In an aspect of the disclosure, the program saves the BLOB in a dedicated area in device memory called BLOB Backup Area (B.AREA) for later reuse.

[0011] An aspect of the disclosure considers loading the common FW image to device memory, launching the device OS, and executing the D.PROG to diversify the common FW image based on the BLOB present in the B.AREA.

[0012] An aspect of the disclosure considers loading diversified FW image to device memory, launching the device OS, and executing the D.PROG to further diversify the diversified FW image based on the BLOB present in the B.AREA and those included in the FW image.

[0013] An aspect of the disclosure considers loading a Reset FW image to device memory, launching the device OS, and executing the D.PROG to diversify the common FW image based on the BLOB present in the B.AREA, wherein the Reset FW image is a twin FW image similar to the initial common FW image which includes a D.PROG but does not include a BLOB.

[0014] An aspect of the disclosure is directed toward a system for updating the firmware of a device while preserving a previously established set of diversification data comprising an embedded device and a server, wherein the embedded device comprises a processor and memory that are configured to carry out the following steps: creating a common firmware (FW) image for a plurality of devices and loading the FW image to the devices; generating perdevice diversified data and loading the data to the devices; and for each device,generating diversified data and grouping the diversified data into a Binary Large Object (BLOB).

[0015] In an aspect of the disclosure, the common FW image includes the device operating system (OS), common data, programs that are initially present on all said many devices, and a piece of executable code (D.PROG) that can be executed to diversify the common firmware image based on diversified data read from a BLOB present in device memory.

[0016] An aspect of the disclosure considers the steps of loading the common FW image to a device memory; loading the BLOB to the device memory; launching the device operating system; and and executing D.PROG to diversify the common FW image based on the BLOB present in the device memory.

[0017] In an aspect of the disclosure, the program deletes the BLOB.

[0018] In an aspect of the disclosure, the program saves the BLOB in a dedicated area in device memory called BLOB Backup Area (B.AREA) for later reuse.

[0019] An aspect of the disclosure considers loading the common FW image to device memory, launching the device OS, and executing the D.PROG to diversify the common FW image based on the BLOB present in the B.AREA.

[0020] An aspect of the disclosure considers loading diversified FW image to device memory, launching the device OS, and executing the D.PROG to further diversify the diversified FW image based on the BLOB present in the B.AREA and those included in the FW image.

[0021] An aspect of the disclosure considers loading a Reset FW image to device memory, launching the device OS, and executing the D.PROG to diversify the common FW image based on the BLOB present in the B.AREA,wherein the Reset FW image is a twin FW image similar to the initial common FW image which includes a program but does not include a BLOB.DESCRIPTION OF DRAWINGS

[0022] For a better understanding of the various described embodiments, reference should be made to the Detailed Description below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures.

[0023] FIG. 1 is an exemplary illustration of a device according to the present disclosure;

[0024] FIG. 2 is an exemplary illustration of a device with an integrated circuit inlay according to the present disclosure;

[0025] FIG. 3 is an exemplary high-level block diagram of an architecture of the integrated circuit according to the present disclosure;

[0026] FIG. 4 is an exemplary high-level block diagram of a memory of the integrated circuit according to the present disclosure; and

[0027] FIG. 5 is an exemplary flowchart according to the present disclosure.DETAILED DESCRIPTION

[0028] Several aspects of the disclosure with reference to the appended drawings are now explained. Whenever the shapes, relative positions and other aspects of the parts described are not explicitly defined, the scope of the invention is not limited only to the parts shown, which are meant merely for the purpose of illustration. Also, while numerous details are set forth, it is understood that some aspects of the disclosure may be practiced without these details. In other instances, well-known circuits, structures, and techniques havenot been shown in detail so as not to obscure the understanding of this description.

[0029] The following description includes references to various methods executed by a processor of an integrated circuit chip. As is common in the field, there may be phrases herein that indicate these methods or method steps are performed by software instructions or software modules. As a person skilled in the art knows, such descriptions should be taken to mean that a processor, in fact, executes the methods, software instructions, and software modules.

[0030] It is further noted that, unless otherwise indicated, the steps of provided methods may be conducted in a different order than the order in which they are provided, where a person of skill in the art would find it to be appropriate. Additionally, unless otherwise noted that steps and / or procedures are mandatory, it may be possible to omit certain steps where they may be extraneous. Thus, while certain steps and / or procedures may be specifically indicated as "optional," this is not intended to imply that the remaining steps are mandatory unless otherwise noted.

[0031] FIG. 1 represents a drawing of an exemplary integrated circuit chip 101 , such as one that may be embedded in a device, such as, for example, an electronic device. The electronic device may be constituted by e.g., a smart phone, a vehicle, a virtual reality device, an augmented reality device, an loT type device, a set-top box, a tablet computer, a desktop computer, a laptop computer, a video player, an audio player, a media-player, a game console, a netbook, a Personal Digital Assistant (or PDA) and / or any other computer device. Such a set of devices is given as mere device examples that may be used without being exhaustive.

[0032] In another example, the device may be an "enabled" device, such as, for instance, a smart card 104 that may include the integrated circuit chip 101 as an inlay within the structure of the card. The technology may be used for any integrated circuit chip applications, such as, for instance, passports,security badges, credit cards, etc. The terminology “smart card” may be used herein to refer to such a system.

[0033] FIG. 2 shows that the device 201 may also contain an antenna 205 connected to the integrated circuit chip 203 by which the integrated circuit chip 203 communicates with a backend server, such as via a communication channel.

[0034] FIG. 3 is a high-level block diagram of an architecture of the integrated circuit chip 103 and the antenna 105. The integrated circuit chip 103 contains a processor 201 and a memory structure 203, which stores data and programs executable by the processor 201. The memory structure 203 may contain one or more of each of a random-access memory (RAM) 205, read-only memory (ROM) 207, and non-volatile programmable memory (NVM) 209. The memory devices 205, 207, and 209 are connected to the processor 201 via a bus 311.

[0035] The integrated circuit chip 203 further contains an input / output interface 313 for communicating to external devices, e.g., a terminal, via the antenna 205. For contactless communication, the input / output interface 313 may communicate with a terminal over the ISO 14443 protocol.

[0036] In alternative embodiments the integrated circuit chip 203 may include electrical contacts (not shown) for communicating over a contact interface to a backend server, for example, according to the ISO-7816 protocol or the Universal Serial Bus (USB) protocol.

[0037] An aspect of the present disclosure is directed toward updating the firmware (FW) of a device (i.e., FW image) while preserving a previously established set of diversification data. The present disclosure is particularly suitable for the deployment of many devices where a common FW image (e.g., static FW image, master FW image) is created and loaded to all said many devices; and per-device diversified data (e.g. unique device identifier, unique device cryptographic key...) are generated independently and loaded to said many devices.

[0038] Fig. 4 demonstrates an example of how a device memory 402 could be organized into different areas in accordance with the disclosure. In the figure, for the purpose of understanding, this example shows the presence of a Loader 404, i.e., a distinct piece of software in charge of loading other contents in the device memory 402. Other means of adding or replacing contents into a device memory are contemplated.

[0039] In the device memory 402, diversified data are generated and grouped into a Binary Large Object (BLOB), called here a Diversification BLOB (D.BLOB) 405, or several D.BLOB(s). The common FW image that is to be loaded onto, for example, the said many devices may include:

[0040] -- The device OS 409, as well as common data and programs 410 that shall be initially present on all said many devices.

[0041] - A piece of executable code or a script of commands, called a Diversification Program (D.PROG) 412, that can be executed to diversify the common FW image based on diversified data read from D. BLOBs 405 present in device memory.

[0042] FIG. 5 demonstrates the device production process, whichh includes steps as follows:- Load common FW image to device memory 402;- Load the one or several D. BLOBs 405 to device memory 402;- Launch the device OS 409 and execute the D.PROG 412 to diversify the common FW image based on the D. BLOBs 405 present in device memory 402.

[0043] This step is called the Diversification Step 502. During this step, the D.PROG 412 may either delete the D.BLOB(s) 405 or save all or some of them in a dedicated area in device memory, called BLOB Backup Area (B.AREA) 416, for later reuse.

[0044] According to the disclosure, following their initial production, the way to update the said many devices is to load the same or another FW image to the said many devices. Several scenarios are considered:1 ) Loading a common FW image to all said many devices; and2) Loading per-device diversified FW images to said many devices.

[0045] In this scenario, a per-device diversified FW image is generated which differs from a common FW image in the following ways: a. It may already contain data diversified for (specific to) a given device; and / or b. It may already contain D.BLOB(s) (i.e. there is no need to load them separately) which may be used by a D.PROG (also included in the FW image) to further diversify the FW image.

[0046] Scenario #1 505. Post-production loading of a common FW image:- Load common FW image to device memory (NOTE: overwrites any previous FW image in device memory)- Launch the device OS and execute the D.PROG to diversify the common FW image based on the D.BLOB(s) present in the B.AREA.

[0047] Scenario #2 508. Post-production loading of a diversified FW image:- Load diversified FW image to device memory (NOTE: overwrites any previous FW image in device memory)- Launch the device OS and execute the D.PROG to further diversify the diversified FW image based on the D.BLOB(s) present in the B.AREA and those possibly included in the FW image.

[0048] During this step, the D.PROG may either delete the D.BLOB(s) or save all or some of them in the B.AREA for later reuse. Accordingto the method, in both scenarios, part of the diversification data loaded to the device during production are preserved and re-injected in the FW image as they are read from one or several D.BLOB(s) found in the B.AREA. In scenario #2, additional diversified data may be injected in the FW image, as the FW image may be already partly diversified or may contain additional D.BLOB(s).

[0049] Using the method, another scenario may be considered where the device would be updated to return to a previous state, typically after the last device update, or possibly to its initial state (i.e. after production). In the following, we simply call this scenario the Device Factory Reset scenario, although it may generally apply to return a device to its state after the last update. In this scenario, a twin FW image similar to the initial common FW image (or similar to the one used for a previous or the last update) is prepared, which includes a D.PROG but does not include any D.BLOB. Let’s call it the Reset FW image (FWLRESET).

[0050] Scenario #3 512. Device Factory Reset:- Load the Reset FW image to device memory (NOTE: overwrites any previous FW image in device memory)- Launch the device OS and execute the D.PROG to diversify the common FW image based on the D.BLOB(s) present in the B.AREA.

[0051] Scenario #3 512 is similar to scenario #1 505 except that the chosen FW image is an equivalent of one from the past (e.g. from initial production or last update), prepared without D.BLOB, the D.PROG being instructed to re-use D.BLOB(s) from the B.AREA. Hence, scenario #3 512 reestablishes a past “clean” state of the device. This scenario may make sense in some contexts, e.g. to return a device to an initial state before its onboarding / enrollment in a network.

[0052] Aspects of the disclosure allow updating the FW image of a device with limited but still convenient capability to keep existing data. The set of data that can be preserved is the set of data diversified during production. In practice, during the update of the FW image, such data may be preserved orreplaced or augmented by supplementary data, as needed. The disclosure describes a solution that is less costly (in terms of implementation, validation, maintenance, deployment) than other complete FW upgrade solutions. It also provides a solution to reset the device to its factory state. The disclosure aims at protecting methods used for on-wafer personalization of secure elements.

[0053] The disclosure describes a way to update a device firmware while preserving a subset of initial diversified data, supported by specific production steps. It offers a trade-off between firmware update methods simply losing existing data and more complex and costly firmware update methods.

[0054] An aspect of the disclosure is directed toward a system for updating the firmware of a device while preserving a previously established set of diversification data. The system may include an embedded device and a server. The embedded device may be constituted by e.g., a smart phone, a vehicle, a virtual reality device, an augmented reality device, an loT type device, a set-top box, a tablet computer, a desktop computer, a laptop computer, a video player, an audio player, a media-player, a game console, a netbook, a Personal Digital Assistant (or PDA) and / or any other computer device. Such a set of devices is given as mere device examples that may be used without being exhaustive.

[0055] Instead of being constituted by a physical device, a software component, such as a library, or a hardware component included within or connected to the device carries out the functions that are described infra and that are performed by the system.

[0056] The embedded device includes one or several Central Processing Unit(s) (or CPU), (micro)processor(s) and / or (micro)controller(s) (not represented), as data processing means, one or several memories (not represented), as data storing means, and one or several Input / Output (or I / O) interfaces (not represented).

[0057] The (or each) processor processes data originating from and / or intended to any internal component and data originating from and / or intended to any external device through one or several I / O interfaces.

[0058] The memories may include one or several EEPROMs (acronym for “Electrically Erasable Programmable Read-Only Memory”), one or several ROMs (acronym for “Read Only Memory”), one or several Flash memories and / or any other memories of different types, like e.g., one or several RAMs (acronym for “Random Access Memory”).

[0059] A memory (and / or a memory of another device connected or coupled to the PC) stores preferably an Internet Protocol (or IP) address, as a IDentifier (or ID), and / or other data that allow(s) uniquely identifying the embedded device.

[0060] The PC I / O interface(s) may include e.g., an antenna (not represented), allowing to transmit data, through e.g., a wireless link, via one (communication) network(s), such as Intranet and / or Internet, to the server.

[0061] The embedded device is connected, through the link, be it wire or wireless, to the server.

[0062] The channel using the link may be secure or unsecure. The channel may be related to a HyperText Transfer Protocol (or HTTP) (registered trademark) type channel, an HTTP Secure (or HTTPS) type channel, a RESTful API communication or any other data communication channel.

[0063] Instead of being constituted by a physical server, it may be constituted by a software component, such as a library, or a hardware component included in (or connected to) the device carries out the functions that are described infra and that are performed by the server.

[0064] The server is remote and accessible through possibly one, two or more communication networks, such as an Intranet network and / or an Internet network, that allow to define or form a corresponding communication channel.

[0065] According to an alternative embodiment (not represented), the server or a software component is local. For example, the server isembedded within a device (not represented), such as a secure element that is connected or communicatively coupled to the embedded device.

[0066] The server may be accessed through an associatedApplication Provider Interface (or API) or a Service Provider Interface (or SPI).

[0067] The server includes one or several CPU(s),(micro)processor(s) and / or (micro)controller(s), as data processing means (not represented), one or several memories, as data storing means (not represented), and one or several I / O interfaces (not represented) that are internally together connected.

[0068] The (or each) server processor processes data originating from and / or intended to any internal component and data originating from and / or intended to any external device through one or several server I / O interfaces.

[0069] The server I / O interface(s) is(are) used for communicating with an external device(s), such as the system, so as to provide, through the system, an adapted response that replaces a response to a data access request.

[0070] The server memory(ies) store(s) preferably, besides an OS, one or several applications to be executed, so that the server provides one or several corresponding services. For instance, an application stored by the server and / or the embedded device is an application to carry out the method of the upgrade of the firmware.

[0071] While certain aspects have been described and shown in the accompanying drawings, it is to be understood that such are merely illustrative of and not restrictive on the broad invention, and that the invention is not limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those of ordinary skill in the art. The description is thus to be regarded as illustrative instead of limiting.

Claims

CLAIMSWhat is claimed is:1 . A method for updating the firmware of a device while preserving a previously established set of diversification data, comprising: creating a common firmware (FW) image for a plurality of devices and loading the FW image to the devices; generating per-device diversified data and loading the data to the devices; and for each device, generating diversified data and grouping the diversified data into a Binary Large Object (BLOB).

2. The method of claim 1 , further comprising that the common firmware image includes the device operating system (OS), common data, programs that are initially present on all said many devices, and a piece of executable code (D.PROG) that can be executed to diversify the common firmware image based on diversified data read from a BLOB present in device memory.

3. The method of claim 2, furthering comprising the steps of: loading the common firmware image to a device memory; loading the BLOB to the device memory; launching the device operating system; and executing D.PROG to diversify the common FW image based on the BLOB present in the device memory.

4. The method of claim 3, further comprising that the program deletes the BLOB.

5. The method of claim 3, further comprising that the program saves the BLOB in a dedicated area in device memory called BLOB Backup Area (B.AREA) for later reuse.

6. The method according to claim 5, further comprising loading the common FW image to device memory, launching the device OS, and executing the D.PROG to diversify the common FW image based on the BLOB present in the B.AREA.

7. The method according to claim 5, further comprising loading diversified FW image to device memory, launching the device OS, and executing the D.PROG to further diversify the diversified FW image based on the BLOB present in the B.AREA and those included in the FW image.

8. The method according to claim 5, further comprising loading a Reset FW image to device memory, launching the device OS, and executing the D.PROG to diversify the common FW image based on the BLOB present in the B.AREA, wherein the Reset FW image is a twin FW image similar to the initial common FW image which includes a D.PROG but does not include a BLOB.

9. A system for updating the firmware of a device while preserving a previously established set of diversification data comprising an embedded device and a server, wherein the embedded device comprises a processor and memory that are configured to carry out the following steps: creating a common firmware (FW) image for a plurality of devices and loading the FW image to the devices; generating per-device diversified data and loading the data to the devices; and for each device, generating diversified data and grouping the diversified data into a Binary Large Object (BLOB).

10. The system of claim 9, further comprising that the common FW image includes the device operating system (OS), common data, programs that are initially present on all said many devices, and a piece of executable code (D.PROG) that can be executed to diversify the common firmware image based on diversified data read from a BLOB present in device memory.11 . The system of claim 10, furthering comprising the steps of: loading the common FW image to a device memory;loading the BLOB to the device memory; launching the device operating system; and and executing D.PROG to diversify the common FW image based on the BLOB present in the device memory.

12. The system of claim 11 , further comprising that the program deletes the BLOB.

13. The system of claim 11 , further comprising that the program saves the BLOB in a dedicated area in device memory called BLOB Backup Area (B.AREA) for later reuse.

14. The system according to claim 13, further comprising loading the common FW image to device memory, launching the device OS, and executing the D.PROG to diversify the common FW image based on the BLOB present in the B.AREA.

15. The system according to claim 13, further comprising loading diversified FW image to device memory, launching the device OS, and executing the D.PROG to further diversify the diversified FW image based on the BLOB present in the B.AREA and those included in the FW image.

16. The system according to claim 13, further comprising loading a Reset FW image to device memory, launching the device OS, and executing the D.PROG to diversify the common FW image based on the BLOB present in the B.AREA, wherein the Reset FW image is a twin FW image similar to the initial common FW image which includes a program but does not include a BLOB.

Images