Method and system for upgrading the firmware of a device

Abstract

A method for upgrading a firmware of a device by an upgrade agent, wherein the firmware comprises a persistent data and an operating system binary code, including determining by the upgrade agent whether the device is running in a regular mode, a loader mode, or a data upgrade mode; if the device is in regular mode, requesting that the device switches to loader mode; if the device is in loader mode, loading a new version of an operating system binary code, and requesting the device to switch to data upgrade mode; and if the device is in data upgrade mode, triggering an upgrade of a preexisting persistent data, and requesting the device to switch to regular mode.

Description

METHOD AND SYSTEM FOR UPGRADING THE FIRMWARE OF A DEVICEFIELD OF USE

[0001] The present invention relates, generally, to integrated circuit chips, and, more particularly, to secure updating of the operating system 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.

[0003] A challenge is represented by the ability to upgrade the firmware (including operating system) of a resource-constrained device, with the following objectives:- replace the current version of the operating system (OS) by a new version;- preserve preexisting persistent data (including OS data, user applications running on top of the OS and user data) that were added and / or modified during usage of the device after initial production;- possibility to undo (i.e., roll back to the state prior the start of) the upgrade operation; and- allowing only a valid and consistent firmware to run on the device.SUBSTITUTE SHEET (RULE 26)SUMMARY

[0004] An aspect of the present disclosure considers a method for upgrading a firmware of a device by an upgrade agent, wherein the firmware comprises a persistent data and an operating system binary code, comprising determining by the upgrade agent whether the device is running in a regular mode, a loader mode, or a data upgrade mode; if the device is in regular mode, requesting that the device switches to loader mode; if the device is in loader mode, loading a new version of an operating system binary code, and requesting the device to switch to data upgrade mode; and if the device is in data upgrade mode, triggering an upgrade of a preexisting persistent data, and requesting the device to switch to regular mode.

[0005] The disclosure allows for larger modifications than classic patching methods, as the entire binary code of the device can be changed all at once. Patching methods would reduce the available memory space due to the accumulation of patches in memory. The disclosure simply replaces the current binary code with a new one. It also allows rolling back to previous firmware version. Thus, the proposed solution is efficient for resource-constrained device. It also fits the specific challenges of upgrading a Java Card runtime and Java Card applications.

[0006] An aspect of the present disclosure considers, while in Regular Mode, requesting the device to verify a cryptographic authorization provided by a device maker.

[0007] An aspect of the present disclosure considers, while in Loader Mode, requesting the device to defragment preexisting persistent data.

[0008] An aspect of the present disclosure considers, while in Loader Mode, requesting the device to generate an encrypted backup of the current firmware.

[0009] An aspect of the present disclosure considers, while in Loader Mode, requesting the device to move preexisting persistent dataSUBSTITUTE SHEET (RULE 26)internally so as to prepare for the loading of the new version of the OS binary code.

[0010] An aspect of the present disclosure considers, while in Data Upgrade mode, requesting the device to move persistent data as needed for regular operation.

[0011] An aspect of the present disclosure considers rejecting the request to switch to regular mode if the device detects that some of the previous steps did not complete normally or if, for any reason, the new OS binary code or the firmware image resulting from the upgrade operation is invalid.

[0012] An aspect of the present disclosure considers returning to Loader Mode.

[0013] An aspect of the present disclosure considers requesting to roll back to a memory state prior to the start of the upgrade operation, by reloading an encrypted memory backup.

[0014] An aspect of the present disclosure considers that the persistent data comprises an operating system data for regular operation, user applications, and user data created by the user applications.

[0015] An aspect of the present disclosure considers a method for upgrading a firmware of a device by an upgrade agent, wherein the device comprises a first non-volatile memory area and a second non-volatile memory area, wherein the firmware comprises a persistent data and an operating system binary code, comprising determining by the upgrade agent whether the device is running in a regular mode, a loader mode, or a data upgrade mode; if the device is in regular mode, requesting that the device switches to loader mode, deactivating the first non-volatile memory area and activating the second nonvolatile memory area; if the device is in loader mode, loading a new version of an operating system binary code to the second non-volatile memory area, and requesting the device to switch to data upgrade mode; and a. if the device is in data upgrade mode, reading the preexisting persistent data in the first non-volatile memory area, upgrading the preexisting persistent data using the operating system binarySUBSTITUTE SHEET (RULE 26)code loaded in the second non-volatile memory area, writing the modified data to the second non-volatile memory area, and requesting the device to switch to regular mode.

