Patent Description:
In some cases, firmware must be updated to provide the latest operation system requirements. For example, manufacturer-based updates may provide up-to-date firmware to a mobile device. The manufacturer-based updates provide application optimization, increased device speeds, new features, operating system stability, and the like.

Among other updating methods, over-the-air (OTA) updating is a preferred method of mobile device updates. These updates may be automatically loaded on to mobile devices and executed by the device manufacturer, regardless of user preferences. In some cases, there is no way to reject a new firmware update. This can create problems when, for example, the update includes a security vulnerability.

Thus, automatic updates may create a security risk for mobile devices. If the updates are performed regardless of user preference, the user may have little or no way to avoid the risk. Therefore, there is a need in the art for systems and methods that provide users more control over firmware updates.

<CIT> discloses a dynamic transaction card. The dynamic transaction card comprises a EuroPay-MasterCard-Visa-processor as EMV-processor storing existing firmware and version data associated with the existing firmware, an EMV plate connectively coupled to the EMV processor, a bootloader; and an input/output interface for receiving an updated firmware program from a firmware provider system, an applet comprising instructions that when executed, cause the EMV processor to perform a checksum validation, and data storage storing a first checksum calculated using the stored firmware upon loading of the firmware, wherein for validating the firmware on the dynamic transaction card the following functions are implemented therein: receiving at the EMV processor, a trigger that triggers checksum validation via the applet, reading, via the applet, the firmware to determine data comprising the first checksum, receiving at the EMV-processor, the data comprising the first checksum, calculating, using the EMV-processor, a second checksum associated with the firmware, comparing, using the EMV-processor, the first checksum and the second checksum, validating the updated firmware program upon determining that the received checksum and the calculated checksum are equal; and deleting at least a portion of data in the data storage and the EMV-processor upon determining that the first checksum and the second checksum are not equal. The EMV-processor is configured to receive, via contacts on the EMV plate, an update component associated with the updated firmware program transmitted from the firmware provider system during a secure communication with the firmware provider system via a secure terminal, wherein the update component is used to validate the received updated firmware program; the bootloader is configured to load the updated firmware program on the dynamic transaction card in response to the validation of the updated firmware program and execute the updated firmware program overwriting the existing firmware; and the EMV-processor) is configured to store and use the updated firmware program in response to the bootloader loading and executing the updated firmware program.

<CIT> shows an image forming apparatus which is capable of updating firmware. Update firmware is downloaded into a download area of an HDD and expanded and stored in a temporary expansion area of the HDD. A CPU determines whether or not the update firmware expanded and stored in the temporary expansion area has been tampered with. The update firmware stored in the temporary storage area is applied to the image forming apparatus when the CPU determines that the update firmware has not been tampered with.

The inventive concept provides an electronic device for updating firmware based on whether a user is authenticated when new firmware update is detected and an operating method thereof.

Embodiments of the present invention are set out in the appended claims.

The present disclosure relates to electronic devices, and more particularly, to an electronic device that enables a user to determine whether to perform firmware update. For example, embodiments of the present disclosure determine whether to perform updates based on user permissions.

Accordingly, embodiments of the present provide users the ability to determine whether their mobile device performs an update based on user consent. When consent-based update is activated, version information of firmware running at a corresponding time point may be stored in a security memory. When system booting is performed, the system may verify whether the firmware contains the same version of the firmware as that which the user has agreed to.

In some embodiments, when a firmware updated is presented, system booting is performed according to existing firmware. User authentication is then performed to determine whether the user is an authorized user. Version information of the updated firmware, which may be running when the user authentication is performed, is stored in the security memory. When rebooting is performed, the updated firmware is loaded, and it is determined whether the version information of the loaded firmware matches the pre-stored version information. Then, booting is performed using new firmware. The existing firmware may be replaced by the new firmware after the booting using the new firmware is completed.

As used herein, the term main firmware may indicate firmware configured to operate when an electronic device starts booting. The main firmware may be replaced by various terms such as embedded firmware, current firmware, or default firmware.

Candidate firmware may indicate firmware distributed by a manufacturer of an electronic device. The candidate firmware may be installed in the electronic device to replace the main firmware previously installed. In general, the candidate firmware may be distributed to the electronic device in a wireless or wired manner, In some cases, distribution in a wireless manner may be referred to as firmware over the air (FOTA). The candidate firmware may be replaced by various terms such as update firmware, new firmware, or replacing the firmware.

According to an embodiment, the electronic device includes a nonvolatile memory (NVM), a main processor, a security NVM, and a security processor. The NVM stores first firmware and a user permission indicator. The main processor loads the first firmware to boot a security processor. The security NVM contains first version information. The security processor compares version information of the first firmware to the first version information based on the user permission indicator and executes the first firmware in response to the matching of the comparison result, wherein the security processor is implemented on the same chip as the main processor.

