storage device

Abstract

A storage device is provided. The storage device includes: a boot ROM storing a plurality of public keys and a boot ROM image; an OTP memory identifying a first public key among the plurality of public keys; a first memory including a first region and a second region, the first region storing the plurality of public keys and a flash boot image different from the boot ROM image, and the second region storing a first boot signature corresponding to the flash boot image; a second memory including a first firmware image containing a first firmware signature; and a memory controller receiving a second firmware image including a second firmware signature and a second boot signature, receiving the second public key and the flash boot image among the plurality of public keys based on the receipt of the second firmware image, and writing the second boot signature into the second region of the first memory.

Description

[0001] Cross-references to related applications

[0002] This application is based on and claims priority and all rights to Korean Patent Application No. 10-2020-0106697, filed on August 25, 2020, with the Korean Intellectual Property Office, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure relates to a storage device. Background Technology

[0004] As electronic device hardware has become increasingly diverse, operating systems (OS) have also been developed. However, despite the recent implementations of operating systems that offer a wide range of functions and execute various applications, there is a problem of excessively increased required size due to the complexity of these functions. Therefore, executing the kernel simultaneously with booting and running the operating system takes a significant amount of time.

[0005] To address this issue, electronic devices such as smartphones, personal digital assistant (PDA) devices, mobile devices, and internet-connected appliances have recently adopted systems based on embedded operating systems. These systems store the operating system on a separate chip and are integrated into the electronic device, rather than reading the operating system from a disk as is the case with desktop computers. Summary of the Invention

[0006] This disclosure provides a storage device.

[0007] According to one aspect of this disclosure, a storage device is provided, comprising: a boot read-only memory (ROM) configured to store a plurality of public keys and a boot ROM image; a once-programmable (OTP) memory configured to identify a first public key among the plurality of public keys; a first memory including a first region and a second region, the first region being configured to store the plurality of public keys and a flash boot image different from the boot ROM image, the second region being configured to store a first boot signature corresponding to the flash boot image; a second memory including a user data region and a firmware image region, the firmware image region being configured to store a first firmware image including the first firmware signature; and a memory controller configured to: receive a second firmware image, the second firmware image including a second firmware signature different from the first firmware signature and a second boot signature different from the first boot signature, receive the second public key and the flash boot image from the first region of the first memory based on the receipt of the second firmware image, and write the second boot signature into the second region of the first memory.

[0008] According to another aspect of this disclosure, a storage device is provided, comprising: a boot read-only memory (ROM) configured to store a plurality of public keys and a boot ROM image; a once-programmable (OTP) memory configured to identify a first public key among the plurality of public keys; a first memory including a first region and a second region, the first region being configured to store the plurality of public keys and a flash boot image different from the boot ROM image, the second region being configured to store a first boot signature corresponding to the flash boot image, the second region being different from the first region; a second memory including a user data region and a firmware image region, the firmware image region being configured to store a first firmware image including the first firmware signature; and a memory controller configured to: receive a second firmware image, the second firmware image including a second firmware signature different from the first firmware signature, and write the second firmware image into the firmware image region based on the receipt of the second firmware image, wherein the first region of the first memory is readable only by the memory controller, and the second region of the first memory is readable and writable by the memory controller.

[0009] According to another aspect of this disclosure, a storage device is provided, comprising: a boot read-only memory (ROM) storing a plurality of public keys and a boot ROM image; a once-programmable (OTP) memory configured to identify a first public key among the plurality of public keys; a first memory including a first region and a second region, the first region being configured to store the plurality of public keys and a flash boot image different from the boot ROM image, the second region being configured to store a first boot signature corresponding to the flash boot image and different from the first region; and a second memory including a user data region and a firmware image region, the firmware image region being configured to store a first firmware image, the first firmware image... The system includes a first firmware signature generated based on a first private key corresponding to a first public key; and a memory controller configured to: receive a second firmware image, the second firmware image including a second firmware signature different from the first firmware signature and a second boot signature different from the first boot signature; write the second boot signature into a second region of a first memory based on the receipt of the second firmware image; and write data into an OTP memory such that the OTP memory recognizes a second public key among a plurality of public keys that is different from the first public key, and deletes the first boot signature stored in the second region of the first memory, wherein the second firmware signature is generated based on a second private key corresponding to the second public key and the second firmware image.

[0010] According to another aspect of this disclosure, a method is provided, comprising: storing a plurality of public keys and a boot read-only memory (ROM) image in a boot ROM; storing a plurality of public keys and a flash boot image different from the boot ROM image in a first region of a first memory; storing a first boot signature corresponding to the flash boot image in a second region of the first memory; storing a first firmware image including a first firmware signature in a second memory; receiving a second firmware image, the second firmware image including a second firmware signature different from the first firmware signature and a second boot signature different from the first boot signature; receiving a second public key and a flash boot image from the first region of the first memory based on the receipt of the second firmware image; and writing the second boot signature into the second region of the first memory.