[0016] An aspect of the present disclosure considers rejecting the request to switch to regular mode if the device detects that some of the previous steps did not complete normally or if, for any reason, the new OS binary code or the firmware image resulting from the upgrade operation is invalid.

[0017] An aspect of the present disclosure considers returning to Loader Mode.

[0018] An aspect of the present disclosure considers requesting aborting the upgrade operation, reactivating the first non-volatile memory area which contains the previous version of the operating system and persistent data, and waiting for a new firmware image to be loaded into the second non-volatile memory area.

[0019] An aspect of the present disclosure considers that requests communicated by the upgrade agent to the device may be encrypted and protected in integrity and origin by an administrator entity, and verified and decrypted by the device, which holds suitable cryptographic credentials to do so.

[0020] An aspect of the present disclosure considers that the persistent data comprises an operating system data for regular operation, user applications, and user data created by the user applications.

[0021] An aspect of the present disclosure considers an embedded device and a server, wherein the embedded device comprises a processor configured to carry out the following steps: determine by the upgrade agent whether the device is running in a regular mode, a loader mode, or a data upgrade mode; if the device is in regular mode, request that the device switches to loader mode; if the device is in loader mode, load a new version of an operating system binary code, and requesting theSUBSTITUTE SHEET (RULE 26)device to switch to data upgrade mode; and if the device is in data upgrade mode, trigger an upgrade of a preexisting persistent data, and requesting the device to switch to regular mode.

[0022] An aspect of the present disclosure considers that the device further comprises a first non-volatile memory area and a second non-volatile memory area.DESCRIPTION OF THE DRAWINGS

[0023] 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.

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

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

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

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

[0028] FIGs. 5A-B are exemplary flow diagrams illustrating a process of present disclosure; and

[0029] FIGs. 6A-D are exemplary flow diagrams illustrating another aspect of a process of present disclosure.SUBSTITUTE SHEET (RULE 26)DETAILED DESCRIPTION

[0030] 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 have not been shown in detail so as not to obscure the understanding of this description.

[0031] 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.

[0032] 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 indicated as "optional," this does not imply that the remaining steps are mandatory unless otherwise noted.

[0033] 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,SUBSTITUTE SHEET (RULE 26)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.

[0034] 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.

[0035] 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.

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

[0037] 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.SUBSTITUTE SHEET (RULE 26)

[0038] 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.

[0039] FIG. 4 is a block diagram illustrating data and programs stored in a memory 403 that corresponds to the memory 303 of FIG. 3. In an aspect, the data and programs illustrated as stored in the memory 403 are stored in an NVM 409 that corresponds to the NVM 309 of FIG. 3. However, other memory organizations are possible.

[0040] The memory 403 contains programs 401 and persistent data 451. The programs 401 are computer program instructions that cause the processor 301 to perform certain actions. The programs 401 include an operating system 405 and applications programs 407.

[0041] The operating system 405, in turn, contains a variety of operating system functions 409 and a loader 411. The operating system functions 409 may include, for example, a virtual machine for executing the application programs 407 and memory management functions.

[0042] The loader 411, which is described in greater detail below, performs functions related to receiving a firmware upgrade and managing the processes related to implementing the upgrade.

[0043] The persistent data 451 may include user data 453, system data 455, and user applications 457. The user data 453 may be data created by user applications 457. The preexisting persistent data 451 (including operating system (OS) data, user applications running on top of the OS and user data) may have been added and / or modified during usage of the device after initial production.

[0044] In an aspect of the disclosure, firmware may be installed in the device, i.e. a firmware image. The firmware may be pre-installed in theSUBSTITUTE SHEET (RULE 26)device, that is to say, the firmware may already be existing on the device. The firmware may be composed of at least the following parts:

[0045] 1. operating system binary code, including: a. OS binary code for regular operation, and b. OS binary code for the upgrade of preexisting persistent data, which is to be used during an upgrade operation and intended to modify preexisting persistent data as required for the correct operation of part l.a of the OS binary code (after completion of the upgrade operation); and

