Electronic device and operating method of electronic device

Abstract

The present disclosure relates to an electronic device, such as a system on a chip, that can perform a firmware update based on user consent. The electronic device includes a non-volatile memory (NVM), a main processor, a secure NVM, and a secure processor. The non-volatile memory (NVM) stores a first firmware and a user permission indicator. The main processor loads the first firmware to boot the secure processor. The secure NVM contains first version information. The secure processor compares version information of the first firmware with the first version information based on the user permission indicator and runs the first firmware in response to a result of the comparison being a match. In some examples, the secure processor is implemented on the same chip as the main processor.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims priority to Korean Patent Application No. 10-2020-0004950, filed on January 14, 2020, in the Korean Intellectual Property Office, the disclosure of which is incorporated herein in its entirety by reference. TECHNICAL FIELD

[0003] The present application relates to an electronic device that updates firmware based on user authentication and an operating method thereof. BACKGROUND

[0004] Mobile devices such as tablet computers, mobile phones, and laptop computers utilize software to perform various functions related to the availability of the device. The term software can include data temporarily stored in a user-controlled memory as well as firmware semi-permanently stored in a hardware memory.

[0005] In some cases, firmware must be updated to provide the latest operating system requirements. For example, manufacturer-based updates can provide the latest firmware to a mobile device. Manufacturer-based updates provide application optimization, improved device speed, new functionality, operating system stability, and the like.

[0006] Among other update methods, over-the-air (OTA) updates are the preferred method of updating mobile devices. These updates can be automatically loaded onto a mobile device and run by the device manufacturer, regardless of user preference. In some cases, new firmware updates cannot be declined. This creates a problem, for example, when the update includes a security vulnerability.

[0007] Accordingly, automatic updates can create security risks for mobile devices. If updates are performed without regard to user preference, the user can have little or no way to avoid the risk. Therefore, there is a need in the art for systems and methods that provide users with the ability to have more control over firmware updates. SUMMARY

[0008] The present inventive concept provides an electronic device that updates firmware based on whether a user is authenticated when a new firmware update is detected and an operating method thereof.

[0009] According to an aspect of the present inventive concept, there is provided an electronic device including: a non-volatile memory (NVM) storing a first firmware and a user permission indicator; a main processor configured to load the first firmware to start a secure processor; a secure NVM containing first version information; and a secure processor configured to compare version information of the first firmware with the first version information based on the user permission indicator, and to execute the first firmware in response to a result of the comparison being a match.

[0010] According to another aspect of the present inventive concept, there is provided an operating method of an electronic device, the operating method including: starting a secure processor according to a first firmware; comparing version information of the first firmware with first version information based on a user permission indicator; and executing the first firmware when a result of the comparison is a match.

[0011] According to another aspect of the present inventive concept, there is provided an electronic device including: a non-volatile memory (NVM) storing a first firmware, a second firmware, and an update indicator indicating that the second firmware is stored; a main processor configured to load the first firmware when the update indicator is deactivated, and to load the second firmware when the update indicator is activated; and a secure processor configured to verify a digital signature of the first firmware when the first firmware is loaded, and to execute the first firmware in response to success of the verification, or to verify a digital signature of the second firmware when the second firmware is loaded, and to execute the second firmware in response to success of the verification.

[0012] According to another aspect of the present inventive concept, a method of updating a firmware can include: receiving a firmware update for a firmware of the electronic device; identifying a user permission indicator indicating that a user consent is required before updating the firmware; obtaining a consent to update the firmware based on the user permission indicator; and updating the firmware with the firmware update based on the consent. BRIEF DESCRIPTION OF DRAWINGS

[0013] Embodiments of the present inventive concept will become more fully understood from the detailed description given herein below, and the accompanying drawings, which are given by way of illustration only and thus are not limitative of the present inventive concept, and wherein:

[0014] Figure 1 is a block diagram of an electronic device according to an example embodiment of the present inventive concept;

[0015] Figure 2 is a format of data stored in a main non-volatile memory (NVM) according to an example embodiment of the present inventive concept;

[0016] Figure 3 This is the format of data loaded on main volatile memory according to an exemplary embodiment of the present invention;

[0017] Figure 4 This is the format of data stored in a secure NVM according to an exemplary embodiment of the present invention;

[0018] Figure 5 This is a flowchart illustrating the operation sequence of an electronic device when user permission is deactivated, according to an exemplary embodiment of the present invention.

[0019] Figure 6 This is a flowchart of an operation sequence for activating a user-licensed electronic device according to an exemplary embodiment of the present invention;

[0020] Figure 7 This is a flowchart illustrating an example embodiment of the present invention, showing the operation sequence of an electronic device being started using the main firmware when a user license is activated; and

[0021] Figure 8 This is a flowchart illustrating the operation sequence of an electronic device that performs a firmware update using candidate firmware when a user license is activated, according to an exemplary embodiment of the present invention. Detailed Implementation

[0022] This disclosure relates to electronic devices, and more specifically, to electronic devices that enable a user to determine whether to perform a firmware update. For example, embodiments of this disclosure determine whether to perform an update based on user permission.

[0023] Therefore, embodiments of this disclosure provide users with the ability to determine whether their mobile devices should be updated based on user consent. When a consent-based update is activated, firmware version information at the appropriate point in time can be stored in secure storage. When the system boots up, it can verify whether the firmware contains the same version as the one the user has consented to.