[0011] However, the aspects of this disclosure are not limited to those set forth herein. These and other aspects of the disclosure will become more apparent to those skilled in the art upon reference to the following detailed description of the disclosure. Attached Figure Description

[0012] The above and other aspects and features of this disclosure will become more apparent from the detailed description of exemplary embodiments thereof with reference to the accompanying drawings, in which:

[0013] Figure 1 This is a block diagram illustrating a memory system for illustrating a semiconductor memory device according to an exemplary embodiment;

[0014] Figure 2 It is used for explanation Figure 1 A block diagram of a storage device;

[0015] Figure 3 It is used for explanation Figure 2 A diagram illustrating the boot process of a storage device;

[0016] Figure 4 This is a block diagram illustrating a method for updating a storage device according to an exemplary embodiment;

[0017] Figure 5 This is a flowchart illustrating a method for updating a storage device according to an exemplary embodiment;

[0018] Figure 6 It is used to explain the basis Figure 5 A block diagram of a method for updating a storage device;

[0019] Figure 7 It is used for explanation Figure 5 A block diagram of the new firmware image;

[0020] Figure 8 It is used for explanation Figure 5 A block diagram of the S70 operation;

[0021] Figure 9 It is used for explanation Figure 5 A block diagram of the operation S72;

[0022] Figure 10 This is a flowchart illustrating a method for updating a storage device according to an exemplary embodiment;

[0023] Figure 11 It is used for explanation Figure 10 A block diagram of the S82 operation;

[0024] Figure 12 It is used for explanation Figure 10 A block diagram of the S82 operation;

[0025] Figure 13 It is used for explanation Figure 10 A block diagram of the S82 operation;

[0026] Figure 14 It is used for explanation Figure 10 A block diagram of the S82 operation;

[0027] Figure 15 This is a flowchart illustrating a method for updating a storage device according to an exemplary embodiment; and

[0028] Figure 16 It is used for explanation Figure 15 The block diagrams for operations S92 and S94 are shown. Detailed Implementation

[0029] Figure 1 This is a block diagram used to illustrate a memory system for a semiconductor memory device according to an exemplary embodiment.

[0030] Reference Figure 1 The semiconductor memory system according to an exemplary embodiment includes a host device 100 and a storage device 200.

[0031] The host device 100 can send data and commands such as read, write, and erase to the storage device 200. The storage device 200 can read, write, or erase data in response to commands sent from the host device 100.

[0032] The host device 100 can be implemented as a PC (personal computer), laptop computer, mobile phone, smartphone, tablet PC, PDA (personal digital assistant), EDA (enterprise digital assistant), digital camera, PMP (portable multimedia player), PND (portable navigation device), MP3 player or e-book.

[0033] The host device 100 may include a central processing unit (CPU) 110, a ROM (read-only memory) 120, a RAM (random access memory) 130, and a memory interface (I / F) 140.

[0034] The central processing unit 110 can execute operating programs stored in or existing in ROM 120 or RAM 130. The central processing unit 110 can execute and control programs stored in ROM 120, RAM 130, or storage device 200. The central processing unit 110 can control the overall operation of the host device 100.

[0035] ROM 120 can store data required to start host device 100. RAM 130 can be used as main memory or cache memory of host device 100, or can temporarily store data to be provided to storage device 200.

[0036] RAM 130 may be, for example, dynamic random access memory, such as DRAM (Dynamic Random Access Memory), SDRAM (Synchronous DRAM), DDR SDRAM (Double Data Rate SDRAM), LPDDR SDRAM (Low Power Double Data Rate SDRAM), GDDR SDRAM (Graphics Double Data Rate SDRAM), DDR2 SDRAM, DDR3 SDRAM, and DDR4 SDRAM or SRAM. However, this disclosure is not limited thereto, and therefore, according to another example embodiment, RAM may include other types of memory.

[0037] Host device 100 and storage device 200 can send and receive data via memory interface 140. Memory interface 140 can be UFS (Universal Flash Storage), SCSI (Small Computer System Interface), SAS (Serial Attached SCSI), SATA (Serial Advanced Technology Attachment), PCIe (Peripheral Component Interconnect), eMMC (Embedded Multimedia Card), FC (Fire Channel), ATA (Advanced Technology Attachment), IDE (Integrated Drive Electronics), USB (Universal Serial Bus), IEEE 1394 (FireWire), etc. Alternatively, memory interface 140 can be any interface that allows host device 100 and storage device 200 to send and receive data. However, this disclosure is not limited thereto, and therefore, according to another example embodiment, the memory interface may include other types of interfaces.