[0046] 2. persistent data, including: a. operating system data for regular operation, b. user applications (i.e. executable code loaded to the device, not part of the operating system), and c. user data (i.e. data created by user applications).

[0047] In general, this part of the OS binary code (l.b) may be specific to a given upgrade operation as it modifies preexisting persistent data as necessary to migrate from a first OS version to second OS version. It may be empty or trivial for an initial deployment or if a particular upgrade operation does not actually require upgrading preexisting persistent data.

[0048] The device may run in the following modes:- a "Regular Mode" where the device runs part l.a of the OS binary code which allows the device to provide its regular intended functionality,-a "Data Upgrade Mode" where the device runs part l.b of the OS binary code which allows upgrading preexisting persistent data as required for the correct operation of part l.a of the operating system (after completion of the upgrade operation), andSUBSTITUTE SHEET (RULE 26)- a "Loader Mode" where the device runs a software component, called "Loader", distinct and isolated from the firmware image, and used to load the new version of the OS binary code and perform various upgrade specific operations.

[0049] According to the disclosure, the upgrade of the device may be conducted by a software agent, called upgrade agent, communicating with the device when the device is running in Regular Mode, Data Upgrade Mode or Loader Mode. FIGs. 5A and 5B demonstrate the steps to upgrade the firmware image, as triggered by the upgrade agent and with the device initially running in Regular Mode, may be as follows, starting with FIG. 5A:

[0050] 1. With device in Regular Mode 503: a. Optionally, request the device to verify a cryptographic authorization provided by the device maker (OEM) to allow the upgrade operation, as in 506. The device contains the necessary cryptographic credentials to perform such a verification; b. Optionally, request the device to defragment preexisting persistent data. This step may serve to accelerate the processing of next steps (generating and possibly retrieving a memory backup); c. Optionally, request the device to generate an encrypted backup of the current firmware image. A new secret cryptographic key, called the backup key, is generated, and stored by the device for that purpose. The encrypted memory backup may be retrieved by the upgrade agent and stored outside the device; d. Optionally, request the device to move preexisting persistent data internally so as to prepare for the loading of the new version of the OS binary code. The upgrade agent may provide the device with the expected size of the new OS binary code and the device may abort the procedure if the required memory space cannot be made available; andSUBSTITUTE SHEET (RULE 26)e. Request switching to Loader Mode, as in 509.

[0051] 2. With device in Loader Mode 511: a. Load the new version of the OS binary code (including parts l.a and l.b), as in 515. This operation may overwrite the OS binary code currently present in the device but shall not overwrite preexisting persistent data; and b. Request switching to Data Upgrade Mode, as in 519.

[0052] 3. Moving to FIG. 5B, with device in Data Upgrade Mode522: a. Trigger the upgrade of preexisting persistent data using part l.b of the OS binary code, as in 526; b. Optionally, request removing part l.b of OS binary code (which may no longer be needed); c. Request the device to move persistent data as needed for regular operation (i.e. correct operation of part l.a of the OS binary code). This step may be required (as opposed to optional) if step l.d was performed and thus may in turn require step 3. b to be performed; and d. Request switching to Regular Mode, as in 529. The device shall reject this request if it detects that some of the previous steps did not complete normally or if, for any reason, the new OS binary code or the firmware image resulting from the upgrade operation is invalid, as in 535.

[0053] 4. If an error occurs after the start of the upgrade operation, the device would be or would return to the Loader Mode 511 and: a. If an encrypted memory backup was generated, the upgrade agent may request to roll back to the memory state prior to the start of the upgrade operation, by reloading the encrypted memory backup (such as that may be stored outside the device); andSUBSTITUTE SHEET (RULE 26)b. If no encrypted memory backup was generated, the upgrade agent may request aborting the upgrade operation. Depending on when in the process the abortion is requested, the current firmware image may be deemed invalid by the device. In this case, the device would wait for a brand-new firmware image to be loaded.

[0054] In case of interruption after the start of the upgrade operation, depending on when the interruption occurred, the upgrade agent and device may be capable of resuming the upgrade operation. For example, it may be possible to resume the upgrade operation by resuming steps such as, for example, l.b, l.c, 2.a and / or 3.b. If the operation cannot be resumed, steps 4. a or 4.b may be triggered. The above steps may be initiated separately by the upgrade agent, or some of them may be combined and triggered altogether as the result of a single request from the upgrade agent (or equivalently, some steps might be triggered automatically by the device).