[0024] In some embodiments, when a firmware update is available, the system boots based on the existing firmware. User authentication is then performed to determine if the user is authorized. Version information of the updated firmware that may be running during user authentication is stored in secure storage. Upon reboot, the updated firmware is loaded, and it is determined whether the version information of the loaded firmware matches pre-stored version information. Booting is then performed using the new firmware. After booting with the new firmware is complete, the existing firmware can be replaced with the new firmware.

[0025] As used herein, the term "master firmware" can refer to the firmware configured to run when an electronic device begins booting. Master firmware can be replaced by various terms such as embedded firmware, current firmware, or default firmware.

[0026] Candidate firmware refers to firmware distributed by the manufacturer of an electronic device. Candidate firmware can be installed in an electronic device to replace the previously installed main firmware. Typically, candidate firmware can be distributed to electronic devices wirelessly or via wired connection. In some cases, wireless distribution may be referred to as firmware over the air (FOTA). Candidate firmware can be replaced by various terms such as updated firmware, new firmware, or replacement firmware.

[0027] According to an embodiment, the electronic device includes non-volatile memory (NVM), a main processor, a secure NVM, and a secure processor. The NVM stores first firmware and a user license indicator. The main processor loads the first firmware to start the secure processor. The secure NVM contains first version information. The secure processor compares the version information of the first firmware with the first version information based on the user license indicator, and runs the first firmware in response to a match, wherein the secure processor and the main processor are implemented on the same chip.

[0028] In the following, various embodiments of the inventive concept will be described in detail with reference to the accompanying drawings.

[0029] Figure 1 This is a block diagram of an electronic device 10 according to an exemplary embodiment of the present invention.

[0030] Reference Figure 1 The electronic device 10 may include a system on chip (SoC) 100, a main NVM 200, a main volatile memory 300, and a secure NVM 400.

[0031] According to various embodiments of the present invention, the SoC 100 may include a main processor 110, a peripheral device 120, a main read-only memory (ROM) 130, a dynamic random access memory (DRAM) controller 140, a flash memory controller 150, and a security processor 160.

[0032] The main processor 110 can handle general tasks of the SoC 100. For example, the main processor 110 can initiate a booting loader in response to power-up of the electronic device 10. Figure 3 301) is loaded onto main volatile memory 300 to perform startup and control the host application ( Figure 3The operation of host application 303). Main ROM 130 can store various types of control information used to execute host application 303 or operate SoC 100. DRAM controller 140 can manage main volatile memory 300. For example, DRAM controller 140 can receive firmware image data from main NVM 200 and load the firmware image data onto main volatile memory 300. Peripheral device 120 can include devices for input and output of electronic device 10. For example, peripheral device 120 can include a display controller for controlling a display to show a pop-up window requesting user authentication information. Flash memory controller 150 can write data to or read data from main NVM 200.

[0033] The security processor 160 may include a secure central processing unit (CPU) 161, a secure ROM 162, a secure RAM 163, an encryption engine 164, a mailbox module 165, a secure flash controller 166, and a secure direct memory access (DMA) controller 167. The secure CPU 161 can perform general operations of the security processor 160 using the secure RAM 163 and secure ROM 162. For example, the secure CPU 161 may be configured to verify the digital signature of candidate firmware or check the version information of candidate firmware. The secure flash controller 166 can perform data reading or writing with the secure NVM 400. For example, when user permission is activated, the secure flash controller 166 can write user authentication information entered by the user into the secure NVM 400. The user authentication information may include the user's user ID, password (PW), and biometric data (e.g., fingerprint information, iris information, facial recognition information, voice information, or vein information). The mailbox module 165 can perform data communication between the security processor 160 and external components using a mailbox protocol. According to an embodiment of the present invention, the mailbox module 165 may include multiple registers and perform communication by receiving and classifying commands and data from external components.

[0034] Encryption engine 164 can encrypt input data using a key. According to an embodiment of the present invention, encryption engine 164 can encrypt user authentication information using a security key and store the encrypted user authentication information in secure NVM 400. According to another embodiment of the present invention, encryption engine 164 can provide at least one algorithm selected from Hash Message Authentication Code (HMAC), Rivest, Shamir, Adleman (RSA), and Elliptic Curve Digital Signature Algorithm (ECDSA) to calculate the hash value of firmware version information or verify digital signatures. Secure DMA controller 167 can be electrically connected to main volatile memory 300 external to secure processor 160. Secure DMA controller 167 can access main volatile memory 300 to read data into secure processor 160. For example, secure DMA controller 167 can read firmware data loaded on main volatile memory 300 into secure processor 160.

[0035] According to various embodiments of the present invention, the secure NVM 400 can instruct the NVM of the security processor 160 directly connected to the SoC 100. Because the secure NVM 400 communicates with the security processor 160 within the SoC 100, the secure NVM 400 can store data that will be processed by the security processor 160 and used for its security. For example, the security processor 160 can store user authentication data, main image version information, candidate image version information, etc., in the secure NVM 400.

[0036] User authentication data, main image version information, and candidate image version information can correspond to the data that the security processor 160 will use to determine whether the user of the electronic device 10 has agreed to update (or modify) to the new firmware. See below for reference. Figure 4 This will be described in detail.

[0037] The primary NVM 200 can indicate which NVMs are accessible to the primary processor 110 and the security processor 160. For example, the primary processor 110 can access the primary NVM 200 to run the bootloader 301. As another example, the security processor 160 can load data related to firmware updates by accessing the primary volatile memory 300, or it can load data related to firmware updates by directly accessing the primary NVM 200.

