Method for keeping track of upgrade safety, electronic device with upgradable firmware, server and data carrier

The present invention relates to a method for keeping track of upgrade safety of firmware in electronic devices comprising a memory and a processor. Furthermore, the present invention relates to an electronic device with upgradeable firmware, a server for providing firmware update software and a data carrier comprising firmware update software.

The complexity of firmware in electronic devices increases constantly. Therefore, it is increasingly desirable that possible errors in the firmware can be corrected. Such a correction is generally performed by means of firmware upgrades.

Besides firmware upgrades devised by the manufacturer of an electronic device, it is also possible that open source firmware is used in hardware devices. An advantage thereof is that bug-fixes may be available faster than a manufacturer's solution to a problem. A disadvantage of open source firmware is that malicious instructions may be present.

A known way of making sure that trustworthy firmware is installed, is provided by means of a signature verification based on a signature appended to the firmware. A practical implementation thereof is that the hardware of the electronics device checks the signature. Such a check will however prevent a potentially good but unsigned firmware update from being installed. A manufacturer of an electronic device may however want to allow for uncontrolled firmware updates at the risk of the owner of the device without being liable for any damages to the device and/or subsequent damages by an operational error of the device. For example in the car industry, the safety and/or other good operation of parts of a car, such as an engine or breaks, are increasingly dependent on embedded software such as firmware. Unauthenticated tampering with such software, which is e.g. performed in so called tuning shops, may affect safety precautions or good operations safeguarded by the manufacturer. It is therefore highly valuable to be able to assess the origin of firmware.

Known from the WO 2004/031949 is a method for broadcasting of software applications that need to be updated, including a communication interface for receiving data from a broadcast communication system which stores software components executable by a CPU. In this method, also configuration information is stored for identifying the software components to be broadcasted. This method provides a solution to the problem that bugs in executable software applications are present. Based on this system the software can be updated based on software sent via the broadcasting system.

When updating firmware however, the problem arises who is responsible for errors in the update software. In case the software is made by the manufacturer of the device, this answer is relatively straightforward. In case the software is coming from a third party, the answer may not be straightforward and mired with legal issues.

In order to provide a solution to this problem, the present invention provides a method for keeping track of upgrade safety parameters of firmware in electronic devices comprising a memory and a processor, the method comprising steps for:

- accessing firmware update software by means of a transportable data carrier or via a network for performing the update,

- performing an update operation of the firmware with the accessed firmware update software, and

- setting an indicator for registering parameters regarding the update, wherein the indicator is tamper proof.

An advantage of such a method according to the present invention is that data pertaining to performed updates can be retrieved by reading out the indicator data.

The tamper proof indicator may be embodied in several ways, including embodiments comprising fusible digits or flags, embodiments requiring encryption or authentication by means of a signature for writing or changing data pertaining to the indicator, embodiments in which only ROM based software is allowed access to a memory space in which data pertaining to the indicator is stored, and combinations thereof.

Verification of a trust level of a firmware version is preferably performed by means of verification using at least a public key comprised by the device, e.g. in tamper- proof ROM memory. This way, use of another key and therefore the possibility of using unauthenticated firmware is prevented.

In a simple embodiment, such an indicator may contain one digit of information by means of which it is possible to record one instance of unsafe firmware software. Depending on design parameters, a manufacturer may for example allow for such a digit to be overwritten when later on a safe firmware version is installed. In other cases, the manufacturer may provide a system in which the one indicator pertaining to an unsafe firmware update is permanent after one firmware update with firmware software of unknown origin.

In another embodiment, it is possible that an array of indicator digits is available for recording a number of subsequent update states. This may be embodied by means of a fixed window or by means of a moving window in which a fixed number of the most recent updates is recorded. In these embodiments, it is possible to devise the recording hardware of the indicator data as write-once memory or memory that is only accessible from non-changeable updater programmes stored in ROM memory of the device. Because the program is stored in ROM it is impossible to be changed for allowing unauthenticated indicator changes.

In further embodiments, it is possible to provide for a data recording space for recording data pertaining to one or more firmware updates. It may be desirable to store a hash of each firmware update. In such an embodiment, it is also possible to provide a moving window of the latest firmware updates. Next to the data pertaining to one or more firmware updates, a separate indicator with the above purposes may be associated thereto.

Preferably, a method according to the present invention comprises steps for verifying a trust level, such as a signature authentication of the firmware update. An advantage thereof is that is that it is specifically known what the origin of a firmware update is, or at least it may be determined that an update was not authorised by a trusted party.

By further preference, the method comprises steps for using the indicator as a boot flag or an install flag. Use as an install flag provides the manufacturer the option to register an unauthenticated install as described in the above.