Hereinafter, various embodiments of the inventive concept will be described in detail with reference to the accompanying drawings.

<FIG> is a block diagram of the electronic device <NUM> according to an example embodiment of the inventive concept.

Referring to <FIG>, the electronic device <NUM> may include a system on chip (SoC) <NUM>, a main NVM <NUM>, a main volatile memory <NUM>, and a security NVM <NUM>.

According to various embodiments of the inventive concept, the SoC <NUM> may include a main processor <NUM>, peripherals <NUM>, main read-only memory (ROM) <NUM>, a dynamic random access memory (DRAM) controller <NUM>, a flash controller <NUM>, and a security processor <NUM>.

The main processor <NUM> may process general jobs of the SoC <NUM>. For example, the main processor <NUM> may perform booting by loading a boot loader (<NUM> of <FIG>) on the main volatile memory <NUM> in response to powering-on of the electronic device <NUM> and control an operation of a host application (<NUM> of <FIG>). The main ROM <NUM> may store various types of control information used to execute the host application <NUM> or operate the SoC <NUM>. The DRAM controller <NUM> may manage the main volatile memory <NUM>. For example, the DRAM controller <NUM> may receive firmware image data from the main NVM <NUM> and load the firmware image data on the main volatile memory <NUM>. The peripherals <NUM> may include devices for inputs and outputs of the electronic device <NUM>. For example, the peripherals <NUM> may include a display controller for controlling a display to display a pop-up window for requesting a user to input user authentication information. The flash controller <NUM> may write data on the main NVM <NUM> or read data from the main NVM <NUM>.

The security processor <NUM> may include a security central processing unit (CPU) <NUM>, security ROM <NUM>, security RAM <NUM>, a crypto engine <NUM>, a mailbox module <NUM>, a security flash controller <NUM>, and a security direct memory access (DMA) controller <NUM>. The security CPU <NUM> may perform a general operation of the security processor <NUM> by using the security RAM <NUM> and the security ROM <NUM>. For example, the security CPU <NUM> may be configured to verify a digital signature for candidate firmware or check version information of the candidate firmware. The security flash controller <NUM> may perform data read or write with the security NVM <NUM>. For example, when user permission is activated, the security flash controller <NUM> may write, on the security NVM <NUM>, user authentication information input from the user. The user authentication information may include a user identification (ID), a password (PW), and biometric data (e.g., fingerprint information, iris information, face recognition information, voice information, or vein information) of the user. The mailbox module <NUM> may perform data communication between the security processor <NUM> and external components by using a mailbox protocol. According to an embodiment of the inventive concept, the mailbox module <NUM> may include a plurality of registers and perform communication by receiving a command and data from an external component and classifying the command and data.

The crypto engine <NUM> may encrypt input data by using a key. According to an embodiment of the inventive concept, the crypto engine <NUM> may encrypt user authentication information by using a security key and store the encrypted user authentication information in the security NVM <NUM>. According to another embodiment of the inventive concept, the crypto engine <NUM> may provide at least one algorithm among hashed message authentication code (HMAC), Rivest, Shamir, Adleman (RSA), and elliptic curve digital signature algorithm (ECDSA) for calculating a hash value for firmware version information or verify a digital signature. The security DMA controller <NUM> may be electrically connected to the main volatile memory <NUM> outside the security processor <NUM>. The security DMA controller <NUM> may access the main volatile memory <NUM> to read data into the security processor <NUM>. For example, the security DMA controller <NUM> may read, into the security processor <NUM>, data of firmware loaded on the main volatile memory <NUM>.

According to various embodiments of the inventive concept, the security NVM <NUM> may indicate an NVM directly connected to the security processor <NUM> inside the SoC <NUM>. The security NVM <NUM> may store data, which is to be processed by the security processor <NUM>, and of which security is used, because the security NVM <NUM> performs communication with the security processor <NUM> inside the SoC <NUM>. For example, the security processor <NUM> may store user authentication data, main image version information, candidate image version information, and the like in the security NVM <NUM>.

The user authentication data, the main image version information, and the candidate image version information may correspond to data to be used for the security processor <NUM> to determine whether the user of the electronic device <NUM> has agreed on update (or modification) to new firmware This will be described below in detail with reference to <FIG>.

The main NVM <NUM> may indicate an NVM accessible to the main processor <NUM> and the security processor <NUM>. For example, the main processor <NUM> may access the main NVM <NUM> to operate the boot loader <NUM>. As another example, the security processor <NUM> may load data related to firmware update by accessing the main volatile memory <NUM> or load the data related to the firmware update by directly accessing the main NVM <NUM>.