[0038] According to embodiments of the present invention, the main NVM 200 and the secure NVM 400 may include an NVM in which data stored even when the power is turned off will not be lost. For example, the main NVM 200 and the secure NVM 400 may include NAND flash memory, vertical NAND flash memory, NOR flash memory, resistive RAM, phase-change memory, magnetoresistive RAM, etc.

[0039] The main processor 110 and the security processor 160 can access the main volatile memory 300. For example, the main volatile memory 300 may be loaded with master firmware and booted. According to embodiments of the present invention, the main volatile memory 300 may include memory where data stored is lost when power is turned off. For example, the main volatile memory 300 may include static RAM (SRAM), dynamic RAM (DRAM), or magnetoresistive RAM. Hereinafter, the main volatile memory 300 implemented with DRAM 300 will be described.

[0040] Figure 2 It is the format of data stored in the main NVM 200 according to an example embodiment of the present invention. Figure 3 This is the format of data loaded on DRAM 300 according to an exemplary embodiment of the present invention. (Refer to...) Figure 2 and Figure 3 The primary NVM200 may include an update data region 201, a primary image region 205, and a candidate image region 206.

[0041] The update data area 201 may include information indicating which firmware is loaded to perform the boot process when the bootloader 301 is activated and the electronic device 10 begins booting. For example, the update data area 201 may include a user license indicator 202, master image location data 203, and an update indicator 204.

[0042] According to an embodiment of the present invention, the user license indicator 202 may include information indicating whether a user license is activated when the electronic device 10 is powered on and started.

[0043] In this document, user permission may instruct booting to be performed using firmware installed or distributed with the user's consent. For example, when user permission is activated, booting of electronic device 10 may fail even if any firmware loaded on DRAM 300 for booting electronic device 10 is legally distributed by the manufacturer of electronic device 10, as long as the version of the loaded firmware is different from the version of the firmware installed with the user's consent.

[0044] For example, when the user license indicator 202 is "1" or logically high, the electronic device 10 can compare the version of the firmware loaded on DRAM 300 with the version of the firmware installed with user consent during startup. As another example, when the user license indicator 202 is "0" or logically low, the electronic device 10 may not check the version of the firmware loaded on DRAM 300. For example, when the user license is deactivated, the electronic device can perform startup based on the updated firmware when the updated firmware is activated. The following will refer to... Figures 5 to 8Describes the details of User License Indicator 202.

[0045] The master image location data 203 may include information related to the storage location of the master firmware. The master image location data 203 may be implemented using pointers, or it may include the starting address of the image storing the master firmware and its digital signature, as well as the size information of the master firmware. When the electronic device 10 performs a boot, it can refer to the master image location data 203 to load the master firmware onto the DRAM 300.

[0046] According to an embodiment of the present invention, the master image location data 203 may have a changed value when a firmware update is performed. For example, because the candidate firmware may not overwrite area A, which stores the master firmware, within the storage area of ​​the master NVM 200, the candidate firmware may be stored in area B within the storage area of ​​the master NVM 200. Therefore, after the firmware update is completed, the master image location data 203 may have a changed value indicating area B.

[0047] The update indicator 204 may include information indicating whether the electronic device 10 should perform a firmware update. A firmware update may instruct a series of processes to change the previously stored master firmware to a newly distributed updated firmware.

[0048] For example, when the update indicator 204 has a value of "1" or a logical high, the update indicator 204 can indicate that firmware with a version different from the main firmware is stored in the candidate image area 206. In this document, different firmware versions can include the latest version and previous versions. As another example, when the update indicator 204 has a value of "0" or a logical low, the update indicator 204 can indicate that firmware with a version different from the main firmware is not stored in the candidate image area 206. For example, the electronic device 10 can determine whether a newly stored updated firmware exists by referring to the value of the update indicator 204.

[0049] According to various embodiments of the present invention, the main image region 205 may correspond to the region where the main firmware data is stored, and the candidate image region 206 may correspond to the region where the candidate firmware data is stored. Each piece of firmware data can be identified by an image body and a digital signature. The digital signature can indicate information used to ensure that the corresponding firmware was distributed by the manufacturer and has not been tampered with. See also... Figure 3The SoC 100 can load the boot loader 301 onto the DRAM 300. The boot loader 301 can instruct a program or instruction configured to perform the boot of the electronic device 10. Alternatively or additionally, the boot loader 301 can instruct a program or instruction set configured to perform some or all of the tasks required for the proper boot of the kernel and to boot the OS 302 by being pre-executed before booting the operating system (OS) 302.

[0050] although Figure 3 The boot loader 301 is shown as a single boot loader, but the boot loader 301 is not limited thereto. According to various embodiments of the present invention, the boot loader 301 may have a hierarchical structure. For example, the boot loader 301 may include stage 1 and stage 2, and may also include stage 1.5. When the boot loader 301 has a hierarchical structure, the stages therein may be executed sequentially.

[0051] SoC 100 can load host application 303 onto DRAM 300. Host application 303 may correspond to a program or instructions that will be executed by main processor 110. Host application 303 can run independently of OS 302. For example, host application 303 can run normally even before OS 302 is started.

[0052] Figure 4 It is the format of data stored in a secure NVM 400 according to an example embodiment of the present invention.

[0053] Reference Figure 4 The secure NVM 400 may include user authentication data 401, main image version information 405, and candidate image version information 406.

[0054] User authentication data 401 may include information related to user authentication. For example, user authentication data 401 may include user authentication information 402, user license indicator 202, and authentication status information 404.