[0055] In an aspect of the disclosure demonstrated by FIGs. 6A-D, the device may contain two distinct non-volatile memory areas, also called partitions, herein denominiated as a first non-volatile memory area A 603 and second non-volatile memory area B 606, where distinct firmware images may be loaded. Said partitions may be implemented and accessed by the device as logical containers hosted by the same physical memory area or distinct physical memory areas. At any time, only one of partition A 603 or B 606 is considered active by the device and its firmware image is the one running when the device is in Regular Mode. In this case, there is no need in the upgrade operation for certain steps referenced previously, such as l.b, l.c, l.d and 3.c. Instead, considering the currently active partition would be partition A 6-3, the steps to upgrade the firmware image, as triggered by the upgrade agent and with the device initially running in Regular Mode, may be as follows:

[0056] 1. At FIG. 6A, with device in Regular Mode 608:SUBSTITUTE SHEET (RULE 26)a. Optionally, request the device to verify a cryptographic authorization provided by the device maker (OEM) to allow the upgrade operation, as in 611. The device contains the necessary cryptographic credentials to perform such a verification; and b. Request switching to Loader Mode, as in 614, deactivating partition A 603 and activating partition B 606.

[0057] 2. At FIG. 6B, with device in Loader Mode 617: a. Load the new version of the OS binary code (including parts l.a and l.b) on partition B 606, as in 620; and b. Request switching to Data Upgrade Mode, as in 623.

[0058] 3. At FIG. 6C, with device in Data Upgrade Mode 625: a. Trigger the upgrade of preexisting persistent data using part l.b of the OS binary code loaded in partition B 606, as in 627. This code reads preexisting persistent data in partition A 603, upgrade them and write the modified data to partition B 606; b. Optionally, request removing part l.b of OS binary code (which is not needed anymore); and c. Request switching to Regular Mode, as in 631. While in Regular mode, as in 635 of FIG. 6D, the device shall reject this request if it detects that some of the previous steps did not complete normally or, for any reason, the new OS binary code or the firmware image in partition B 606 is invalid, as in 639.4) If an error occurs after the start of the upgrade operation, the device would be or would return to the Loader Mode 617 and: a. The upgrade agent may request reactivating partition A 603, switching to Regular Mode and doing so, rolling back to the previous firmware image; andSUBSTITUTE SHEET (RULE 26)b. The upgrade agent may request aborting the upgrade operation, without rolling back to the previous firmware image. In this case, partition B remains active, and the device would wait for a brand new firmware image to be loaded in partition B 606.

[0059] In case of interruption after the start of the upgrade operation, depending on when the interruption occurred, the upgrade agent and device might be capable of resuming the upgrade operation. For example, it may be possible to resume the upgrade operation by resuming steps such as 2.a, 3. a or 3.b (non-exhaustive list).

[0060] In particular, according to this aspect of the disclosure, the upgrade operation can always be resumed from step 2.a. If the operation cannot be resumed, steps 4. a or 4.b may be triggered. This aspect of the disclosure of course requires significant additional non-volatile memory space from the device (i.e., about twice as much) but performs the upgrade operation significantly faster. In particular, in case of error or interruption, rolling back to the previous firmware image can be done almost instantaneously. This aspect of the disclosure does not require the upgrade agent to be aware of which partition A 603 or B 606 is currently active and, in above descriptions, partition names are given for illustration purpose only. Only the device needs to know which partition is currently active and the state of contents within each partition.

[0061] While it is apparent that the new OS binary code shall be encrypted and protected in integrity and origin and conversely, authenticated, verified and decrypted by the device, such aspects are not specifically addressed in this disclosure. However, it is mentioned previously (e.g. step 3.d) that the device may detect that the new OS binary code is not valid, which includes detecting that it cannot be interpreted or that its integrity or origin cannot be verified. The device would hold suitable cryptographic credentials to perform such verifications and decryption.SUBSTITUTE SHEET (RULE 26)