According to an embodiment of the inventive concept, the main NVM <NUM> and the security NVM <NUM> may include an NVM in which stored data does not vanish even when a power supply is turned off. For example, the main NVM <NUM> and the security NVM <NUM> may include a NAND flash memory, a vertical NAND flash memory, a NOR flash memory, resistive RAM, a phase-change memory, magneto-resistive RAM, or the like.

The main volatile memory <NUM> may be accessible to the host application <NUM> and the security processor <NUM>. For example, the main volatile memory <NUM> may load the main firmware thereon and perform booting. According to an embodiment of the inventive concept, the main volatile memory <NUM> may include a memory in which stored data vanishes when a power supply is turned off. For example, the main volatile memory <NUM> may include static RAM (SRAM), dynamic RAM (DRAM), or magneto-resistive RAM. Hereinafter, the description will be made based on the main volatile memory <NUM> implemented by DRAM <NUM>.

<FIG> is a format of data stored in the main NVM <NUM>, according to an example embodiment of the inventive concept. <FIG> is a format of data loaded on the DRAM <NUM>, according to an example embodiment of the inventive concept. Referring to <FIG> and <FIG>, the main NVM <NUM> may include an update data region <NUM>, a main image region <NUM>, and a candidate image region <NUM>.

The update data region <NUM> may include information indicating which firmware is loaded to perform booting when the boot loader <NUM> is activated, and the electronic device <NUM> starts booting. For example, the update data region <NUM> may include a user permission indicator <NUM>, main image location data <NUM>, and an update indicator <NUM>.

According to an embodiment of the inventive concept, the user permission indicator <NUM> may include information indicating whether user permission is activated when booting is performed in response to the powering-on of the electronic device <NUM>.

Herein, user permission may indicate that booting is performed through firmware installed or distributed with the user's consent. For example, when user permission is activated, even though arbitrary firmware loaded on the DRAM <NUM> to boot the electronic device <NUM> is legally distributed by the manufacturer of the electronic device <NUM>, the booting of the electronic device <NUM> may fail when the loaded firmware has a version different from that of firmware installed with the user's consent.

For example, when a value of the user permission indicator <NUM> is "<NUM>" or logic high, the electronic device <NUM> may compare a version of firmware loaded on the DRAM <NUM> is the same as a version of firmware installed with the user's consent when booting is performed. As another example, when the value of the user permission indicator <NUM> is "<NUM>" or logic low, the electronic device <NUM> may not check a version of firmware loaded on the DRAM <NUM>. For example, when user permission is inactivated, the electronic device <NUM> may perform booting according to update firmware when the update firmware is activated. A detailed description of the user permission indicator <NUM> will be described below with reference to <FIG>.

The main image location data <NUM> may include information related to a location where the main firmware is stored. The main image location data <NUM> may be implemented by a pointer or may include a start address at which an image of the main firmware and a digital signature are stored and size information of the main firmware. When the electronic device <NUM> performs booting, the electronic device <NUM> may load the main firmware on the DRAM <NUM> with reference to the main image location data <NUM>.

According to an embodiment of the inventive concept, the main image location data <NUM> may have a value changed when a firmware update is performed. For example, the candidate firmware may be stored in a region B among the storage regions of the main NVM <NUM> because candidate firmware may not be overwritten in a region A in which the main firmware is stored among storage regions of the main NVM <NUM>. Therefore, after the firmware update is completed, the main image location data <NUM> may have a value changed to indicate the region B.

The update indicator <NUM> may include information indicating whether the electronic device <NUM> performs firmware update. The firmware update may indicate a series of processes of changing the main firmware previously stored to newly distributed update firmware.

For example, when a value of the update indicator <NUM> is "<NUM>" or logic high, the update indicator <NUM> may indicate that firmware of a version different from that of the main firmware is stored in the candidate image region <NUM>. Herein, the different firmware version may include the latest version and previous versions. As another example, when the value of the update indicator <NUM> is "<NUM>" or logic low, the update indicator <NUM> may indicate that firmware of a version different from that of the main firmware is not stored in the candidate image region <NUM>. For example, the electronic device <NUM> may determine whether there exists newly stored update firmware, by referring to the value of the update indicator <NUM>.

According to various embodiments of the inventive concept, the main image region <NUM> may correspond to a region in which data of the main firmware is stored, and the candidate image region <NUM> may correspond to a region in which data of candidate firmware is stored. Each firmware data may be identified by an image body and a digital signature. The digital signature may indicate information for guaranteeing that corresponding firmware was distributed by a manufacturer and has not been falsified. Referring to <FIG>, the SoC <NUM> may load the boot loader <NUM> on the DRAM <NUM>. The boot loader <NUM> may indicate a program or instructions configured to perform booting of the electronic device <NUM>. Additionally or alternatively, the boot loader <NUM> may indicate a program or a set of instructions configured to wrap up some or all tasks used to correctly start a kernel by being previously executed before starting an operating system (OS) <NUM>, and to start the OS <NUM>.