[0055] The description of the user license indicator 202 included in user authentication data 401 is referenced. Figure 2 The process is omitted here.

[0056] User authentication information 402 can be generated when user authentication is initially activated and stored in the secure NVM 400. For example, user authentication information 402 can be information entered by the user of electronic device 10 when user authentication is initially activated. Subsequently, when a firmware update is performed, electronic device 10 can authenticate whether the user is an authorized user. User authentication information 402 can include a combination of random characters, numbers, symbols, etc. Alternatively or additionally, user authentication information 402 may also include the user's biometric data (e.g., fingerprint information, iris information, facial recognition information, voice information, or vein information).

[0057] The authentication status information 404 may include information indicating the user authentication result. When new firmware is installed after activating user license, the electronic device 10 may control the display controller in the peripheral device 120 to display a pop-up window on the display requesting user authentication information. For example, user authentication information 402 stored in the secure NVM 400 may be used to verify the user authentication information entered through the pop-up window. When verification is successful, the user is an authorized user. Therefore, the authentication status information 404 may have a value of "1" or a logical high. As another example, when verification fails, the user is not an authorized user. Therefore, user authentication fails, and the authentication status information 404 may have a value of "0" or a logical low.

[0058] The master image version information 405 may include the version information of the master firmware. This version information is not limited to information indicating the firmware version as officially named by the manufacturer, and may include various types of information that can identify the master firmware.

[0059] For example, the master image version information 405 may include a hash value of the master firmware. Since the hash value can vary due to very small data differences between the master firmware and the random firmware, it can serve as proof of the master firmware. As another example, the master image version information 405 may include a digital signature value of the master firmware. The digital signature can be generated based on at least one of the algorithms HMAC, RSA, and ECDSA. However, the master image version information 405 is not limited to a hash value or a digital signature value, and may include some or all of the values ​​that can prove the firmware.

[0060] Candidate image version information 406 may include version information of the candidate firmware. Similar to the main image version information 405, candidate image version information 406 may include the hash value and / or digital signature value of the candidate firmware.

[0061] In various embodiments of the present invention, the size of the version information of the main firmware and / or candidate firmware can be variable. The size of the version information can be determined based on the security level of the security processor 160. For example, when the security level of the security processor 160 is higher than a threshold level, the main image version information 405 and / or candidate image version information 406 may include hash values ​​obtained by using a hash function with a long digest (e.g., SHA-512). The digest may indicate the output of the hash function and may correspond to the length of the output bits. As another example, when the security level of the security processor 160 is lower than a threshold level, the main image version information 405 and / or candidate image version information 406 may include hash values ​​obtained by using a hash function with a short digest (e.g., SHA-256).

[0062] Figure 5 This is a flowchart of the operation sequence of electronic device 10 when user permission is deactivated, according to an example embodiment of the present invention.

[0063] Reference Figure 5 In operation S110, the electronic device 10 can activate the boot loader 301. In response to the power-on of the electronic device 10, the boot loader 301 can be loaded onto the DRAM 300 to execute the boot sequence, and the host application 303 can be driven.

[0064] In operation S120, electronic device 10 can determine whether the update indicator value has a specific logical value (e.g., "1" or a logical high value). For example, update indicator 204 can indicate whether a new candidate firmware has been stored. Host application 303 of electronic device 10 can identify the update indicator value by loading update data area 201 stored in the host NVM 200.

[0065] In operation S130, electronic device 10 can load the main firmware onto DRAM 300. When the update indicator value is "0" or logic low in operation S120, there are no candidate firmwares other than the main firmware for firmware update. Therefore, the main firmware is loaded to start the previously installed main firmware.

[0066] According to various embodiments of the present invention, when operation S130 is performed, the data is as follows.

[0067]

[0068] Table 1

[0069] In operation S140, electronic device 10 can verify the digital signature of the main firmware. The digital signature can be used to verify whether the firmware was distributed by an authorized distributor (e.g., the manufacturer of electronic device 10) and has not been tampered with. The security processor 160, which starts in operation S130, can perform signature verification based on the digital signature included in the main firmware.

[0070] In operation S150, electronic device 10 can run the main firmware. After verifying the digital signature, security processor 160 can run the main firmware. When user license is activated, the version information of the firmware to be run should be checked, but the user license is not activated. Therefore, the process of checking the firmware version information can be skipped or bypassed.

[0071] In operation S160, the electronic device 10 can load candidate firmware onto DRAM 300. When the update indicator value is "1" or logic high in operation S120, the host application 303 can recognize the existence of candidate firmware for firmware update to replace the main firmware. Therefore, the host application 303 can load the candidate firmware to start the candidate firmware instead of the main firmware.

[0072] According to various embodiments of the present invention, when operation S160 is performed, the data is as follows.

[0073]

[0074] Table 2

[0075] In operation S170, the electronic device 10 can verify the digital signature of the candidate firmware. The description of the digital signature verification is the same as that of operation S140, and is omitted here.

[0076] In operation S180, the electronic device 10 can run candidate firmware. After verifying the digital signature, the security processor 160 can run the candidate firmware. When user permission is activated, the version information of the candidate firmware to be run is checked. However, if user permission is not activated, the process of checking the firmware version information can be skipped.