[0062] In another aspect of the disclosure, requests (or commands) communicated by the upgrade agent to the device may be encrypted and protected in integrity and origin by an administrator entity, and verified and decrypted by the device, which holds suitable cryptographic credentials to do so. In this case, the role of the upgrade agent is essentially to obtain such requests from the administrator and relay such requests to the device. Notice that this aspect of the disclosure differs from the cryptographic protection of the new OS binary code that is mentioned earlier. The key aspect here is that requests may be provided and secured by an administrator entity, whereas the cryptographic protection of the new OS binary code may be computed independently, such as by another entity and / or a third-party. In this scenario, the upgrade agent may still coordinate some interactions or may perform necessary actions not directly instructed by the administrator. For example, the upgrade agent may retrieve and store an encrypted memory backup (step l.c earlier described), may trigger a rollback in case an error is reported by the device during the upgrade operation (step 4. a earlier described), or may decide to abort the upgrade operation (based on some policy).

[0063] Aspects of the disclosure provide the ability to upgrade the firmware of a device without losing preexisting data, meaning the device firmware can be upgraded anytime, during production or in the field after issuance, with no service interruption and no need to reconfigure user specific data. The upgrade method described by the disclosure allows for larger modifications than classic patching methods, as the entire binary code of the device can be changed all at once. It also allows rolling back to previous firmware version. Classic patching methods would rather be used to modify small portions of the binary code, in general with limitations, and sometimes without any possibility to perform a roll back. The disclosure also allows discarding part of the binary code that is used to convert preexisting data, upon completion of the upgrade. With additional memory space, a variant of the invention can perform the upgrade in a very efficient way. The upgrade method described by the disclosure is especially suitable for resource-constrainedSUBSTITUTE SHEET (RULE 26)devices. The Data Upgrade Mode and related steps of the method described by the disclosure makes it especially suitable for the upgrade of a firmware implementing a Java Card runtime where Java Card applications may already be installed, and user data may already be present. Upgrading such kind of firmware introduces specific challenges due to the specific details of the Java Card technology.

[0064] In summary, aspects of the disclosure include:- An encrypted backup of the firmware is generated, which allows to roll back the firmware to its previous state in case of error during the process. Alternatively, or additionally, two non-volatile memory partitions (A and B) are used to save the need for such a backup and implement instantaneous roll back by simply switching active partitions. Without such mechanisms, upgrading the device would be an unsafe irreversible process, highly subject to failures (e.g. power loss, unexpected errors, etc.), with no means to return to a stable state.- Specific steps of the procedure (i.e. defragmenting and moving preexisting data) allow to free suitable memory space for the loading of the new OS binary code. Without such steps, loading the new OS binary code may not be possible.- The procedure includes a specific Data Upgrade phase where suitable and possibly large modifications of preexisting data can be performed as needed. This aspect of the method allows to cope with the widest range of upgrade situations and needs. Such modifications are also performed by a dedicated part of the new OS binary code, which may also be removed after the upgrade. Without such a mechanism, useless / dead OS binary code would remain on the device, leaving less memory for user applications and data.- The upgrade operation may require a cryptographic authorization from the device maker (OEM). The set of messages exchanged with the device to perform the upgrade may also be cryptographically protected independently bySUBSTITUTE SHEET (RULE 26)an administrator entity. The definition of such roles guarantees that the device and the firmware can be owned and managed by distinct entities.

[0065] An aspect of the disclosure is directed toward a system for upgrading the firmware of a device. The system may include an embedded device and a server.

[0066] 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 previously and that are performed by the system.

[0067] 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).

[0068] 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 1 / O interfaces.

[0069] 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").

[0070] The PC 1 / 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.

[0071] The embedded device is connected, through the link, be it wire or wireless, to the server.SUBSTITUTE SHEET (RULE 26)

[0072] 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.

[0073] 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.

[0074] 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.

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

[0076] The server is preferably accessed through an associated Application Provider Interface (or API) or a Service Provider Interface (or SPI).

[0077] 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.

[0078] 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.SUBSTITUTE SHEET (RULE 26)

[0079] The server 1 / 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.

[0080] 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.

[0081] 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.SUBSTITUTE SHEET (RULE 26)

Claims

CLAIMSWhat is claimed is:

1. A method for upgrading a firmware of a device by an upgrade agent, wherein the firmware comprises a persistent data and an operating system binary code, comprising: determining by the upgrade agent whether the device is running in a regular mode, a loader mode, or a data upgrade mode; if the device is in regular mode, requesting that the device switches to loader mode; if the device is in loader mode, loading a new version of an operating system binary code, and requesting the device to switch to data upgrade mode; and if the device is in data upgrade mode, triggering an upgrade of a preexisting persistent data, and requesting the device to switch to regular mode.

2. The method for upgrading the firmware of a device of claim 1, further comprising, while in Regular Mode, requesting the device to verify a cryptographic authorization provided by a device maker.

3. The method for upgrading the firmware of a device of claim 1, further comprising, while in Loader Mode, requesting the device to defragment preexisting persistent data.

4. The method for upgrading the firmware of a device of claim 1, further comprising, while in Loader Mode, requesting the device to generate an encrypted backup of the current firmware.

5. The method for upgrading the firmware of a device of claim 1, further comprising, while in Loader Mode, requesting the device to move preexistingpersistent data internally so as to prepare for the loading of the new version of the OS binary code.

6. The method for upgrading the firmware of a device of claim 1, further comprising, while in Data Upgrade mode, requesting the device to move persistent data as needed for regular operation.

7. The method for upgrading the firmware of a device of claim 1, further comprising rejecting the request to switch to regular mode if the device detects that some of the previous steps did not complete normally or if, for any reason, the new OS binary code or the firmware image resulting from the upgrade operation is invalid.

8. The method for upgrading the firmware of a device of claim 6, further comprising returning to Loader Mode.

9. The method for upgrading the firmware of a device of claim 6, further comprising requesting to roll back to a memory state prior to the start of the upgrade operation, by reloading an encrypted memory backup.

10. The method for upgrading the firmware of a device of claim 1, wherein the persistent data comprises an operating system data for regular operation, user applications, and user data created by the user applications.

11. A method for upgrading a firmware of a device by an upgrade agent, wherein the device comprises a first non-volatile memory area and a second nonvolatile memory area, wherein the firmware comprises a persistent data and an operating system binary code, comprising: determining by the upgrade agent whether the device is running in a regular mode, a loader mode, or a data upgrade mode; if the device is in regular mode, requesting that the device switches to loader mode, deactivating the first non-volatile memory area and activating the second non-volatile memory area;if the device is in loader mode, loading a new version of an operating system binary code to the second non-volatile memory area, and requesting the device to switch to data upgrade mode; and if the device is in data upgrade mode, reading the preexisting persistent data in the first non-volatile memory area, upgrading the preexisting persistent data using the operating system binary code loaded in the second non-volatile memory area, writing the modified data to the second non-volatile memory area, and requesting the device to switch to regular mode.

12. The method for upgrading the firmware of a device of claim 10, further comprising rejecting the request to switch to regular mode if the device detects that some of the previous steps did not complete normally or if, for any reason, the new OS binary code or the firmware image resulting from the upgrade operation is invalid.

13. The method for upgrading the firmware of a device of claim 11, further comprising returning to Loader Mode.

14. The method for upgrading the firmware of a device of claim 12, further comprising requesting aborting the upgrade operation, reactivating the first non-volatile memory area which contains the previous version of the operating system and persistent data, and waiting for a new firmware image to be loaded into the second non-volatile memory area.

15. The method for upgrading the firmware of a device of claim 13, wherein requests communicated by the upgrade agent to the device are encrypted and protected in integrity and origin by an administrator entity, and verified and decrypted by the device, which holds suitable cryptographic credentials to do so.

16. The method for upgrading the firmware of a device of claim 10, wherein the persistent data comprises an operating system data for regular operation, user applications, and user data created by the user applications.

17. A system for upgrading the firmware of a device, comprising an embedded device and a server, wherein the embedded device comprises a processor configured to carry out the following steps: determine by the upgrade agent whether the device is running in a regular mode, a loader mode, or a data upgrade mode; if the device is in regular mode, request that the device switches to loader mode; if the device is in loader mode, load a new version of an operating system binary code, and requesting the device to switch to data upgrade mode; and if the device is in data upgrade mode, trigger an upgrade of a preexisting persistent data, and requesting the device to switch to regular mode.

18. The system according to claim 16, wherein the device further comprises a first non-volatile memory area and a second non-volatile memory area.

Images