[0038] Storage device 200 can be a non-volatile data storage medium in which data can be input and erased upon power-on. Storage device 200 can be an SSD (Solid State Drive), memory card (flash memory card), multimedia card (MMC), USB flash drive, smart media, compact flash memory, memory stick, SD card (Secure Digital Card), universal flash memory (UFS), etc. However, this disclosure is not limited thereto, and therefore, according to another example embodiment, the storage device may include other types of storage devices.

[0039] The system bus 105 can be connected between the central processing unit 110, ROM 120, RAM 130 and memory interface 140.

[0040] Figure 2 It is used for explanation Figure 1 A block diagram of the storage device.

[0041] Reference Figure 2 The storage device 200 according to the exemplary embodiment may include a system bus 205, a memory controller 210, an OTP memory 220, a boot ROM 230, a first memory (memory 1) 260 and a second memory (memory 2) 270.

[0042] The memory controller 210 can control the overall operation of the OTP memory 220, the boot ROM 230, the first memory 260, and the second memory 270. For example, the memory controller 210 can receive data, addresses, and commands from the host device 100 and control the operation of the second memory 270 in response to them.

[0043] OTP memory (single-time programmable memory) 220 can recognize the public key used during startup. For example, OTP memory 220 can recognize one of a plurality of public keys 235 stored in boot ROM 230. OTP memory 220 can also recognize one of a plurality of public keys stored in a first region 240 of first memory 260. That is, OTP memory 220 can recognize the addresses of public keys 235 and 245. Memory controller 210 can use the public keys 235 and 245 recognized by OTP memory 220 to boot storage device 200.

[0044] The boot ROM 230 may include a boot ROM image 232. The boot ROM image 232 may include boot code that executes when the storage device 200 is started. The boot ROM image 232 may include multiple public keys 235. The public keys 235 may be injected into the boot ROM image 232 during the manufacturing (or preparation) process of the storage device 200.