[0077] In operation S190, electronic device 10 can modify the information in update data area 201. For example, when distributing (or receiving) candidate firmware while the main firmware is stored in area A of the main NVM 200, the candidate firmware can be stored in area B of the main NVM 200. Since the boot using the candidate firmware was successful in operation S180, the host application 303 of electronic device 10 can change the main image location data 203 from area A to area B so that the candidate firmware can be booted when booting is performed later. For example, when booting using the candidate firmware is completed, the information can be changed to identify the candidate firmware as the main firmware. Alternatively or alternatively, the host application 303 can delete the existing main firmware stored in area A and change the value of update indicator 204 to "0" or logical low because the new candidate firmware has not yet been stored in area A. When the value of update indicator 204 is not changed, an erroneous operation may occur because a new firmware update is considered when booting is performed.

[0078] In some cases, the master firmware stored in region A is deleted, and host application 303 changes the value of update indicator 204 to "0" or logical low in response to the deletion of the master firmware. However, this embodiment is not limited to this. When host application 303 changes the value of update indicator 204 to "0" or logical low and changes master image location data 203 from region A to region B, host application 303 can bypass the deletion of the master firmware stored in region A. Because the update indicator value and master image location data 203 have changed, host application 303 does not perform booting by using the existing master firmware stored in region A. When new firmware is received, host application 303 can overwrite the existing master firmware stored in region A.

[0079] According to various embodiments of the present invention, when operation S190 is performed, the data is as follows.

[0080]

[0081]

[0082] Table 3

[0083] Figure 6 This is a flowchart of an operation sequence for activating a user-licensed electronic device 10, according to an exemplary embodiment of the present invention.

[0084] Reference Figure 6In operation S210, the electronic device 10 can perform primary booting. In this document, primary booting can refer to booting before user permission is activated. For example, primary booting can refer to the user initially booting the electronic device 10 shipped from the manufacturer. Therefore, completion of primary booting can indicate the execution of... Figure 5 The operation. For example, in operation S210, the user license is deactivated, and the main firmware can be the firmware used when manufacturing the electronic device 10 (factory initialization firmware), or it can be one of the firmwares that are separately distributed by the manufacturer after the electronic device 10 is manufactured.

[0085] According to various embodiments of the present invention, when operation S210 is performed, the data is as follows.

[0086]

[0087] Table 4

[0088] In operation S220, electronic device 10 can receive user input for activating user license. For example, when performing a firmware update, electronic device 10 can display a pop-up window on the display in peripheral device 120, including visual notifications such as "Do you want to pause automatic firmware updates?" or "Do you want to perform a firmware update with user consent?". Alternatively, the user can directly activate the user license by accessing a menu that allows activation of user license.

[0089] In operation S230, electronic device 10 can receive user authentication information and store it in the secure NVM 400. The user authentication information may be related to the above references. Figure 4 The description includes the user ID and user password information.

[0090] In certain situations, the host application 303 of the electronic device 10 may display a pop-up window requesting user authentication information to activate user authorization. For example, the pop-up window may display areas for entering the user ID and PW, or display guidance information for obtaining biometric information. The host application 303 may send the entered user authentication information to the security processor 160. By sending the user authentication information to the security processor 160 and storing it in the secure NVM 400, firmware updates to be performed by the security processor 160 can be executed based on user authentication information stored in the secure NVM 400 connected to the security processor 160, rather than on unreliable user authentication information stored externally to the electronic device 10. Therefore, the security and reliability of firmware updates performed by the security processor 160 can be increased.

[0091] In operation S240, the electronic device 10 can change the value of the user license indicator 202. For example, since the value of the user license indicator 202 is "0" or logical low before the user activates the user license, the value of the user license indicator 202 can be changed to "1" or logical high. By changing the value of the user license indicator 202, the host application 303 of the electronic device 10 can perform user license operations when a firmware update is subsequently performed.

[0092] In operation S250, electronic device 10 can generate version information of the main firmware and store this version information in the secure NVM 400. Before user license is activated, it is optional to check whether the firmware version licensed by the user has been booted. Therefore, the version information of the main firmware may not be generated or stored. However, when user license is activated, it is possible to check whether the firmware corresponding to the user-licensed firmware has been booted. Therefore, the version information of the main firmware (i.e., the firmware loaded when user license is activated) can be generated and stored. The version information of the main firmware can correspond to... Figure 4 The main image version information is 405.

[0093] Specifically, the security processor 160 can generate master image version information 405 and store it in the secure NVM 400. Therefore, information used to determine whether the firmware is a user-approved version can be used as master image version information 405, which is stored in the secure NVM 400, connected to the security processor 160, rather than externally on the electronic device 10. This improves the security and reliability of the boot process executed by the security processor 160.

[0094] According to various embodiments of the present invention, when in Figure 6 When a user license is activated, the data is as follows.

[0095]

[0096] Table 5

[0097] Figure 7 This is a flowchart illustrating the operation sequence of an electronic device 10 that is started by using the main firmware when a user license is activated, according to an example embodiment of the present invention.

[0098] Reference Figure 7 In operation S310, electronic device 10 can perform a secondary startup. In this document, a secondary startup can be indicated in... Figure 6 Launch after the user license is activated.

[0099] According to various embodiments of the present invention, when the second startup of operation S310 is performed, the data is as follows.

[0100]

[0101]

[0102] Table 6

[0103] In operation S320, electronic device 10 can recognize that the update indicator value is logic low. Host application 303 of electronic device 10 can load the update data area 201 stored in the main NVM 200, recognize that the update indicator 204 value is "0" or logic low, and determine that there is no candidate firmware for performing a firmware update. Host application 303 can recognize that a user license is activated based on the user license indicator 202 stored in the main NVM 200, but may not perform a firmware update. Therefore, host application 303 can perform boot by loading the main firmware onto DRAM 300.