Although <FIG> shows that the boot loader <NUM> is a single boot loader, the boot loader <NUM> is not limited thereto. According to various embodiments of the inventive concept, the boot loader <NUM> may have a hierarchical structure. For example, the boot loader <NUM> may include stage <NUM> and stage <NUM> and may further include stage <NUM>. When the boot loader <NUM> has a hierarchical structure, stages therein may be sequentially executed.

The SoC <NUM> may load the host application <NUM> on the DRAM <NUM>. The host application <NUM> may correspond to a program or instructions to be performed by the main processor <NUM>. The host application <NUM> may operate independently to the OS <NUM>. For example, the host application <NUM> may normally operate even before starting the OS <NUM>.

<FIG> is a format of data stored in the security NVM <NUM>, according to an example embodiment of the inventive concept.

Referring to <FIG>, the security NVM <NUM> may include user authentication data <NUM>, main image version information <NUM>, and candidate image version information <NUM>.

The user authentication data <NUM> may include information related to user authentication. For example, the user authentication data <NUM> may include user authentication information <NUM>, the user permission indicator <NUM>, and authentication status information <NUM>.

A description of the user permission indicator <NUM> included in the user authentication data <NUM> is made with reference to <FIG> and is omitted herein.

The user authentication information <NUM> may be generated when user authentication is initially activated, and stored in the security NVM <NUM>. For example, the user authentication information <NUM> may be information input when the user of the electronic device <NUM> initially activates user authentication. Thereafter, the electronic device <NUM> may authenticate whether a user is an authorized user when a firmware update is performed. The user authentication information <NUM> may include a combination of random characters, numbers, symbols, and the like. Additionally or alternatively, the user authentication information <NUM> may also include the user's biometric data (e.g., fingerprint information, iris information, face recognition information, voice information, or vein information).

The authentication status information <NUM> may include information indicating a result of user authentication. When new firmware is installed after activating user permission, the electronic device <NUM> may control the display controller among the peripherals <NUM> to display, on the display, a pop-up window for requesting an input of user authentication information. For example, the user authentication information input through the pop-up window may be verified using the user authentication information <NUM> stored in the security NVM <NUM>. When the verification is successful, the user is an authorized user. Therefore, the authentication status information <NUM> may have a value of "<NUM>" or logic high. As another example, when the verification fails, the user is not an authorized user. Therefore, the user authentication fails, and the authentication status information <NUM> may have a value of "<NUM>" or logic low.

The main image version information <NUM> may include version information of the main firmware. The version information is not limited to information indicated by a firmware version officially named by a manufacturer and may include various types of information that may certify the main firmware.

For example, the main image version information <NUM> may include a hash value of the main firmware. Because the hash value may vary due to a very minute data difference between the main firmware and random firmware, the hash value may certify the main firmware. As another example, the main image version information <NUM> may include a value of a digital signature for the main firmware. The digital signature may be generated based on at least one algorithm among HMAC, RSA, and ECDSA. However, the main image version information <NUM> is not limited to a hash value or a digital signature value and may include some or all values which may certify firmware.

The candidate image version information <NUM> may include version information of candidate firmware. Like the main image version information <NUM>, the candidate image version information <NUM> may include a hash value and/or a digital signature value of the candidate firmware.

According to various embodiments of the inventive concept, a size of the version information of the main firmware and/or the candidate firmware may be variable. The size of the version information may be determined based on a security level of the security processor <NUM>. For example, when the security level of the security processor <NUM> is higher than a threshold level, the main image version information <NUM> and/or the candidate image version information <NUM> may include a hash value obtained by using a hash function (e.g., SHA-<NUM>) with a long digest. The digest may indicate an output of the hash function and may correspond to a length of output bits. As another example, when the security level of the security processor <NUM> is lower than the threshold level, the main image version information <NUM> and/or the candidate image version information <NUM> may include a hash value obtained by using a hash function (e.g., SHA-<NUM>) with a short digest.

<FIG> is a flowchart of an operating sequence of the electronic device <NUM> when user permission is inactivated, according to an example embodiment of the inventive concept.

Referring to <FIG>, the electronic device <NUM> may activate the boot loader <NUM> in operation S110. In response to powering-on the electronic device <NUM>, the boot loader <NUM> may be loaded on the DRAM <NUM> to perform a boot sequence, and the host application <NUM> may be driven.

In operation S120, the electronic device <NUM> may determine whether an update indicator value has a certain logic value (e.g., a "<NUM>", or logic high value). For example, the update indicator <NUM> may indicate whether candidate firmware is newly stored. The host application <NUM> of the electronic device <NUM> may identify the update indicator value by loading the update data region <NUM> stored in the main NVM <NUM>,.