Preferably, the indicator data and data recording space are only writable during the update process, and/or the indicator data and data recording space are of a write once type. Alternatively, it is possible to set a boot flag when the device is booted by means of unauthenticated firmware.

In a further preferred embodiment, a switching step is comprised for providing a selection option to a person upgrading the device for choosing whether to allow unauthenticated firmware. In such a case, a message can be shown to the user of the device in

which a choice is offered either to install an available unauthenticated or untrusted firmware version or proceed without an upgrade. Possibly, alternative versions that are authorised can be offered for download in such a switching step. Also, a user can be presented with consequences regarding warranty for the product or a liability limitation of the manufacturer of the device.

A switching step can be comprised by the invention for providing a selection option to a person for choosing whether to allow booting the device with unauthenticated firmware. The device prevents booting of the device with unauthenticated firmware unless a user actively chooses to override the prevention, using the boot switch. Preferably, according to the present invention, in case the user overrides preventing booting the device with the unauthenticated software, also the indicator or flag is set to register this occurrence.

A user can therefore actively decide whether he wishes to use unauthenticated firmware or not. Such options effectively safeguard against unknowingly installing unsafe firmware by a user.

An identification of firmware update software can be made based on a hash thereof, which hash has a further advantage that it can be stored using a limited amount of storage space. Such storage space of a hash can effectively function as a indicator or such storage space can be linked to data representing an indicator. Using such a hash, it is possible to identify firmware update versions.

A further aspect of the present invention provides a method for keeping track of upgrade safety of firmware in electronic devices comprising steps for providing a firmware update from a server on a network. An advantage thereof is that a network device will always be able to connect to a network location in which firmware updates are stored, e.g. by the manufacturer of the device or trusted open source party.

A further aspect of the present invention provides an electronic device with upgradeable firmware, where the device comprises:

- a memory and a processor,

- a network connection or a data carrier interface,

- a firmware updater for updating software that is receivable via a transportable data carrier or a network,

- indicator data storage means for storage of indicator data for registering parameters regarding an update, wherein the indicator data storage means are tamper proof. Advantages of such an electronic device are indicated in the above in connection with a description of the method.

As was described in the above, the flags or indicator data are preferably protected against tampering. Preferably this is achieved by storing the flags in tamper-proof or write-once memory. However, tamper-proof memory is relatively costly and/or requires additional efforts being built into the device in a suitable manner. Alternatively, the flag data can be stored in flash memory, e.g. by encrypting the data and e.g. signing the data by means of a signature of the device itself.

Preferably, a protection against replay attacks is provided. An embodiment for this is one in which the device has a secure counter; each time when flag data are stored, the secure counter is increased, and the updated counter value is included in signed indicator data. When the device accesses flag data, it checks its own signature and then checks if the counter stored in flash corresponds to the counter in secure memory.

A further aspect of the present invention provides a server for providing firmware update software to a device according to claim 13 for updating with a method according to one or more of the claims 1-12, comprising a memory and a processor and network connection means. An advantage thereof is that for networked devices any desired upgrade will always be available.

A further aspect of the present invention provides a data carrier comprising firmware update software for use in a method according to one or more of the claims 1-12.

Further advantages, features and details of the present invention will be described below with reference to the annexed drawings, in which:

Fig. 1 shows a schematic representation of a first embodiment according to the present invention;

Fig. 2 shows a preferred embodiment of a device and system according to the present invention.

A preferred embodiment according to the present invention is shown schematically in Fig. 1. This embodiment is a method for keeping track of upgrade safety of an electronic device. The method starts in step 1. In step 2, an update is acquired, either from a data carrier such as a (solid state) memory device or a CD-ROM or via a computer network or telecommunications network. Generally, suitable data carriers for providing firmware upgrade software can be any computer readable data carrier of any sort. Suitable networks

can comprise public telecoms networks such as mobile or fixed dial up networks, wide area computer networks, local area computer networks or even more local personal area networks, such as Bluetooth networks or the like.

In step 3, the actual update process is started. Such an update process for firmware is generally performed by means of a reboot of the device using a specific instruction for initiating the update process. For purposes of the update, the firmware update software that has been acquired can be stored on erasable memory, such as flash memory or on a hard disc available in the device.

In step 5, a public key for authenticating the firmware update software will be retrieved or read out of a ROM memory of the device as well as a software module that is able to write to a memory location for storing data pertaining to a flag to be used for purposes according to the present invention. In step 5, it is determined whether the firmware update software is provided with a signature identifying the trustworthiness and or the maker of the software. In case it is determined that a signature is present in step 5, in step 6 it is determined whether the signature is valid. For determining the validity of the signature, use is made of the public key that was read out of the ROM memory of the device. For the purpose of determining the validity of the signature, use can be made of a chain of trust based on a root of trust. In case the signature was appended to the firmware update software by an authority not directly linked to the available public key, the chain of trust can be used to indirectly verify the validity of the signature.