[0104] In operation S330, electronic device 10 can boot security processor 160 using main firmware. The description of operation S330 is consistent with... Figure 5 The description of operation S130 is the same, and is omitted here.

[0105] In operation S340, electronic device 10 can verify the digital signature of the main firmware. The description of operation S340 is as follows: Figure 5 The description of operation S140 is the same and is omitted here.

[0106] In operation S350, electronic device 10 can recognize that the value of user license indicator 202 is logic high. Security processor 160 of electronic device 10 can determine that user license is activated based on the value of user license indicator 202 stored in secure NVM 400. When user license is activated, security processor 160 can determine whether the digital signature of the main firmware has been verified, and whether the firmware loaded on secure RAM 163 matches the firmware version licensed by the user.

[0107] In operation S360, the electronic device 10 can compare the master image version information 405 stored in the secure NVM 400 with the version information of the loaded firmware. For example, the secure processor 160 can generate test version information of the firmware loaded on the secure RAM 163 to determine whether the loaded firmware is the same as the version of firmware licensed by the user. The test version information can be generated by performing calculations on the firmware loaded on the secure RAM 163 based on the same function used to generate the master image version information 405. For example, when the master image version information 405 is generated based on SHA-512 in the hash function, the secure processor 160 can perform calculations on the firmware loaded on the secure RAM 163 using the hash function SHA-512.

[0108] When the two version information entries differ, the firmware currently loaded on secure RAM 163 is not the user-approved version. Therefore, booting will fail, and the operation sequence will end.

[0109] In operation S370, electronic device 10 can run the main firmware. When the two version information matches in operation S360, the main firmware currently loaded on secure RAM 163 is the user-licensed version of firmware. Therefore, secure processor 160 can boot by running the main firmware.

[0110] Figure 8 This is a flowchart of the operation sequence of an electronic device 10 that performs a firmware update by using candidate firmware when a user license is activated, according to an example embodiment of the present invention.

[0111] Reference Figure 8 During operation S410, electronic device 10 can activate user license. The user license activation process can be indicated as complete. Figure 6 Operations S210 to S250.

[0112] In operation S420, electronic device 10 can recognize that the update indicator value is logical high. For example, electronic device 10 can receive candidate firmware distributed from the manufacturer and store the received candidate firmware in the main NVM 200. When the candidate firmware is received, the host application 303 of electronic device 10 changes the update indicator 204 to "1" or logical high. Therefore, the host application 303 can recognize that a firmware update should be performed during the startup process based on the value of the update indicator 204.

[0113] According to various embodiments of the present invention, when operation S420 is performed, the data is as follows.

[0114]

[0115]

[0116] Table 7

[0117] In operation S430, electronic device 10 can boot security processor 160 using master firmware. Booting is performed using master firmware to obtain user consent for firmware updates when the value of update indicator 204 is identified as logical high. For example, authentication status information 404 can be "0" or fail (FAIL) when the value of update indicator 204 is identified. Therefore, host application 303 can boot security processor 160 using existing master firmware.

[0118] In operation S440, electronic device 10 can successfully boot by using the main firmware. In this document, successful booting of operation S440 can be related to the execution of... Figure 7 The operations S340 to S370 are the same. For example, since the user license is activated, those skilled in the art will understand that the main firmware can be run by verifying the digital signature of the main firmware and checking whether the main firmware is the same as the version of firmware licensed by the user.

[0119] In operation S450, electronic device 10 can perform user authentication. Electronic device 10 can display a pop-up window on a display within peripheral device 120 requesting the user to enter a user ID and user password. Alternatively, electronic device 10 can display a pop-up window guiding the input of biometric data.

[0120] Host application 303 can send the input user authentication information to security processor 160. Security processor 160 can verify whether the user authentication information received from host application 303 is authorized user authentication information by using user authentication data 401 pre-stored in secure NVM 400. When the user authentication information received from host application 303 passes verification, the user is an authorized user. Therefore, user authentication is successful. According to various embodiments of the present invention, when verification fails, the authentication status information 404 may not be changed.

[0121] In operation S460, the electronic device 10 can change the value of the authentication status information 404 and generate and store candidate firmware version information. When user authentication is successful, the security processor 160 can change the authentication status information 404 to "1" or PASS to reflect successful user authentication.

[0122] Next, the security processor 160 can generate version information for candidate firmware. The version information of the candidate firmware can correspond to... Figure 4Candidate image version information 406. The security processor 160 can generate candidate image version information 406 and store it in the secure NVM 400 to indicate to the user that they agree to a firmware update with the candidate firmware when a reboot is performed.

[0123] According to various embodiments of the present invention, when operation S460 is performed, the data is as follows.

[0124]

[0125] Table 8

[0126] In operation S470, electronic device 10 can reboot security processor 160. Because booting is performed using the existing master firmware to obtain user permission, security processor 160 can be rebooted to perform a firmware update using candidate firmware.

[0127] In operation S480, the electronic device 10 can recognize the modified authentication status information 404. The security processor 160 can recognize the user license indicator 202 and the authentication status information 404 during a reboot. Because user license is activated, the user license indicator 202 is "1" or logically high, so the security processor 160 can refer to the authentication status information 404 to determine whether user authentication has been completed. Because the authentication status information 404 has been successfully modified based on user authentication in operation S460, the security processor 160 can recognize the candidate firmware version that has been user-licensed. Therefore, in operation S490, the security processor 160 can load the candidate firmware onto the secure RAM 163. Those skilled in the art will understand that verifying the digital signature after loading the candidate firmware onto the secure RAM 163 is omitted.