[0045] The first memory 260 may include boot code that executes after the boot ROM 230 when the storage device 200 starts. Therefore, the first memory 260 may be a host ( Figure 1 The first memory 260 may be a region where the host writes or reads data.

[0046] The first memory 260 may include a first region 240 and a second region 250.

[0047] A flash boot image 242, different from the boot ROM image 232, may be stored in the first region 240. The flash boot image 242 may include boot code that executes when the storage device 200 boots. The first region 240 may be a region that is readable but not writable by the memory controller 210. That is, according to the example embodiment, the memory controller 210 cannot write to the first region 240.

[0048] The flash boot image 242 may include multiple public keys 245. The multiple public keys 245 may be injected into the flash boot image 242 during the manufacturing process of the storage device 200.

[0049] The second region 250 may store the startup signature 255 on the flash startup image 242. That is, in the first memory 260 according to the exemplary embodiment, the first region 240 in which the flash startup image 242 is stored may be separated from the second region 250 in which the startup signature 255 is stored.

[0050] A boot signature 255 can be generated using, for example, a public key and multiple public keys 245 of a flash boot image 242. When the storage device 200 is manufactured, the boot signature 255 can be stored in a second region 250 along with the flash boot image 242 of the first region 240. Furthermore, the boot signature 255 can be written to the memory controller 210 during updates to the storage device 200. That is, the second region 250 can be a region that is both readable and writable by the memory controller 210.

[0051] The first memory 260 may include non-volatile memory. The first memory 260 may be, for example, NOR flash memory.

[0052] The second memory 270 may include a user data area 280 and a firmware (FW) image area 290.

[0053] User data area 280 can be an area accessible to the host. For example, user data area 280 can be an area where the memory controller 210 writes and reads data according to commands such as read or write provided from the host. That is, user data area 280 can be the majority of the area where data is written to and stored in the second memory 270.

[0054] Conversely, firmware image area 290 can be an area that restricts host access. A firmware image can be stored in firmware image area 290. The firmware image may include boot code that executes when firmware 215 of memory controller 210 is started. The firmware image may be stored in firmware image area 290 during the manufacturing process of storage device 200. According to another example embodiment, a new firmware image may be stored in firmware image area 290 via a firmware update after storage device 200 is released.

[0055] The second memory 270 may include non-volatile memory. The second memory 270 may include, for example, NAND flash memory, vertical NAND flash memory (VNAND, 3D), NOR flash memory, PRAM (phase-change random access memory), RRAM (resistive random access memory), MRAM (magnetoresistive random access memory), FRAM (ferroelectric random access memory), STT-RAM (spin-transfer torque random access memory), and similar non-volatile memory devices. However, this disclosure is not limited thereto, and therefore, according to another example embodiment, the second memory may include other types of memory.

[0056] The firmware image area 290 of the OTP memory 220, boot ROM 230, first memory 260, and second memory 270 is a space that stores information and boot code for booting the storage device 200, and can be a secure area that cannot be arbitrarily changed by the host. In the following text, reference will be made to... Figure 3 Detailed instructions are provided.

[0057] The system bus 205 can perform connections between the memory controller 210, the OTP memory 220, the boot ROM 230, the first memory 260, and the second memory 270.

[0058] Figure 3 It is used for explanation Figure 2 A diagram illustrating the boot process of a storage device.

[0059] Reference Figure 2 and Figure 3 When power is applied to the storage device 200, the boot ROM 230 can be copied to the memory controller 210. The copied boot ROM image 232 can be executed by the memory controller 210. As a result, the memory controller 210 can become the core of the boot ROM 230.

[0060] Next, the first memory 260 can be copied to the memory controller 210. The memory controller 210 can verify the copied flash boot image 242. The memory controller 210 can read the data written to the OTP memory 220. The memory controller 210 can verify the boot signature 256 of the flash boot image 242 based on the data written to the OTP memory 220 using the first public key 236 in the boot ROM image 232. For example, the memory controller 210 can verify the boot signature 256 of the flash boot image 242 using the first public key 236 recognized by the OTP memory 220. The first public key 236 can be a value used to confirm the creation of the flash boot image 242 at an authentication location.

[0061] When verifying the boot signature 256 of the flash boot image 242, the flash boot image 242 can be executed by the memory controller 210. As a result, the memory controller 210 can become the core of the second memory 270.

[0062] Next, firmware image 292 can be copied from firmware image region 290 of second memory 270 to memory controller 210. Firmware image 292 may include firmware signature 296. Firmware signature 296 can be generated using firmware image 292 and manufacturer's private key. Firmware signature 296 can be stored in firmware image region 290 along with firmware image 292 during manufacturing of storage device 200.

[0063] The memory controller 210 can verify the copied firmware image 292. The memory controller 210 can verify the firmware signature 296 of the firmware image 292 based on data written to the OTP memory 220 using the first public key 246 in the first memory 260. This enables confirmation that the firmware image 292 was created at an authorized location.

[0064] Each address of public keys 236, 237, and 238 stored in boot ROM image 232 can correspond to each address of public keys 246, 247, and 248 stored in flash boot image 242. For example, the address of the first public key 236 stored in boot ROM image 232 can correspond to the address of the first public key 246 stored in flash boot image 242. This is because multiple public keys 236, 237, and 238 stored in boot ROM image 232 and multiple public keys 246, 247, and 248 stored in flash boot image 242 are used during boot based on the data written to OTP memory 220. Therefore, verification of flash boot image 242 and firmware signature 296 can be performed using the same public keys.

[0065] When verifying the firmware signature 296 of firmware image 292, firmware image 292 can be executed by memory controller 210. As a result, memory controller 210 can become the core of firmware. That is, memory controller 210 can be operated by firmware.

[0066] Therefore, the storage device 200 can be started for security reasons. Afterward, the storage device 200 can be driven by firmware.

[0067] Figure 4 This is a block diagram illustrating a method for updating a storage device according to an exemplary embodiment.

[0068] Reference Figure 4 The storage device 200 can perform a security update of the firmware image region 290 of the second memory 270 according to the example embodiment. The security update can be performed while the storage device 200 is powered on. That is, the memory controller 210 can be in a state driven by firmware 215. The security update can also be performed by firmware 215.

[0069] Storage device 200 may be provided with a new firmware image from an external source. Firmware 215 may, in response to the provision of the new firmware image, write the new firmware image to firmware image region 290 of second memory 270, and may write a new boot signature 255 to second region 250 of first memory 260. Additionally, firmware 215 may, in response to the provision of the new firmware image, provide a public key write command to OTP memory 220. OTP memory 220 may, in response to the public key write command, identify another public key. Referring below... Figures 5 to 9 Provide a detailed description.

[0070] Figure 5 This is a flowchart illustrating a method for updating a storage device according to an exemplary embodiment. Figure 6 It is used to explain the basis Figure 5 A block diagram of a method for updating a storage device. Figure 7 It is used for explanation Figure 5 A block diagram of the new firmware image. Figure 8 It is used for explanation Figure 5 The block diagram of the S70 operation. Figure 9 It is used for explanation Figure 5 The block diagram of the operation S72.

[0071] Reference Figure 5 and Figure 6 It can be done in the firmware ( Figure 4 The method (S10) of updating the storage device according to an exemplary embodiment is started while a new second firmware image 302 is provided to firmware 215. For example, firmware 215 may be provided with an update command including a second firmware image 302 from an external source.

[0072] Firmware 215 may write the second firmware image 302 into the firmware image area 290 of the second memory 270 in response to the receipt of the second firmware image 302.

[0073] Firmware 215 can determine whether the first public keys 236 and 246 need to be revoked in response to the receipt of the second firmware image 302 (S15). Firmware 215 can determine the need to revoke the first public keys 236 and 246 based on the second firmware signature 307 included in the second firmware image 302. For example, when the private key used for the second firmware signature 307 is different from the private key used for the old first firmware signature 296, firmware 215 can determine that the first public keys 236 and 246 need to be revoked.

[0074] When it is determined that the first public keys 236 and 246 need to be revoked, firmware 215 can read a new second boot signature 257 from the second firmware image 302 (S20).

[0075] For example, refer to Figure 7 The second firmware image 302 provided to firmware 215 can be in an encrypted state. The second firmware image 302 may include a second firmware signature 307 and a second boot signature 257. The second firmware signature 307 can be generated using the second firmware image 302 and the second private key 317 via a digital signature algorithm (DSA). The second boot signature 257 can be generated using the flash boot image 242 and the second private key 317 via a digital signature algorithm.

[0076] A digital signature algorithm can be defined as an algorithm that generates a signature on given data using a private key known only to the person who created it. A third party can then use the public key used for verification to confirm that the data was generated by the verified person through signature verification.

[0077] Therefore, the second firmware image 302 can be verified as being generated by the manufacturer through the second firmware signature 307. As a result, the manufacturer authentication and integrity of the second firmware image 302 can be ensured. Because the first firmware signature 296 is generated from the first private key and the second firmware signature 307 is generated from a second private key different from the first private key, the firmware 215 can determine that the first public keys 236 and 246 need to be revoked. Therefore, the firmware 215 can read a new second boot signature 257 from the second firmware image 302.

[0078] Refer again Figure 5 and Figure 6 Firmware 215 can write a new second boot signature 257 into the second region 250 of the first memory (S30).

[0079] Next, firmware 215 can write data to OTP memory 220 (S40). As a result, OTP memory 220 can recognize another public key (i.e., second public keys 237 and 247).

[0080] Due to the characteristics of the OTP memory 220, the OTP memory 220 does not need to recognize the first public keys 236 and 246 again. That is, the first public key 236 stored in the boot ROM image 232 and the first public key 246 stored in the flash boot image 242 can be reused and revoked. Therefore, the storage device according to the exemplary embodiment can prevent the public key from rolling back to a previous public key during the update process.

[0081] Next, firmware 215 can delete the previous first boot signature 256 (S50) written to the second region 250 of the first memory.

[0082] As a result, firmware 215 can successfully update the firmware (S60) and can securely boot the storage device using the new second public keys 237 and 247 (S70).

[0083] That is, such as using Figure 3 Earlier explanation, and reference Figure 8 When power is applied to the storage device, the boot ROM image 232 can be copied to the memory controller 210. The memory controller 210 can become the core of the boot ROM 230.

[0084] Next, the flash boot image 242 and the second boot signature 257 can be copied to the memory controller 210. The memory controller 210 can then read the data written to the OTP memory 220.

[0085] The memory controller 210 can verify the second boot signature 257 using the second public key 237 in the boot ROM image 232 based on the data read from the OTP memory 220. Since the second boot signature 257 is generated using the second public key 247 in the flash boot image 242, it can be verified using the second public key 237 in the boot ROM image 232. Therefore, the flash boot image 242 can be executed, and the memory controller 210 can become the core of the second memory 270.

[0086] Next, the second firmware image 302 can be copied to the memory controller 210. The memory controller 210 can then read data from the OTP memory 220.

[0087] The memory controller 210 can verify the second firmware signature 307 using the second public key 247 in the flash boot image 242 based on the data written to the read OTP memory 220. Since the second firmware signature 307 is generated using the second private key corresponding to the second public keys 237 and 247, it can be verified using the second public key 247 in the flash boot image 242. Therefore, the second firmware image 302 can be executed, and the memory controller 210 can become the core of firmware 215.

[0088] As a result, the storage device 200 can be booted using the updated second firmware image 302 for secure operation.

[0089] On the other hand, if it is determined in operation S15 that it is not necessary to revoke the first public keys 236 and 246, then firmware 215 writes the second firmware image 302 into the firmware image area 290, and then the firmware update can be successful (S62). For example, when the second firmware signature 307 and the first firmware signature 296 are generated using the same private key, firmware 215 can determine that it is not necessary to revoke the first public keys 236 and 246. That is, when the second firmware signature 306 is generated using the first private key, since the OTP memory 220 has already recognized the first public key 236 in the boot ROM image 232 and the first public key 246 in the flash boot image 242 corresponding to the first private key, it is not necessary to change the data written on the OTP memory 220.

[0090] Furthermore, since the first public key 236 in the boot ROM image 232 and the first public key 246 in the flash boot image 242 correspond to the first private key, it is not necessary to revoke the first public key 236 in the boot ROM image 232 and the first public key 246 in the flash boot image 242.

[0091] As a result, firmware 215 enables a successful firmware update, allowing the storage device 200 to be booted securely using the old first public keys 236 and 246 (S72). See reference. Figure 9 For security purposes, the storage device 200 can be started by the following steps: executing the boot ROM image 232, verifying the first boot signature 256 using the first public key 236 and executing the flash boot image 242, and verifying the second firmware signature 306 using the first public key 246 and executing the second firmware image 302.

[0092] When a public key used for secure boot is exposed on a secure boot-enabled storage device or when the public key is compromised, a method for revoking the public key is required. In this case, a new firmware image, including a firmware signature signed with a new private key, needs to be provided to the storage device. When manufacturing the storage device, multiple public keys can be stored in the boot ROM image and flash boot image within the storage device. Therefore, when a new firmware image is provided, the storage device can revoke the old public key by using the public key among the multiple public keys that corresponds to the firmware signature included in the new firmware image, and can then boot using the new public key based on the new firmware.

[0093] In the case of a storage device booting using a boot ROM and a first memory, a new flash boot image and a new firmware image are required to revoke the old public key and perform booting using the new public key. However, since the first memory is restricted access due to storing boot information, a new flash boot image cannot be provided to the storage device after it has been released. Furthermore, when manufacturing the storage device, it is difficult to inject the boot signatures of all public keys into the second area of ​​the first memory. Therefore, storage devices booting using a boot ROM and a first memory require restoration and updates by the manufacturer.

[0094] Conversely, when the storage device 200 according to the exemplary embodiment is provided with a new firmware image 302 including a new boot signature 257, the new boot signature 257 can be written into the first memory 260 via firmware 215. Additionally, the data written to the OTP memory 220 can be changed, and the old public key in the first memory 260 can be revoked.

[0095] Therefore, storage device 200 is provided with a new firmware image 302 but not a new flash boot image, the old public keys 236 and 246 are revoked, and storage device 200 can be updated with new public keys 237 and 247. That is, storage device 200 can be updated simply by providing a firmware image without changing the flash boot image. Alternatively, the manufacturer may provide a new firmware image 302 that includes a new boot signature 257 and a new firmware signature 307, and may provide updates to the public keys to storage device 200. Additionally, storage device 200 can be booted according to the old secure boot sequence without changing the secure boot sequence.

[0096] Figure 10 This is a flowchart illustrating a method for updating a storage device according to an exemplary embodiment. Figures 11 to 14 It is used for explanation Figure 10 The block diagram of the S82 operation. The main explanations and usage will be provided. Figures 4 to 9 The differences are explained.

[0097] Reference Figure 10The method for updating the storage device according to the exemplary embodiment can be started simultaneously with the provision of a new second firmware image 302 to firmware 215. The storage device can be updated via operations S20 to S70 as described above.

[0098] However, a sudden power outage (SPO) (S80) may occur during operation S15 to S40.

[0099] At this point, the storage device can securely activate the previously obtained first public key (S82).

[0100] For example, refer to Figure 5 , Figure 6 and Figure 11 A sudden power outage can occur simultaneously with the firmware receiving the second firmware images 302_1 and 302_2 to write them into the firmware image region 290 of the second memory 270. The writing of the second firmware images 302_1 and 302_2 into the firmware image region 290 of the second memory 270 can be performed, for example, alternately with writing a new second boot signature 257 into the second region 250 of the first memory (operation S30). That is, operation S30 can be performed after the second firmware images 302_1 and 302_2 have been written into at least a portion of the firmware image region 290 of the second memory 270. According to another example embodiment, operation S30 can be performed after all the second firmware images 302_1 and 302_2 have been written into the firmware image region 290 of the second memory 270.

[0101] Firmware image region 290 may include multiple firmware image storage regions 290_1 to 290_n. Each of firmware images 302_1, 302_2, and 292 may be stored in each of firmware image storage regions 290_1 to 290_n. Second firmware images 302_1 and 302_2 may be stored in some of the multiple firmware image storage regions 290_1 to 290_n, and first firmware image 292 may be stored in the remaining regions.

[0102] In this case, since the data stored in the OTP memory has not been changed, the storage device can be started securely by the following steps: verifying the first boot signature 256 using the first public key 236 to execute the flash boot image 242, and verifying the first firmware signature 296 using the first public key 246 to execute the first firmware image 292.

[0103] When a new firmware image is provided again after a secure boot, the storage device can be updated by operating S10 to S70.

[0104] In yet another example, refer to Figure 12A sudden power outage can occur while the new second boot signature 257_1 is being written into the second region 250 of the first memory or after the second boot signature 257_1 has been written into the second region 250 of the first memory.

[0105] According to the example embodiment, Figure 12 The situation shown can occur before a portion of the second boot signature 257_1 is written to the second region 250, but before the data written to the OTP memory 220 is changed. Therefore, refer to Figure 13 The storage device can be started securely using the boot ROM image 232, the flash boot image 242 verified by the first public key 236 and the first boot signature 256 based on the data written on the OTP memory 220, and the first firmware image 292 verified by the first public key 246 and the first firmware signature 296 based on the data written on the OTP memory 220.

[0106] When a new firmware image is provided again after a secure boot, the storage device can be updated by operating S10 to S70.

[0107] After the new second boot signature 257_1 is written into the second region 250 of the first memory, data is written to the OTP memory 220. Thereafter, the old first boot signature 256 is deleted, and the update of the storage device according to the exemplary embodiment can be completed. As a result, even if a sudden power outage occurs during the update process, the storage device can be securely booted using the first public keys 236 and 246 prior to the update. Additionally, the storage device can be securely booted according to the old secure boot sequence.

[0108] Figure 14 It is used to explain in Figure 10 A block diagram showing the case where operation S10 is executed after operation S82.

[0109] Reference Figure 14The storage device can be provided with a new second firmware image 302 again after a firmware update fails due to a sudden power outage during the update process. The new second firmware image 302 can be a firmware image generated using the same private key as the firmware image provided in the firmware update that failed due to the sudden power outage. Firmware 215 can read a new second boot signature 257_2 from the new second firmware image 302. In this case, since the old written second boot signature 257_1 and the new second boot signature 257_2 are generated using the same private key, the new second boot signature 257_2 needs to be written to the address where the old second boot signature 257_1 is written in the second region 250. Therefore, firmware 215 deletes the old second boot signature 257_1 and can write the second boot signature 257_2 from the new second firmware image 302 to the address where the old second boot signature 257_1 has been deleted.

[0110] In yet another example, the new firmware image 302 may be provided with another firmware image generated by a different private key than the firmware image provided by a firmware update that failed due to a sudden power outage. In this case, firmware 215 reads a new boot signature from the provided alternative firmware image and may write the new boot signature to an address in a second region 250 corresponding to the address where the public key is stored in the first region 240.

[0111] Therefore, even if a boot signature written via a failed firmware update exists in the second region 250, no problems will occur during storage device updates and boots.

[0112] Figure 15 This is a flowchart illustrating a method for updating a storage device according to an exemplary embodiment. Figure 16 It is used for explanation Figure 15 The block diagrams for operations S92 and S94 are shown. The main explanations and usage will be provided. Figures 4 to 9 The differences are explained.

[0113] Reference Figure 15 and Figure 16 Even during operation S50 of the method for updating the storage device according to the exemplary embodiment, a sudden power outage (S90) may occur.

[0114] At this time, because the OTP memory 220 is written to identify the second public keys 237 and 247, the storage device can be started using the second public keys 237 and 247 even if the first boot signature 256 is not deleted (S92).

[0115] The storage device uses the second public key 237 to verify the second boot signature 257 and can accordingly execute the flash boot image 242. Additionally, the storage device uses the second public key 247 to verify the second firmware signature 307 and can securely execute and boot the first firmware image 292.

[0116] Next, when both the first boot signature 256 and the second boot signature 257 are written to the second region 250 of the first memory, the firmware can delete the first boot signature 256 (S94). That is, when the OTP memory 220 is written to identify the second public keys 237 and 247 and revoke the old first public keys 236 and 246, the firmware can delete the old first boot signature 256 existing in the second region 250 of the first memory.

[0117] In the detailed implementation, those skilled in the art will understand that many variations and modifications can be made to the exemplary embodiments without substantially departing from the principles of this disclosure. Therefore, the exemplary embodiments disclosed herein are used only in a general and descriptive sense and not for purposes of limitation.

Claims

1. A storage device, comprising: A boot read-only memory is configured to store multiple public keys and a boot read-only memory image; A single-programmable memory configured to identify a first public key among the plurality of public keys; A first memory includes a first region and a second region, the first region being configured to store the plurality of public keys and a flash boot image different from the boot read-only memory image, and the second region being configured to store a first boot signature corresponding to the flash boot image; The second memory includes a user data area and a firmware image area, the firmware image area being configured to store a first firmware image including a first firmware signature. as well as The memory controller is configured as follows: Receive a second firmware image, the second firmware image including a second firmware signature different from the first firmware signature and a second boot signature different from the first boot signature. Based on the receipt of the second firmware image, the second public key and the flash boot image are received from the first region of the first memory, among the plurality of public keys. Write the second boot signature into the second region of the first memory.

2. The storage device according to claim 1, wherein, The first region of the first memory is readable only by the memory controller, and the second region of the first memory is both readable and writable by the memory controller.

3. The storage device according to claim 2, wherein, The memory controller is also configured to perform a write operation in a second area of ​​the first memory based on the receipt of the second firmware image.

4. The storage device according to claim 1, wherein, The first firmware signature is generated based on the first private key corresponding to the first public key. The second firmware signature is generated based on the second private key corresponding to the second public key. The first private key and the second private key are the same, and The first boot signature and the second boot signature are the same.

5. The storage device according to claim 4, wherein, The first boot signature written at the first address of the first memory is deleted, and the second boot signature is written at the first address.

6. The storage device according to claim 1, wherein, The first firmware signature is generated based on the first private key corresponding to the first public key. The second firmware signature is generated based on a second private key that is different from the first private key and corresponds to the second public key, and The second startup signature is generated based on the flash startup image and the second private key.

7. The storage device according to claim 6, wherein, The first boot signature is written to the first address in the second region of the first memory, and The second boot signature is written in the second region of the first memory at a second address that is different from the first address.

8. The storage device according to claim 1, wherein, The address where the second boot signature is stored in the second region of the first memory corresponds to the address where the second public key is stored in the boot read-only memory.

9. The storage device according to claim 1, wherein, The memory controller is configured to receive the flash boot image from a first region of the first memory based on the receipt of the second firmware image, and The second startup signature is generated based on the second private key and the flash startup image.

10. The storage device according to claim 1, wherein, The address of each of the plurality of public keys stored in the startup read-only memory image corresponds to the address of each of the plurality of public keys stored in the first memory.

11. The storage device according to claim 1, wherein, The memory controller is also configured to write data to the one-time programmable memory such that the one-time programmable memory recognizes the second public key among the plurality of public keys.

12. The storage device according to claim 11, wherein, The memory controller is also configured to write the second boot signature into a second region of the first memory and to write the data into the one-time programmable memory, such that the one-time programmable memory recognizes the second public key.

13. The storage device according to claim 12, wherein, The memory controller is also configured to write the data onto the one-time programmable memory, such that the one-time programmable memory recognizes the second public key and deletes the first boot signature from a second region of the first memory.

14. A storage device, comprising: A boot read-only memory is configured to store multiple public keys and a boot read-only memory image; A single-programmable memory configured to identify a first public key among the plurality of public keys; A first memory includes a first region and a second region, the first region being configured to store the plurality of public keys and a flash boot image different from the boot read-only memory image, and the second region being configured to store a first boot signature corresponding to the flash boot image, the second region being different from the first region; The second memory includes a user data area and a firmware image area, the firmware image area being configured to store a first firmware image including a first firmware signature. as well as The memory controller is configured as follows: Receive a second firmware image, the second firmware image including a second firmware signature different from the first firmware signature, and The second firmware image is written into the firmware image area based on the receipt of the second firmware image. The first region of the first memory is readable only by the memory controller, and the second region of the first memory is both readable and writable by the memory controller.

15. The storage device according to claim 14, wherein, The first firmware signature is generated based on the first private key corresponding to the first public key, and The second firmware signature is generated based on the first private key.

16. The storage device according to claim 14, wherein, The first firmware signature is generated based on the first private key corresponding to the first public key. The second firmware signature is generated based on a second private key that is different from the first private key, and The memory controller is also configured to write a second boot signature, different from the first boot signature, into a second region of the first memory based on the receipt of the second firmware image.

17. The storage device according to claim 16, wherein, The memory controller is also configured to read, based on the receipt of the second firmware image, a second public key corresponding to the second private key from a first region of the plurality of public keys.

18. The storage device according to claim 14, wherein, The memory controller is also configured to use the first public key to verify the first firmware image when a power outage occurs while the second firmware image is being written to the second region.

19. A storage device, comprising: Start-up read-only memory, which stores multiple public keys and a startup read-only memory image; A single-programmable memory configured to identify a first public key among the plurality of public keys; A first memory includes a first region and a second region, the first region being configured to store the plurality of public keys and a flash boot image different from the boot read-only memory image, and the second region being configured to store a first boot signature corresponding to the flash boot image and different from the first region; The second memory includes a user data area and a firmware image area, the firmware image area being configured to store a first firmware image including a first firmware signature generated based on a first firmware signature generated based on a first private key corresponding to the first public key. as well as The memory controller is configured as follows: Receive a second firmware image, the second firmware image including a second firmware signature different from the first firmware signature and a second boot signature different from the first boot signature. Based on the receipt of the second firmware image, the second boot signature is written to the second area of ​​the first memory, and Data is written into the one-time programmable memory, enabling the one-time programmable memory to recognize a second public key among the plurality of public keys that is different from the first public key, and to delete the first boot signature stored in the second area of ​​the first memory. Specifically, the second firmware signature is generated based on the second private key corresponding to the second public key and the second firmware image.

20. The storage device according to claim 19, wherein, The memory controller is configured to write the data into the one-time programmable memory, such that the one-time programmable memory recognizes the second public key, then verifies the second firmware image using the second public key in the event of a power outage, and deletes the first boot signature stored in the second area of ​​the first memory.

Images