In operation S130, the electronic device <NUM> may load the main firmware on the DRAM <NUM>. When the update indicator value is "<NUM>" or logic low in operation S120, candidate firmware for a firmware update other than the main firmware does not exist. Therefore, the main firmware is loaded to boot the main firmware previously installed.

According to various embodiments of the inventive concept, data, when operation S130 is performed, is as follows.

In operation S140, the electronic device <NUM> may verify a digital signature for the main firmware. The digital signature may be used to verify whether firmware was distributed by an authorized issuer (e.g., the manufacturer of the electronic device <NUM>) and has not been falsified) The security processor <NUM> booted in operation S130 may perform signature verification based on the digital signature included in the main firmware.

In operation S150, the electronic device <NUM> may execute the main firmware. After verifying the digital signature, the security processor <NUM> may execute the main firmware. When user permission is activated, version information of firmware to be executed is supposed to be checked, but user permission has not been activated. Therefore, a process of checking version information of firmware may be skipped or bypassed.

In operation S160, the electronic device <NUM> may load candidate firmware on the DRAM <NUM>. When the update indicator value is "<NUM>" or logic high in operation S120, the host application <NUM> may identify that candidate firmware for a firmware update exists to replace the main firmware. Therefore, the host application <NUM> may load the candidate firmware to boot the candidate firmware instead of the main firmware.

According to various embodiments of the inventive concept, data when operation S160 is performed is as follows.

In operation S170, the electronic device <NUM> may verify a digital signature of the candidate firmware. A description of verification of the digital signature is the same as the description of operation S140 and is omitted herein.

In operation S180, the electronic device <NUM> may execute the candidate firmware. After verifying the digital signature, the security processor <NUM> may execute the candidate firmware. When user permission is activated, version information of the candidate firmware to be executed will be checked. However, if user permission has not been activated, the process of checking version information of firmware may be skipped.

In operation S190, electronic device <NUM> may change the information in the update data region <NUM>. For example, when the candidate firmware is distributed (or received) in a state where the main firmware is stored in the region A of the main NVM <NUM>, the candidate firmware may be stored in the region B of the main NVM <NUM>. Because booting using the candidate firmware has succeeded in operation S180, the host application <NUM> of the electronic device <NUM> may change the main image location data <NUM> from the region A to the region B so that the candidate firmware is booted when booting is performed thereafter. For example, when the booting using the candidate firmware is finished, information may be changed to identify the candidate firmware as the main firmware. Additionally or alternatively, the host application <NUM> may delete the existing main firmware stored in the region A and change the value of the update indicator <NUM> to "<NUM>" or logic low because new candidate firmware is not stored in the region A yet. When the value of the update indicator <NUM> is not changed, a wrong operation may occur by considering that new firmware update is performed when booting is performed.

In some cases, the main firmware stored in the region A is deleted and the host application <NUM> changes the value of the update indicator <NUM> to "<NUM>" or logic low in response to the deletion of the main firmware. However, the present embodiment is not limited thereto. When the host application <NUM> changes the value of the update indicator <NUM> to "<NUM>" or logic low and changes the main image location data <NUM> from the region A to the region B, the host application <NUM> may bypass the deletion of the main firmware stored in the region A. Because the update indicator value and the main image location data <NUM> have been changed, the host application <NUM> does not perform booting by using the existing main firmware stored in the region A. When new firmware is received, the host application <NUM> may overwrite the existing main firmware stored in the region A.

According to various embodiments of the inventive concept, data, when operation S190 is performed, is as follows.

<FIG> is a flowchart of an operating sequence of the electronic device <NUM> for activating user permission, according to an example embodiment of the inventive concept.

Referring to <FIG>, in operation S210, the electronic device <NUM> may perform primary booting. Herein, the primary booting may indicate booting before user permission is activated. For example, the primary booting may indicate that the user initially booted the electronic device <NUM> shipped from the manufacturer. Therefore, completion of the primary booting may indicate that the operations of <FIG> are performed. For example, in operation S210, user permission is inactivated, and the main firmware may be firmware (factory initialization firmware) when the electronics device <NUM> was manufactured or one of the pieces of firmware additionally distributed by the manufacturer after the electronics device <NUM> was manufactured.

According to various embodiments of the inventive concept, data, when operation S210 is performed, is as follows.

In operation S220, the electronic device <NUM> may receive a user input for activating user permission. For example, the electronic device <NUM> may display on the display, among the peripherals <NUM>, a pop-up window including a visual notification such as "Do you want to suspend automatic firmware update?" or "Do you want to perform firmware update with a user's consent?" when a firmware update is performed. Alternatively, the user may directly input the activation of user permission by entering a menu through which user permission is activated.

In operation S230, electronic device <NUM> may receive user authentication information and store the user authentication information in the security NVM <NUM>. The user authentication information may be information about the user ID and the user password described above with reference to <FIG>.