[0128] In operation S500, the electronic device 10 can determine whether the candidate image version information 406 stored in the secure NVM 400 is the same as the version information loaded on the DRAM 300. The detailed description of comparing these two versions is the same as that of operation S360 and is omitted here. The version information to be compared in operation S500 can be the version information of candidate firmware. For example, the secure processor 160 can determine whether the firmware currently loaded on the secure RAM 163 is the same as the candidate firmware authorized for updating during user authentication in operation S450.

[0129] In operation S510, the electronic device 10 can change the main image version information 405, the candidate image version information 406, the update indicator 204, the main image location data 203, and the authentication status information 404.

[0130] When the comparison results in operation S500 are the same, the security processor 160 can determine that the firmware loaded on DRAM 300 is the same as the candidate firmware authorized by the user, and complete the boot based on the candidate firmware. Because the firmware update has been completed, the electronic device 10 can change the main image version information 405, update indicator 204, main image location data 203, and authentication status information 404 to prevent erroneous firmware update operations during boot.

[0131] According to various embodiments of the present invention, since the existing candidate firmware becomes the new master firmware after the firmware update is completed, the security processor 160 can modify the image version information. Because the firmware update is complete, the security processor 160 can replace the master image version information 405 with the existing candidate image version information 406 and delete the existing candidate image version information 406. By overwriting the master image version information 405 with the existing candidate image version information 406, the new master firmware can be authenticated as the latest version of firmware licensed by the user during subsequent boot processes.

[0132] Alternatively, the security processor 160 may change the authentication status information 404 back to "0" or FAIL. When the authentication status information 404 is not changed, an unwanted firmware update may be performed because the authentication status information 404 remains PASS even if the user does not permit the update to the new candidate firmware during the firmware update process.

[0133] The main processor 110 can change the value of the update indicator 204. Since the firmware update is complete, the main processor 110 can change the value of the update indicator 204 back to "0" or logical low. If the value of the update indicator 204 is not changed, an error may occur even if the firmware update is complete, indicating that a new firmware update exists during startup.

[0134] The main processor 110 can modify the main image location data 203. Because the region storing the existing candidate firmware is region B of the main NVM 200, the main image location data 203 can be changed to indicate region B. When the main image location data 203 is not modified, it might attempt to boot from region A, which stores the main firmware prior to the firmware update. As a result, booting might fail because the firmware version information in region A differs from the modified main image version information 405.

[0135] According to various embodiments of the present invention, when operation S510 is performed, the data is as follows.

[0136]

[0137] Table 9

[0138] In operation S520, electronic device 10 can delete candidate firmware. When the version information does not match in operation S500, the candidate firmware is not user-approved firmware. Therefore, the candidate firmware can be deleted, and booting can be performed using the existing main firmware.

[0139] Therefore, according to another aspect of the present invention, a method for updating firmware is provided, the method comprising: receiving a firmware update for firmware of an electronic device; identifying a user license indicator indicating that user consent is required before updating the firmware; obtaining consent to update the firmware based on the user license indicator; and updating the firmware based on consent to use the firmware update.

[0140] In some cases, the method further includes: performing user authentication; receiving user input for activating a user license mode; and setting a user license indicator based on user authentication and user input. In some cases, the method further includes: storing candidate versions of firmware based on firmware updates; and setting an update indicator based on receiving a firmware update, wherein consent is obtained based on the update indicator.

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

[0142] Although the inventive concept has been specifically shown and described with reference to embodiments thereof, it should be understood that various changes in form and detail may be made herein without departing from the spirit and scope of the appended claims.

Claims

1. An electronic device, comprising: A non-volatile memory stores first firmware and a user license indicator, the user license indicator indicating whether to perform a comparison between the installed firmware version and the firmware version installed with user consent. A main processor configured to load the first firmware to start a security processor, and configured to activate an update indicator when a second firmware is stored in main non-volatile memory, wherein the second firmware is different from the first firmware; and A secure non-volatile memory, the secure non-volatile memory containing first version information, wherein the first version information is the version information of firmware installed with the user's consent; The security processor is configured as follows: The user authorization indicator is activated in response to receiving user authentication information including a user identifier and a password, and the user authentication information is stored in the secure non-volatile memory; The user is verified using the stored user authentication information; When the user license indicator is activated, first version information including the hash value of the first firmware that is running is generated and stored; When the update indicator is deactivated, startup is performed by loading the first firmware; When the user license indicator is activated, the version information of the loaded first firmware is compared with the first version information; and In response to a match in the comparison, the loaded first firmware is executed, and The security processor and the main processor are implemented on the same chip.

2. The electronic device according to claim 1, wherein, The security processor is also configured to: In response to the activation of the user permission indicator, the received user identifier and password are stored in the secure non-volatile memory; Generate a hash value for the first firmware that runs when the user license indicator is activated; as well as The generated hash value is stored as the first version information.

3. The electronic device according to claim 2, wherein, The non-volatile memory is also configured to store a second firmware different from the first firmware and an update indicator indicating that the second firmware is stored.

4. The electronic device according to claim 3, wherein, The main processor is also configured to: The activation of the update indicator is identified; The security processor is started by using the first firmware; In response to the activation of the update indicator, the user is requested to perform user authentication; as well as The user input received in response to the request is sent to the security processor as user authentication information.