If in step 6 it is determined that the signature is a valid signature, the method continues in step 9 by installing the firmware upgrade and if required rebooting the system. In this case, when both a signature is present and the signature is valid, there is no need to change a flag from safe to unsafe.

In a device making use of such a method, several kinds of indicators or data storage mechanisms with respect to firmware updates can be used. A first option is to use a simple one-digit flag that is set to 0 (safe) as a default value when the device is initially produced and provided with a trusted firmware version. When an unsafe firmware update is installed, this digit will be set to 1 (unsafe) in order to represent the fact that an unsafe firmware update was installed. In another embodiment an array of such single-digit flags is present in order to keep track of either all updates or all unsafe updates, or in order to keep track of a moving 'window' of a number of updates or unsafe updates. Preferably, the user of the device will not be able to tamper with the indicator data in any way. Therefore, a change of the indicator value is only possible by means of software present in the ROM of the

device. Another way of preventing undetected tampering is to use a one time fuse which indicates a trusted update when unfused and an untrusted update when fused.

In case all updates are registered by means of a flag, a flag will need to be changed from zero to one in case an update is unsafe. In case an update is safe, no change needs to be recorded. Logically, in case an unsafe firmware update is installed, the flag needs to be changed in step 7, which will be described below.

In other embodiments, information that is linked to a flag or a firmware update will be stored in a memory representing the flag or a separate memory linked to the flag. An item that is stored in such embodiments may be a hash of the firmware update in order to identify the firmware update at a later stage, e.g. when a malfunction has occurred and a warranty claim has been registered with the manufacturer of the device, or an accident has happened due to unsafe firmware malfunction which will be investigated by an authority investigating the cause of such an accident.

If in step 5 it has been determined that no signature is present, or if in step 6 it has been determined that a signature that is present is invalid, in step 7 it will be determined whether a flag is set to safe or unsafe. In case the flag is determined to be set to unsafe, which may be the case when one flag is used for several updates, the process will continue in step 9 with the installation of the upgrade in step 9. Optionally, an additional prompt may be presented to the user on e.g. a screen or via voice information in order to make sure that the user wishes to proceed with the unsafe install.

If in step 7 it is determined that the flag was set to safe, in step 8 the flag will be set to unsafe. Optionally, the user may be asked whether he wants to proceed with an unsafe firmware update, so that the user is given a chance to abort the process. If the user chooses to continue the process and the flag is set to unsafe in step 8, the process proceeds in step 9 as described in the above.

In Fig. 2, an overview of a device in connection with a network and a server is schematically shown. The device can be a consumer electronic device, an automotive device such as a motor management system or a break system or the like, a portable telephone or computer device, etc. The device comprises a memory 11 for storing a public key to be used for verifying a signature of firmware update software. Furthermore, the device comprises a processor and a RAM memory. For connecting to a computer network with an attached server 10 for providing firmware upgrade software, the device is equipped with a network interface 19.

For e.g. storage of programmes, the device is equipped with a flash memory or an EEPROM memory. In such a memory, general purpose programmes as well as firmware updates can be stored. An advantage of such memory is that data can be retained after a power down of the device. For storage of flag data, a memory module 16 comprising either a storage space for flag data such as a flag bit or an array of flag bits, and/or a memory module 17 for recording an upgrade table comprising information such as hash data pertaining to consecutively installed firmware updates. Preferably both of these memory modules can only be written by instructions that are not changeable such as instructions stored in ROM memory of the device.

Connected with the processor there is the signature verifier 18, which can be embodied by means of a hardware module or a software component. As with the software for writing to the flag memory and the public key data memory 11 , this software is preferably tamper proof, since it carries out security operations.

In a device according to the invention the history of firmware upgrades will be retrievable to an extent necessary for determining whether the user has allowed firmware that has initiated unsafe flag registrations. Any malfunction or damage that was caused to the device and/or its environment after installation of unsafe firmware will therefore be attributable to other parties than the manufacturer of the device. The manufacturer can associate a disclaimer to such an occurrence.

Also, it is possible to prevent the device from booting at all using the switch 14. One embodiment of the device is conceivable with merely the switch 14 without the flag such that firmware versions without a valid signature will be prevented at all from being installed or alternatively, the device can be prevented from being booted using firmware lacking a valid signature. For these embodiments, the signature verifier checks the signature before a requested update, or resp. before each boot up of the device.

The invention has been described with reference to the above embodiments. The person skilled in the art may combine several embodiments or use insights that are obvious to him within the disclosure of the present document. The invention is not limited to the above description. The rights are conferred by the annexed claims.