In some cases, the host application <NUM> of the electronic device <NUM> may display a pop-up window for requesting input of user authentication information to activate user permission. For example, the pop-up window may display regions for inputting the user ID and PW or display guide information for obtaining biometric information. The host application <NUM> may transmit the input user authentication information to the security processor <NUM>. By transmitting the user authentication information to the security processor <NUM> and storing the same in the security NVM <NUM>, a firmware update to be performed by the security processor <NUM> may be performed not based on unreliable user authentication information stored in the outside of the electronic device <NUM> but based on the user authentication information stored in the security NVM <NUM> which is connected with the security processor <NUM>. Accordingly, the security and reliability of firmware update performed by the security processor <NUM> may be increased.

In operation S240, the electronic device <NUM> may change a value of the user permission indicator <NUM>. For example, because the value of the user permission indicator <NUM> is "<NUM>" or logic low before the user activates user permission, the value of the user permission indicator <NUM> may be changed to "<NUM>" or logic high. By changing the value of the user permission indicator <NUM>, when a firmware update is performed thereafter, the host application <NUM> of the electronic device <NUM> may perform a user permission operation.

In operation S250, the electronic device <NUM> may generate version information of the main firmware and store the version information in the security NVM <NUM>. Before user permission is activated, the firmware of a version permitted by the user is booted may or may not be checked. Therefore, version information of the main firmware may not be generated or stored. However, firmware may be checked whether to be booted corresponding to firmware permitted by the user when user permission is activated. Therefore, the version information of the main firmware, i.e., firmware loaded when user permission is activated, may be generated and stored. The version information of the main firmware may correspond to the main image version information <NUM> of <FIG>.

Particularly, the security processor <NUM> may generate the main image version information <NUM> and store the main image version information <NUM> in the security NVM <NUM>. Accordingly, information for determining whether firmware has a version permitted by the user may be used as the main image version information <NUM> stored not in the outside of the electronic device <NUM> but in the security NVM <NUM>, which may be connected with the security processor <NUM>. Accordingly, the security and reliability of a booting process performed by the security processor <NUM> may be increased.

According to various embodiments of the inventive concept, data, when user permission is activated in <FIG>, is as follows.

<FIG> is a flowchart of an operating sequence of the electronic device <NUM> for performing booting by using the main firmware when user permission is activated, according to an example embodiment of the inventive concept.

Referring to <FIG>, in operation S310, the electronic device <NUM> may perform secondary booting. Herein, the secondary booting may indicate booting after user permission is activated in <FIG>.

According to various embodiments of the inventive concept, data, when the secondary booting of operation S310 is performed, is as follows.

In operation S320, the electronic device <NUM> may identify that an update indicator value is logic low. The host application <NUM> of the electronic device <NUM> may load the update data region <NUM> stored in the main NVM <NUM>, identify that a value of the update indicator <NUM> is "<NUM>" or logic low, and determine that there does not exist candidate firmware for performing a firmware update. The host application <NUM> may identify that user permission is activated, based on the user permission indicator <NUM> stored in the main NVM <NUM>, but the firmware update may not be performed. Therefore, the host application <NUM> may perform booting by loading the main firmware on the DRAM <NUM>.

In operation S330, the electronic device <NUM> may boot the security processor <NUM> by using the main firmware. A description of operation S330 is the same as the description of operation S130 of <FIG> and is omitted herein.

In operation S340, the electronic device <NUM> may verify a digital signature for the main firmware. A description of operation S340 is the same as the description of operation S140 of <FIG> and is omitted herein.

In operation S350, the electronic device <NUM> may identify that a value of the user permission indicator <NUM> is logic high. The security processor <NUM> of the electronic device <NUM> may determine that user permission is activated, based on a value of the user permission indicator <NUM> stored in the security NVM <NUM>. When user permission is activated, the digital signature for the main firmware may be determined as verified and whether firmware loaded on the security RAM <NUM> matches firmware of a version permitted by the user.

In operation S360, the electronic device <NUM> may compare whether the main image version information <NUM> stored in the security NVM <NUM> is the same as version information of the loaded firmware. For example, the security processor <NUM> may generate test version information of the firmware loaded on the security RAM <NUM> to determine whether the loaded firmware is the same as the firmware of the version permitted by the user. The test version information may be generated by performing a calculation on the firmware loaded on the security RAM <NUM> based on the same function as a function used to generate the main image version information <NUM>. For example, when the main image version information <NUM> is generated based on SHA-<NUM> among hash functions, the security processor <NUM> may perform a calculation on the firmware loaded on the security RAM <NUM> by using a hash function, SHA-<NUM>.

When the two pieces of version information differ from each other, the firmware currently loaded on the security RAM <NUM> is not firmware of the version permitted by the user. Therefore, booting may fail and an operating sequence may end.