5. The electronic device according to claim 4, wherein, The security processor is also configured to: User authentication is performed by comparing the received user authentication information with user authentication data pre-stored in the secure non-volatile memory; as well as When the comparison result is a match, an identifier for the second firmware is generated, the generated identifier is stored as second version information, and the authentication status information indicating the result of the user authentication is activated.

6. The electronic device according to claim 5, wherein, The security processor is also configured to: In response to the activation of the authentication status information, the second firmware is loaded; Generate an identifier for the loaded second firmware and compare the generated identifier with the second version information; as well as When the comparison result is a match, the second firmware is run.

7. The electronic device according to claim 6, wherein, The security processor is also configured to: In response to the operation of the second firmware, the update indicator is deactivated; The identifier of the second firmware is stored as the first version information; Delete the second version information; as well as Deactivate the authentication status information.

8. The electronic device according to claim 6, wherein, The main processor is also configured to: The comparison result was identified as a mismatch; and Deactivate the update indicator.

9. The electronic device according to claim 1, wherein, The non-volatile memory is also configured to store a second firmware different from the first firmware and an update indicator indicating that the second firmware is stored; and The main processor is also configured to: Identify the deactivation of the user license indicator; In response to the identification, the comparison between the version information of the first firmware and the first version information is bypassed; as well as The security processor is started according to the second firmware.

10. A method of operating an electronic device, the method comprising: In response to receiving user authentication information including a user identifier and a password, a user permission indicator is activated, and the user authentication information is stored in a secure non-volatile memory; Verify the user using the stored user authentication information; When the user license indicator is activated, first version information, including the hash value of the first firmware currently in operation, is generated and stored; When the update indicator is deactivated, startup is performed by loading the first firmware; When the second firmware is stored, the update indicator is activated; the second firmware is different from the first firmware. When the user license indicator is activated, the version information of the loaded first firmware is compared with the first version information; as well as When the comparison result is a match, the loaded first firmware is executed.

11. The operating method according to claim 10, further comprising: In response to the activation of the user permission indicator, the received user identifier and password are stored as user authentication information; Store a second firmware that is different from the first firmware; as well as The activation indicator stores the update indicator for the second firmware. The first version information corresponds to the identifier of the first firmware that runs when the user license indicator is activated.

12. The operating method according to claim 11, further comprising: The activation of the update indicator is identified; In response to the activation that recognizes the update indicator, the security processor is started according to the first firmware; Displays the user input required for authentication; The user authentication is performed by comparing the user input received in response to the request with the user authentication information; When the comparison result is a match, an identifier for the second firmware is generated, and the generated identifier is stored as second version information; as well as Activate authentication status information indicating the result of the user authentication.

13. The operating method according to claim 12, further comprising: The activation of the authentication status information is identified; In response to the identification, the second firmware is loaded; Generate an identifier for the loaded second firmware, and compare the generated identifier with the second version information. When the comparison result is a match, the second firmware is run.

14. The operating method according to claim 13, further comprising: Deactivate the update indicator; The identifier of the second firmware is stored as the first version information, and the second version information is deleted; as well as Deactivate the authentication status information.

15. The operating method according to claim 13, further comprising: When the comparison result is a mismatch, the update indicator is deactivated.

16. The operating method according to claim 10, further comprising: Store a second firmware that is different from the first firmware; The activation indicator stores the update indicator for the second firmware; Identify the deactivation of the user license indicator; as well as In response to the identification, the comparison between the version information of the first firmware and the first version information is bypassed, and the security processor is started according to the second firmware.

17. An electronic device comprising: A non-volatile memory that stores a first firmware, a second firmware, and an update indicator indicating that the second firmware is stored; A main processor configured to load the first firmware when the update indicator is deactivated, and to load the second firmware when the update indicator is activated; as well as A security processor configured to: verify the digital signature of the first firmware when loading the first firmware, and run the first firmware in response to successful verification of the digital signature of the first firmware; or verify the digital signature of the second firmware when loading the second firmware, and run the second firmware in response to successful verification of the digital signature of the second firmware. The security processor and the main processor are implemented on the same chip. The main processor is further configured as follows: Receive user input for activating user license; In response to the receipt, a user license indicator is activated, indicating whether to perform a comparison between the installed firmware version and the firmware version installed with the user's consent; The user license indicator is stored in the non-volatile memory; The received user input is sent as user authentication information to the security processor so that the user authentication information is stored in secure non-volatile memory; Calculate the identifier of the firmware that runs when the user input is received; The calculated identifier is generated as first version information, wherein the first version information is the version information of the firmware installed with the user's consent; and The first version information is sent to the secure non-volatile memory. The main processor is further configured to load the first firmware in response to the deactivation of the update indicator; and The security processor is also configured to: Based on the activation of the user license indicator, the identifier of the loaded first firmware is obtained; Compare the obtained identifier with the first version information; and In response to a match in the comparison, the first firmware is run. The main processor is further configured to load the first firmware in response to activation of the update indicator, and The security processor is also configured to: Receive user input for performing user authentication; The received user input is verified based on the user authentication information; When the verification is successful, the identifier of the second firmware is obtained; The obtained identifier is stored as a second version of information in the secure non-volatile memory; Load the second firmware; Obtain the identifier of the loaded second firmware; Compare the obtained identifier with the second version information; and When the comparison result is a match, the second firmware is run.

Images