In operation S370, the electronic device <NUM> may execute the main firmware. When the two pieces of version information match in operation S360, the main firmware currently loaded on the security RAM <NUM> is the firmware of the version permitted by the user. Therefore, the security processor <NUM> may complete booting by executing the main firmware.

<FIG> is a flowchart of an operating sequence of the electronic device <NUM> for performing a firmware update by using candidate firmware when user permission is activated, according to an example embodiment of the inventive concept.

Referring to <FIG>, in operation S410, the electronic device <NUM> may activate user permission. A process of activating user permission may indicate that operations S210 to S250 of <FIG> are completed.

In operation S420, the electronic device <NUM> may identify that an update indicator value is logic high. For example, the electronic device <NUM> may receive candidate firmware distributed from the manufacturer and store the received candidate firmware in the main NVM <NUM>. When the candidate firmware is received, the host application <NUM> of the electronic device <NUM> changes the update indicator <NUM> to "<NUM>" or logic high. Therefore, the host application <NUM> may identify that a firmware update is supposed to be performed based on a value of the update indicator <NUM> in a booting process.

According to various embodiments of the inventive concept, data, when operation S420 is performed, is as follows.

In operation S430, the electronic device <NUM> may boot the security processor <NUM> by using the main firmware. When the value of the update indicator <NUM> is identified as logic high, booting is performed using the main firmware to obtain the user's consent on a firmware update. For example, when the value of the update indicator <NUM> is identified, the authentication status information <NUM> may be "<NUM>" or FAIL. Therefore, the host application <NUM> may boot the security processor <NUM> by using the existing main firmware.

In operation S440, the electronic device <NUM> may successfully perform booting by using the main firmware. Herein, the successful booting of operation S440 may be the same as performing operations S340 to S370 of <FIG>. For example, because user permission is activated, it would be understood by those of ordinary skill in the art that the main firmware may be executed through a process of verifying a digital signature for the main firmware and checking whether the main firmware is the same as the firmware of the version permitted by the user.

In operation S450, the electronic device <NUM> may perform user authentication. The electronic device <NUM> may display, on the display among the peripherals <NUM>, a pop-up window for requesting the user to input a user ID and a user password. Alternatively, the electronic device <NUM> may display a pop-up window for guiding an input of biometric data.

The host application <NUM> may transmit the input user authentication information to the security processor <NUM>. The security processor <NUM> may verify whether the user authentication information received from the host application <NUM> is authentication information of an authorized user by using the user authentication data <NUM> pre-stored in the security NVM <NUM>. When the user authentication information received from the host application <NUM> is verified, the user is an authorized user. Therefore, user authentication may succeed. According to various embodiments of the inventive concept, when the verification fails, the authentication status information <NUM> may not be changed.

In operation S460, the electronic device <NUM> may change the value of the authentication status information <NUM> and generate and store version information of the candidate firmware. When the user authentication succeeds, the security processor <NUM> may change the authentication status information <NUM> to "<NUM>" or PASS to reflect the user authentication success.

Next, the security processor <NUM> may generate the version information of the candidate firmware. The version information of the candidate firmware may correspond to the candidate image version information <NUM> of <FIG>. The security processor <NUM> may generate the candidate image version information <NUM> and store the same in the security NVM <NUM> to indicate that the user has agreed on firmware update with the candidate firmware when rebooting is performed.

According to various embodiments of the inventive concept, data, when operation S460 is performed, is as follows.

In operation S470, the electronic device <NUM> may reboot the security processor <NUM>. Because booting is performed using the existing main firmware to obtain user permission, the security processor <NUM> may be rebooted to perform a firmware update with the candidate firmware.

In operation S480, the electronic device <NUM> may identify the changed authentication status information <NUM>. The security processor <NUM> may identify the user permission indicator <NUM> and the authentication status information <NUM> while the rebooting is performed. Because user permission is activated, the user permission indicator <NUM> is "<NUM>" or logic high, and accordingly, the security processor <NUM> may refer to the authentication status information <NUM> to determine whether user authentication is completed. Because the authentication status information <NUM> has been changed according to the user authentication success in operation S460, the security processor <NUM> may identify that the candidate firmware of the version permitted by the user. Therefore, in operation S490, the security processor <NUM> may load the candidate firmware on the security RAM <NUM>. It would be understood by those of ordinary skill in the art that verifying a digital signature after loading the candidate firmware on the security RAM <NUM> is omitted.

In operation S500, the electronic device <NUM> may determine whether the candidate image version information <NUM> stored in the security NVM <NUM> is the same as version information loaded on the DRAM <NUM>. A detailed description of comparing the two pieces of version information is the same as the description of operation S360 and is omitted herein. The version information to be compared in operation S500 may be the version information of the candidate firmware. For example, the security processor <NUM> may determine whether the firmware currently loaded on the security RAM <NUM> is the same as the candidate firmware permitted for an update during the user authentication in operation S450.

In operation S510, the electronic device <NUM> may change the main image version information <NUM>, the candidate image version information <NUM>, the update indicator <NUM>, the main image location data <NUM>, and the authentication status information <NUM>.

When the comparison result in operation S500 is identical, the security processor <NUM> may determine that the firmware loaded on the DRAM <NUM> is the same as the candidate firmware permitted by the user, and complete the booting based on the candidate firmware. Because the firmware update is completed, the electronic device <NUM> may change the main image version information <NUM>, the update indicator <NUM>, the main image location data <NUM>, and the authentication status information <NUM> to prevent a wrong operation that there exists firmware update when booting is performed.

According to various embodiments of the inventive concept, the security processor <NUM> may change image version information because the existing candidate firmware becomes new main firmware after completing the firmware update. Because the firmware update is completed, the security processor <NUM> may replace the main image version information <NUM> with the existing candidate image version information <NUM> and delete the existing candidate image version information <NUM>. By overwriting the main image version information <NUM> with the existing candidate image version information <NUM>, when booting is performed thereafter, the new main firmware may be authenticated as the firmware of the latest version permitted by the user.

Additionally or alternatively, the security processor <NUM> may change the authentication status information <NUM> to "<NUM>" or FAIL again. When the authentication status information <NUM> is not changed, firmware update not intended by the user may be performed because the authentication status information <NUM> is still PASS even though the user does not permit an update for new candidate firmware when firmware update occurs.

The main processor <NUM> may change a value of the update indicator <NUM>. Because the firmware update is completed, the main processor <NUM> may change the value of the update indicator <NUM> to "<NUM>" or logic low again. When the value of the update indicator <NUM> is not changed, there may occur a wrong operation that new firmware update exists when booting is performed even though the firmware update is completed.

The main processor <NUM> may change the main image location data <NUM>. Because a region in which the existing candidate firmware is stored is the region A of the main NVM <NUM>, the main image location data <NUM> may be changed to indicate the region B. When the main image location data <NUM> is not changed, booting may be attempted using the region A in which the main firmware prior to the firmware update is stored. As a result, the booting may fail because firmware version information in the region A differs from the changed main image version information <NUM>.

According to various embodiments of the inventive concept, data, when operation S510 is performed, is as follows.

In operation S520, the electronic device <NUM> may delete the candidate firmware. When the version information does not match in operation S500, the candidate firmware is not the firmware permitted by the user. Therefore, the candidate firmware may be deleted, and booting using the existing main firmware may be performed.

Therefore, According to another aspect of the inventive concept, a method of updating firmware, the method may include receiving a firmware update for a firmware of the electronic device; identifying a user permission indicator indicating that user consent is required prior to updating the firmware; obtaining consent to update the firmware based on the user permission indicator; and updating the firmware with the firmware update based on the consent.

In some cases, the method further comprises performing a user authentication; receiving user input for activating a user permission mode; and setting the user permission indicator based on the user authentication and the user input. In some cases, the method further comprises storing a candidate version of the firmware based on the firmware update; and setting an update indicator based on receiving the firmware update, wherein the consent is obtained based on the update indicator.

In some cases, the method further comprises performing a user authentication, wherein the consent is obtained based on the user authentication; and updating authentication status information based on the user authentication, wherein the firmware is updated based on the authentication status information. In some cases, updating the firmware further comprises loading candidate firmware associated with the firmware update; verifying version information of the candidate firmware; and saving the candidate firmware to a main image location based on the verification.

Claim 1:
A system on chip (<NUM>) comprising:
a main processor (<NUM>), a security processor (<NUM>) and a security nonvolatile memory, NVM, (<NUM>);
the main processor (<NUM>) configured to load a first firmware to boot the security processor (<NUM>) and configured to activate an update indicator (<NUM>) when a second firmware is stored in a main the NVM (<NUM>), wherein the second firmware is different from the first firmware; and
the security NVM (<NUM>) containing first version information and user permission indicator (<NUM>);
wherein the security processor (<NUM>) is configured to:
activate a user permission indicator (<NUM>) in response to receive user authentication information (<NUM>) including user identification (ID) and a password, the user authentication information (<NUM>) being stored in the security NVM (<NUM>);
verify the user using the stored user authentication information (<NUM>);
generate and store the first version information including a hash value of the first firmware which is running when the user permission indicator (<NUM>) is activated;
when the update indicator is inactive, perform booting by loading the first firmware;
compare version information of the first loaded firmware with the first version information when the user permission indicator (<NUM>) is activated; and
execute the first loaded firmware in response to matching of the comparison result, and
wherein the security processor (<NUM>) is implemented on a same chip as the main processor (<NUM>).