Storage device, storage system having the same and operating method thereof

Abstract

A storage device according to the present invention comprises a plurality of memory blocks having a plurality of memory cells connected to word lines and bit lines, at least one non-volatile memory device storing a blockchain ledger in at least one of the plurality of memory blocks, and a controller controlling the at least one non-volatile memory device, wherein the controller receives a device authentication request message from an external device, reads the blockchain ledger from the at least one non-volatile memory device, and transmits authentication information corresponding to the blockchain ledger to the external device in response to the device authentication request.

Description

Technology Field

[0001] The present invention relates to a storage device, a storage system having the same, and a method of operating the same. Background Technology

[0002] Generally, as a non-volatile memory, flash memory can retain stored data even when the power is cut off. Recently, storage devices containing flash memory, such as eMMC (embedded Multi-Media Card), UFS (Universal Flash Storage), SSD (Solid State Drive), and memory cards, are widely used. Storage devices are useful for storing or transferring large amounts of data. There is a continuous demand for technologies that can improve the reliability of storage devices. The problem to be solved

[0003] The object of the present invention is to provide a storage device that performs authentication, firmware credentialing, and firmware updates between devices, a storage system including the same, and a method of operating the same. means of solving the problem

[0004] A method of operating a storage device according to an embodiment of the present invention may include the steps of: transmitting an authentication request message to another storage device; receiving a certificate signed with the private key of the other storage device from the other storage device; reading the public key of the other storage device from a blockchain ledger; and decrypting the signed certificate with the public key.

[0005] A storage device according to an embodiment of the present invention comprises: at least one non-volatile memory device having a plurality of memory blocks having a plurality of memory cells connected to word lines and bit lines, and storing a blockchain ledger in at least one of the plurality of memory blocks; and a controller for controlling the at least one non-volatile memory device, wherein the controller receives a device authentication request message from an external device, reads the blockchain ledger from the at least one non-volatile memory device, transmits authentication information corresponding to the blockchain ledger to the external device in response to the device authentication request, and performs an authentication operation for another device using the blockchain ledger.

[0006] A storage system according to an embodiment of the present invention comprises: a first storage device for storing a blockchain ledger; and a second storage device for storing the blockchain ledger, wherein the first storage device transmits an authentication request message to the second storage device, receives a certificate corresponding to the authentication request message from the second storage device, reads the public key of the second storage device from the blockchain ledger, and authenticates the second storage device by decrypting the certificate using the public key.

[0007] A storage system according to an embodiment of the present invention comprises: a host device for storing a blockchain ledger; a switch device connected to the host device and storing the blockchain ledger; and a plurality of devices connected to the switch device and storing the blockchain ledger, wherein at least one of the plurality of devices may include a storage device that performs offloading of the host device using the blockchain ledger.

[0008] A method of operating a storage system according to an embodiment of the present invention may include: a step of determining whether a new storage device is connected to a switch device from a host device; a step of requesting device information from the storage device when the new storage device is newly connected to the switch device; a step of verifying the storage device in the host device, the switch device, and the remaining devices by comparing device information received from the storage device with information stored in a blockchain ledger; and a step of recording device information of the storage device in the blockchain ledger based on a blockchain consensus method after the verification of the storage device is completed.

[0009] A method of operation of a host device according to an embodiment of the present invention may include: a step of performing an authentication operation of the storage device using a blockchain; and a step of performing a qualification verification operation of firmware running on the storage device using the blockchain. Effects of the invention

[0010] A storage device according to an embodiment of the present invention, a storage system having the same, and a method of operating the same can efficiently use resources while enhancing security by performing device authentication operations, firmware credential verification operations, or firmware update operations between devices using a blockchain. Brief explanation of the drawing

[0011] The drawings attached below are intended to aid in understanding the embodiments thereof, and embodiments are provided along with a detailed description. Figure 1 is a drawing showing a general storage system (10). FIG. 2 is a drawing illustrating an exemplary storage system (1000) according to an embodiment of the present invention. FIG. 3 is a diagram exemplarily showing a blockchain block according to an embodiment of the present invention. FIG. 4 is a ladder diagram exemplarily showing a device authentication operation in a storage system (1000) according to an embodiment of the present invention. FIG. 5 is a ladder diagram exemplarily showing a firmware qualification operation in a storage system (1000) according to an embodiment of the present invention. FIG. 6 is a ladder diagram exemplarily showing a device authentication operation in a storage device of a storage system according to an embodiment of the present invention. FIG. 7 is a ladder diagram exemplarily showing a device authentication operation in a storage device of a storage system according to another embodiment of the present invention. FIG. 8 is a ladder diagram exemplarily showing a firmware update operation in a storage device of a storage system (1000) according to an embodiment of the present invention. FIG. 9 is a ladder diagram exemplarily showing the firmware update operation of a storage system (1000) according to an embodiment of the present invention. FIG. 10 is a diagram exemplarily showing the addition of a new device to a storage system according to an embodiment of the present invention. FIG. 11 is a diagram exemplarily showing a newly created blockchain block following the addition of a new storage device (SSD3) shown in FIG. 10. FIG. 12 is a diagram exemplarily showing one of the devices being reconnected to a storage system (3000) according to an embodiment of the present invention. Figure 13 is a diagram exemplarily showing the payload of the Nth blockchain block used for device authentication. FIG. 14 is a ladder diagram exemplarily showing the authentication operation of a device according to the reconnection shown in FIG. 12. FIG. 15 is a flowchart illustrating an exemplary method of operation of a storage system according to an embodiment of the present invention. FIG. 16 is a flowchart exemplarily showing a method of operation of a storage system according to another embodiment of the present invention. FIG. 17 is a flowchart exemplarily showing a method of operation of a storage system according to another embodiment of the present invention. FIG. 18 is a drawing illustrating an exemplary computing system (20) in an embodiment of the present invention. FIG. 19 is a drawing exemplarily showing a storage device (30) according to an embodiment. FIG. 20 is a drawing illustrating an exemplary controller (200) according to an embodiment of the present invention. FIG. 21 is a drawing exemplarily showing a data center to which a memory device according to an embodiment of the present invention is applied. Specific details for implementing the invention

[0012] Below, the contents of the present invention will be described clearly and in detail using the drawings so that a person skilled in the art can easily implement the invention.

[0013] A storage device according to an embodiment of the present invention, a storage system having the same, and a method of operating the same can perform device authentication using a blockchain or perform attestation for firmware operating on the device.

[0014] FIG. 1 is a drawing showing a general storage system (10). Referring to FIG. 1, the storage system (10) includes a host device (11), a secure storage device (12), a switch device (13), and devices (14-1, 14-2, 14-3, 14-4).

[0015] Generally, the host device (11) checks whether the firmware being executed on the devices (14-1 to 14-4) made by the vendor is operating normally. The host device (11) is equipped with a secure storage device (12) that stores values ​​measured during normal operation of the devices (14-1 to 14-3). Subsequently, the host device (11) requests the corresponding measured values ​​when the device is executing the firmware. The host device (11) verifies whether the firmware is operating normally by comparing the measured values ​​received from the device with the values ​​stored in the secure storage device (12). This verification of whether the firmware is operating normally is called attestation.

[0016] Generally, such credential verification is performed after the authentication of the device is performed first. For example, a host device (11) sends an authentication request message to a first storage device (14-1, SSD1). The first storage device (SSD1) responds to this authentication request by signing the authentication request message using a private key and sends the signed certificate to the host device (11). The host device (11) confirms that the signature is from the first storage device (SSD1) by decrypting the signed certificate using the public key (PubK_SSD1) of the first storage device (SSD1) stored in the secure storage device (12).

[0017] After the authentication operation is completed, a credential verification operation is performed. The host device (11) requests a firmware measurement value from the first storage device (SSD1) to verify whether the firmware in the first storage device (SSD1) is operating normally. The first storage device (SSD1) responds to this verification request by operating the firmware, measuring the relevant value, and transmitting the measurement value to the host device (11). The host device (11) compares the measurement value transmitted from the first storage device (SSD1) with the measurement value (MV_SSD1) that is already stored in the secure storage device (12) and is operating normally. If the measurement value and the stored value (MV_SSD1) match, the host device (11) determines that the firmware of the first storage device (SSD1) is operating normally.

[0018] This general credentialing method requires additional protection against hacking of the secure storage device (12) by providing a secure storage device (12). Additionally, only the host device (11) can perform authentication and credentialing for each device. In the case of a system having a device that supports offloading operations, each device requires a complex procedure to perform authentication and credentialing via the host device.

[0019] A storage system according to an embodiment of the present invention is equipped with a device that performs offloading from a host device, and can perform authentication, credential verification, and firmware updates between devices using blockchain technology.

[0020] A storage system according to an embodiment of the present invention may include a host device that uses blockchain technology to record the public key of the device's firmware, a value measured during normal operation, and the firmware version in a blockchain ledger, and a device that performs device authentication, performs credential verification for the normal operation of the firmware, or performs a firmware update by comparing the value received by requesting the device's public key, the value measured during normal operation, and the firmware version with the value in the blockchain ledger.

[0021] The storage system according to an embodiment of the present invention can reduce management costs by not requiring a separate secure storage device. In addition, the storage system according to an embodiment of the present invention can reduce the load on the host device by performing authentication, credential verification, or firmware updates between devices without hardware involvement.

[0022] FIG. 2 is a diagram illustrating an exemplary storage system (1000) according to an embodiment of the present invention. Referring to FIG. 2, the storage system (1000) may include a host device (1100), a switch device (1300), and devices (1410, 1420, 1430, 1440).

[0023] The host device (1100) can be connected to a plurality of devices (1410, 1420, 1430, 1440) through a switch device (1300). In an embodiment, at least one of the plurality of devices (1410, 1420, 1430, 1440) may include a storage device that performs offloading of the host device (1100) using a blockchain ledger.

[0024] The host device (1100) can directly perform device authentication or credential verification. At the same time, the host device (1100) can offload these functions (device authentication, credential verification) to each of the devices (1410, 1420, 1430, 1440). For example, each of the devices (1410, 1420, 1430, 1440) can perform verification operations using a blockchain to determine whether a device is legitimate when transmitting data to another device, updating firmware, or reconnecting.

[0025] For example, when multiple devices are replaced on a server or when new blockchain creation events, such as firmware updates, occur on multiple devices, multiple blockchains may be created competitively. These blockchains may be connected by referencing different or the same blockchain. Furthermore, blockchain verification is not performed by the entire system, but rather by specific key devices (host, security device, FPGA, accelerator, switch controller, high-stability SSD, etc.) performing verification, thereby allowing the system to be authenticated as a verified blockchain. Once verification is complete, other devices can subsequently create and connect blockchains. In an embodiment, multiple blockchains may simultaneously create blockchains with different branches. Subsequently, blockchains may continuously create chains, and the blockchain that occupies the majority (i.e., the blockchain with the longest branch) may survive. A minority of blockchains may be recorded in the newly created blockchains among the majority. The series of processes described above may be referred to as a consensus process. Meanwhile, it should be understood that the consensus process of the present invention is not limited thereto.

[0026] Meanwhile, if, after such authentication or credentialing, one storage device exceeds its workload or if faster processing is desired by having another device perform tasks in parallel, the storage device may offload its tasks to another authenticated or credentialed device.

[0027] In an embodiment, the switch device (1300) can transmit and receive data to and from the host device (1100) and devices (1410, 1420, 1430, 1440) through a PCIe (Peripheral Component Interconnect Express) interface.

[0028] Meanwhile, it should be understood that the present invention is not limited to such PCIe interfaces. The present invention may be implemented with various interfaces that support a peer-to-peer interface. In an embodiment, the devices (1410, 1420, 1430, 1440) may include storage devices (1410 (SSD1), 142 (SSD2)). In an embodiment, the devices (1410, 1420, 1430, 1440) may include computational processing devices (1430 (FPGA1), 1440 (FPGA2)). Meanwhile, it should be understood that the number of devices (1410, 1420, 1430, 1440), the number of storage devices, or the number of computational processing devices shown in FIG. 2 are merely examples.

[0029] Each of the host device (1100), the switch device (1300), and the devices (1410, 1420, 1430, 1440) shares a blockchain ledger. Here, the blockchain ledger includes the public keys of the host device (1100) and the devices (1410, 1420, 1430, 1440) and measurements during normal firmware operation.

[0030] A blockchain ledger may contain blockchain blocks. Each blockchain block may be generated based on a consensus algorithm. For example, consensus algorithms such as PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stake), PoT (Proof of Trading), PoB (Proof of Burn), Proof of Storage, PoET (Proof of Elapsed Time), BFT (Byzantine Fault Tolerance), PBFT (Practical Byzantine Fault Tolerance), Paxos, or Raft may be used. For the sake of convenience of explanation, it will be assumed below that blockchain blocks are generated using the PoW consensus algorithm. In an embodiment, blockchain blocks may be generated using the PoW consensus algorithm when a storage device (SSD or FPGA) is attached (connected) or when the firmware is updated. Here, the blockchain block may contain the entire firmware data or a hash value obtained by hashing specific measurement data during firmware execution. Here, the hash value may be calculated using a hash function. In an embodiment, the hash function may be implemented as any one of the CRC-32 function, MD2 function, MD4 function, MD5 function, SHA-1 function, SHA-256 function, SHA-384 function, SHA-512 function and HAVAL function.

[0031] FIG. 3 is a diagram illustrating an exemplary blockchain block according to an embodiment of the present invention. Referring to FIG. 3, two blockchain blocks (32, 33) are shown for convenience of explanation.

[0032] The 99th blockchain block (32) stores values ​​corresponding to the first storage device (SSD1). The 99th blockchain block (32) may include a header and a payload. In an embodiment, the header may include the hash value of the previous blockchain block, the 98th blockchain block (31), and the payload hash value of the current blockchain block (32). Here, the payload hash value refers to the hash value for the payload. The payload may include the serial number of the first storage device (SSD1), the public key of the first storage device (SSD1), the firmware version, the firmware update time, the hash value of the firmware, the measured value during normal operation of the firmware, the hash value of the first storage device (SSD1), etc. In addition to this, the payload may further include various information, for example, the manufacturer of the device, the manufacturing date, the capacity, the SSD health status, the first connected time, etc.

[0033] The 100th blockchain block (33) stores values ​​corresponding to the second storage device (SSD2). The 100th blockchain block (33) may include a header and a payload. In an embodiment, the header may include the hash value of the previous 99th blockchain block (32) and the payload hash value of the current blockchain block (33). Here, the payload may include the serial number of the second storage device (SSD2), the public key of the second storage device (SSD2), the firmware version, the firmware update time, the hash value of the firmware, the measured value during normal operation of the firmware, the hash value of the second storage device (SSD2), etc.

[0034] FIG. 4 is a ladder diagram exemplarily showing a device authentication operation in a storage system (1000) according to an embodiment of the present invention. Referring to FIGS. 2 through 4, the device authentication operation in a host device (1100) can be performed as follows.

[0035] A host device (1100), a switch device (1300), and a first storage device (SSD1) share a blockchain ledger (S10). The host device (1100) can issue an authentication request message from the first storage device (SSD1) and transmit it to the switch device (1300) (S11). The switch device (1300) can transmit the authentication request message from the first storage device (SSD1) to the first storage device (SSD1) (S12). The first storage device (SSD1) can respond to the authentication request message by signing the authentication-related information with the private key of the first storage device (SSD1) (S13). This signed certificate can perform the role of authentication for the authentication-related information. Here, the authentication-related information may include specification information of the first storage device (SSD1). The above-described certificate signing process may proceed as follows. The first storage device (SSD1) can generate a hash for the authentication-related information. The first storage device (SSD1) can encrypt a hash value generated using a private key. The first storage device (SSD1) can generate a signed certificate having the encrypted hash value and authentication-related information.

[0036] The first storage device (SSD1) can transmit the signed certificate to the switch device (1300) (S14). The switch device (1300) can transmit the signed certificate to the host device (1100) (S15). The host device (1100) can read the public key of the first storage device (SSD1) from the blockchain ledger (S16). The host device (1100) can decrypt the signed certificate using the public key of the first storage device (SSD1) (S17). Here, the signed certificate may include an encrypted hash value and authentication-related information. The host device (1100) can decrypt the encrypted hash value using the public key of the first author device (SSD1). Additionally, the host device (1100) can generate a hash value for the authentication-related information. In an embodiment, when verifying authentication-related information from a decrypted certificate, the host device (1100) can authenticate the first storage device (SSD1) as a legitimate connection device.

[0037] Meanwhile, after the authentication operation for the first storage device (SSD1), a credential verification operation for the firmware may be performed.

[0038] FIG. 5 is a ladder diagram exemplarily showing a firmware qualification verification operation in a storage system (1000) according to an embodiment of the present invention. Referring to FIGS. 2 through 5, a qualification verification operation for the normal operation of firmware performed in a first storage device (SSD1) can proceed as follows.

[0039] The host device (1100), the switch device (1300), and the first storage device (SSD1) share a blockchain ledger (S20). The host device (1100) can issue a request for a firmware measurement value (FWMV) of the first storage device (SSD1) and transmit it to the switch device (1300) (S21). The switch device (1300) can transmit the request for a firmware measurement value (FWMV) of the first storage device (SSD1) to the first storage device (SSD1) (S22). The first storage device (SSD1) can drive the firmware in response to the request for a firmware measurement value (FWMV) and measure a value based on the result of the drive (S23). The first storage device (SSD1) can transmit the firmware measurement value (FWMV) of the first storage device (SSD1) to the switch device (1300) (S24). The switch device (1300) can transmit the firmware measurement value (FWMV) of the first storage device (SSD1) to the host device (1100) (S25). The host device (1100) can read the firmware measurement value of the first storage device (SSD1) from the blockchain ledger (S26). The host device (1100) can compare the firmware measurement value read from the blockchain ledger with the firmware measurement value transmitted from the first storage device (SSD1) (S27). If the firmware measurement value read from the blockchain ledger matches the firmware measurement value transmitted from the first storage device (SSD1), or if the difference value resulting from the comparison is within a predetermined range, the host device (1100) can determine that the firmware of the first storage device (SSD1) is operating normally.

[0040] Meanwhile, the storage system (1000) according to an embodiment of the present invention may perform mutual authentication between each device.

[0041] FIG. 6 is a ladder diagram exemplarily showing a device authentication operation in a storage device of a storage system according to an embodiment of the present invention. Referring to FIGS. 2 through 6, the device authentication operation can proceed as follows.

[0042] The first storage device (SSD1) and the second storage device (SSD2) share a blockchain ledger (S30). The first storage device (SSD1) can transmit an authentication request message to the second storage device (SSD2) (S31). The second storage device (SSD2) can sign the authentication request message with its private key in response to this authentication request (S33). The second storage device (SSD2) can transmit the signed certificate to the first storage device (SSD1) (S34). The first storage device (SSD1) can read the public key of the second storage device (SSD2) from the blockchain ledger (S36). The first storage device (SSD1) can decrypt the signed certificate using the public key of the second storage device (SSD2) (S37). Here, when verifying authentication-related information from the decrypted certificate, the first storage device (SSD1) can authenticate the second storage device (SSD2) as a legitimate connection device.

[0043] Meanwhile, in FIG. 6, device authentication is performed using a public key. However, the present invention is not limited thereto. A storage system according to an embodiment of the present invention may also perform device authentication using history information stored in a blockchain ledger.

[0044] FIG. 7 is a ladder diagram exemplarily showing a device authentication operation in a storage device of a storage system according to another embodiment of the present invention. Referring to FIGS. 2 through 5 and FIG. 7, the device authentication operation can proceed as follows.

[0045] The first storage device (SSD1) and the second storage device (SSD2) share a blockchain ledger (S40). The first storage device (SSD1) can transmit an authentication request message to the second storage device (SSD2) (S41). The second storage device (SSD2) can read its history information in response to this authentication request (S43). Here, this history information may include at least one of the device manufacturer, manufacturing date, capacity, S / N and firmware creation date, firmware version, firmware update date, firmware size, firmware hash value, measurement value during normal operation, SSD health status, and initial connection time.

[0046] The second storage device (SSD2) can transmit history information to the first storage device (SSD1) (S44). The first storage device (SSD1) can read the history information of the second storage device (SSD2) from the blockchain ledger (S46). The first storage device (SSD1) can compare the history information transmitted from the second storage device (SSD2) with the history information read from the blockchain ledger (S47). Here, when the history information matches as a result of the comparison, the first storage device (SSD1) can authenticate the second storage device (SSD2) as a legitimate connection device.

[0047] Meanwhile, the storage system (1000) according to an embodiment of the present invention may perform firmware qualification verification between devices.

[0048] FIG. 8 is a ladder diagram exemplarily showing a firmware update operation in a storage device of a storage system (1000) according to an embodiment of the present invention. Referring to FIGS. 2 through 8, after device authentication is completed, the firmware credential verification operation may proceed as follows.

[0049] The first storage device (SSD1) and the second storage device (SSD2) share a blockchain ledger (S50). The first storage device (SSD1) can request a measurement value (FWMV) for firmware credential verification from the second storage device (SSD2) (S51). The second storage device (SSD2) can execute the firmware to measure the value in response to this request for the measurement value (S53). The second storage device (SSD2) can transmit the measurement value (FWMV) to the first storage device (SSD1) (S54). The first storage device (SSD1) can read the measurement value of the second storage device (SSD2) from the blockchain ledger (S56). The first storage device (SSD1) can compare the measurement value read from the blockchain ledger with the measurement value transmitted from the second storage device (SSD2) (S57). Here, when the measurement value read from the blockchain ledger matches the measurement value transmitted from the second storage device (SSD2) or when the difference between them exists within a predetermined range, it can be determined that the firmware of the second storage device (SSD2) is operating normally.

[0050] Meanwhile, the storage system (1000) according to an embodiment of the present invention enables firmware updates between devices.

[0051] FIG. 9 is a ladder diagram exemplarily showing the firmware update operation of a storage system (1000) according to an embodiment of the present invention. Referring to FIGS. 2 through 9, the firmware update operation between devices can proceed as follows.

[0052] The first storage device (SSD1) and the second storage device (SSD2) share a blockchain ledger (S60). The first storage device (SSD1) can search the blockchain ledger for a target device having a firmware version to be updated (S61). If the target device is the second storage device (SSD2), the first storage device (SSD1) can transmit a firmware request to the second storage device (SSD2) (S62). The second storage device (SSD2) can perform device authentication of the first storage device (SSD1) in response to this firmware request (S63). Here, device authentication may utilize the device authentication method described in FIGS. 6 and 7. After device authentication is completed, the second storage device (SSD2) can transmit its firmware to the first storage device (SSD2) (S64). The first storage device (SSD1) can update its firmware using the firmware transmitted from the second storage device (SSD2) (S65). The blockchain ledger may be changed according to such firmware updates. The changed blockchain ledger can be shared among all devices within the blockchain (S66).

[0053] FIG. 10 is a diagram exemplarily showing the addition of a new device to a storage system according to an embodiment of the present invention. Referring to FIG. 10, the storage system (2000) has a structure in which a third storage device (SSD3, 1450) is added compared to the storage system (1000) shown in FIG. 1.

[0054] FIG. 11 is a diagram exemplarily showing a newly created blockchain block following the addition of a new storage device (SSD3) shown in FIG. 10.

[0055] Referring to FIG. 11, the newly created 101st blockchain block (33) stores values ​​corresponding to the third storage device (SSD3). The 101st blockchain block (33) may include a header and a payload. In an embodiment, the header may include the hash value of the previous 100th blockchain block (33) and the payload hash value of the current blockchain block (34). Here, the payload may include the serial number of the third storage device (SSD3), the public key of the third storage device (SSD3), the firmware version, the firmware update time, the hash value of the firmware, the measured value during normal operation of the firmware, the hash value of the third storage device (SSD3), etc.

[0056] Meanwhile, the storage device can be reconnected to the storage system after being detached for reasons such as parts replacement.

[0057] FIG. 12 is a diagram exemplarily showing the reconnection of one of the devices to a storage system (3000) according to an embodiment of the present invention. Referring to FIG. 12, the storage system (3000) may include a host device (3100), a switch device (3300), and first to fifth storage devices (3410 to 3450). For convenience of explanation, it will be assumed that the second storage device (SSD2, 3420) in the storage system (3000) is reconnected after being detached, as shown in FIG. 11.

[0058] In an embodiment, at least one of the first to fifth storage devices (3410 to 3450) may support offloading that performs some functions of the host device (3100).

[0059] Other devices (3100, 3300, 3410, 3430, 3440, 3450) within the blockchain may request authentication from the reconnected second storage device (SSD2, 3420). For example, the remaining devices (3100, 3300, 3410, 3430, 3440, 3450) may perform device authentication using the hash value of the payload of the Nth blockchain block corresponding to the second storage device (SSD2), as illustrated in FIG. 13. That is, by comparing the hash value of the payload of the second storage device (SSD2) stored in the blockchain ledger before reconnection with the hash value of the payload of the second storage device (SSD2) after reconnection, it can be determined whether the device is authenticated as a legitimate device.

[0060] FIG. 14 is a ladder diagram exemplarily illustrating the authentication operation of a device following the reconnection illustrated in FIG. 12. Referring to FIG. 12 through FIG. 14, the authentication operation of a reconnected storage device of a storage system (3000) can proceed as follows.

[0061] At least one of the host device (Host), switch device (SW), and storage devices (SSD1, SSD3, SSD4, SSD5) may request device information from the second storage device (SSD2) after detecting the reconnection of the second storage device (SSD2) (S71). The second storage device (SSD2) may transmit device information to at least one device in response to this device information request (S72). At least one device may read device information of the second storage device (SSD2) from a blockchain ledger (S73). At least one device may compare the device information read from the blockchain ledger with the device information transmitted from the second storage device (SSD2) (S74). As a result of the comparison, when the device information read from the blockchain ledger matches the device information transmitted from the second storage device (SSD2), the reconnected second storage device (SSD2) may be authenticated as a legitimate device connected to the storage system (3000).

[0062] FIG. 15 is a flowchart exemplarily illustrating the operation method of a storage system according to an embodiment of the present invention. Referring to FIG. 15, a host device can determine whether a new storage device (e.g., SSD3 shown in FIG. 10) is connected (S110). If the new device is not connected, the related connection detection operation may continue. If the new storage device (SSD3) is connected, the host device may request device information from the newly connected storage device (SSD3) (S120). The newly connected storage device (SSD3) may transmit its device information to all remaining devices. Subsequently, the host device and the remaining devices may verify the device information of the new storage device (SSD3) (S130). When the device verification operation of the new storage device (SSD3) is completed, information on the new storage device (SSD3) may be recorded in the blockchain ledger (S140). On the other hand, if the device verification operation of the new storage device (SSD3) is not completed, the device information of the new storage device is not recorded in the blockchain ledger (S150), and subsequently, the host device and the remaining devices can announce the results (S160).

[0063] FIG. 16 is a flowchart illustrating an exemplary method of operation of a storage system according to another embodiment of the present invention. Referring to FIG. 16, the firmware update process of a storage device of the storage system can be carried out as follows.

[0064] The storage device (SSD3) can determine whether a firmware update is necessary using a blockchain ledger (S210). If a firmware update is required for the storage device (SSD3), the storage device (SSD3) can check the latest firmware version of another device (e.g., SSD2) on the blockchain (S220). The storage device (SSD3) can request the target firmware from the other device (SSD2) (S230). The other device (SSD2) can send an authentication request message to the storage device (SSD3) (S240). The storage device (SSD3) can transmit device information corresponding to the authentication request to the other device (SSD2). The other device (SSD2) can determine whether the device information transmitted from the storage device (SSD3) matches the information of the storage device (SSD3) recorded in the blockchain ledger (S250). If the information transmitted from the storage device (SSD3) matches the information of the storage device (SSD3) recorded in the blockchain ledger, another device (SSD2) can transmit target firmware to the storage device (SSD30) (S260). On the other hand, if the information transmitted from the storage device (SSD3) does not match the information of the storage device (SSD3) recorded in the blockchain ledger, the remaining devices can announce this fact (S270).

[0065] FIG. 17 is a flowchart exemplarily illustrating a method of operation of a storage system according to another embodiment of the present invention. Referring to FIGS. 2 through 17, the firmware credential verification operation of the storage system may proceed as follows.

[0066] One of the internal devices of the storage system may perform authentication of the storage device using a blockchain (S310). In an embodiment, an authentication operation may be performed by transmitting an authentication request message to the storage device through a switch device, receiving a certificate signed in the authentication request message using a private key from the storage device through the switch device, reading the public key of the storage device stored in the blockchain ledger, and decrypting the certificate signed using the public key. After such device authentication, one of the devices may perform credential verification for the normal operation of the firmware using a blockchain (S320). In an embodiment, a firmware measurement value may be requested from the storage device through a switch device, receiving a firmware measurement value corresponding to the request from the storage device through the switch device, reading the firmware measurement value of the storage device stored in the blockchain ledger, and comparing the read firmware measurement value with the received firmware measurement value.

[0067] In an embodiment, the host device can monitor whether to make an additional connection or reconnect to the switch device of the storage device. In an embodiment, when there is an additional connection or reconnection to the switch device of the storage device, a new blockchain block is created, and the created blockchain block can be combined with the blockchain.

[0068] Meanwhile, the storage device according to an embodiment of the present invention may be implemented to perform some of the functions of the host device.

[0069] FIG. 18 is a drawing illustrating an exemplary computing system (20) in an embodiment of the present invention. Referring to FIG. 18, the computing system (20) of the present invention may include a host device (21) and a smart storage device (22).

[0070] The host device (21) may include a central processing unit (CPU, 21-2), a volatile memory device (DRAM, 21-3), and an interface circuit (21-4) connected to a system bus (21-1).

[0071] The smart storage device (22) may include a central processing unit (22-2) connected to a bus (22-1), a buffer memory (SRAM, 22-3), a volatile memory device (DRAM, 22-4), a non-volatile memory device (NAND, 22-5), an arithmetic processing unit (FPGA, 22-6), and an interface circuit (22-7).

[0072] FIG. 19 is a drawing illustrating an exemplary storage device (30) according to an embodiment. Referring to FIG. 19, the storage device (30) may include at least one non-volatile memory device (NVM(s), 100) and a controller (CTRL, 200).

[0073] At least one non-volatile memory device (100) may be implemented to store data. The non-volatile memory device (100) may be a NAND flash memory, a vertical NAND flash memory, a NOR flash memory, a resistive random access memory (RRAM), a phase-change memory (PRAM), a magnetoresistive random access memory (MRAM), a ferroelectric random access memory (FRAM), a spin transfer torque random access memory (STT-RAM), etc. Additionally, the non-volatile memory device (100) may be implemented as a three-dimensional array structure. The present invention is applicable to both flash memory devices in which the charge storage layer is composed of a conductive floating gate, as well as charge trap flash (CTF) devices in which the charge storage layer is composed of an insulating film. For convenience of explanation below, the non-volatile memory device (100) will be referred to as a vertical NAND flash memory device (VNAND).

[0074] Additionally, the non-volatile memory device (100) may be implemented to include a plurality of memory blocks (BLK1 to BLKz, where z is an integer of 2 or more) and control logic (150). Each of the plurality of memory blocks (BLK1 to BLKz) may include a plurality of pages (Page 1 to Page m, where m is an integer of 2 or more). Each of the plurality of pages (Page 1 to Page m) may include a plurality of memory cells. Each of the plurality of memory cells may store at least one bit.

[0075] In an embodiment, at least one of the plurality of memory blocks (BLK1 to BLKz) may be implemented to store the blockchain ledger described in FIGS. 1 to 18.

[0076] The control logic (150) can be implemented to receive a command and an address from a controller (CTRL; 200) and to perform an operation (program operation, read operation, erase operation, etc.) corresponding to the received command on memory cells corresponding to the address.

[0077] A controller (CTRL; 200) may be connected to at least one non-volatile memory device (100) through a plurality of control pins that transmit control signals (e.g., CLE, ALE, CE(s), WE, RE, etc.). Additionally, it may be implemented to control the non-volatile memory device (100) using the control signals (CLE, ALE, CE(s), WE, RE, etc.). For example, the non-volatile memory device (100) may perform program operation / read operation / erase operation by latching a command or address at the edge of the WE (write enable) / RE (read enable) signal according to the CLE (command latch enable) signal and the ALE (address latch enable) signal. For example, during a read operation, the chip enable signal (CE) is activated, CLE is activated during the command transmission period, ALE is activated during the address transmission period, and RE may be toggled during the period in which data is transmitted through the data signal line (DQ). The data strobe signal (DQS) can be toggled at a frequency corresponding to the data input / output rate. Read data can be transmitted sequentially synchronized with the data strobe signal (DQS).

[0078] In an embodiment, the controller (200) may be implemented to receive a device authentication request message from an external device (e.g., a host device, another storage device, a switch device), read a blockchain ledger from at least one non-volatile memory device (100), and transmit authentication information corresponding to the blockchain ledger to the external device in response to the device authentication request.

[0079] In an embodiment, the authentication information includes a value in which an authentication request message is signed with the private key of the storage device (30), and the private key of the storage device may correspond to the public key of the storage device stored in the blockchain ledger. In another embodiment, the authentication information may include device information of the storage device (30) stored in the blockchain ledger. In an embodiment, the controller (200) may perform an authentication operation for another device using the blockchain ledger. In an embodiment, the controller (200) may perform a credential verification operation for the firmware of another device using the blockchain ledger.

[0080] Additionally, the controller (200) may include at least one processor (CPU (Central Processing Unit)(s); 210), and a buffer memory (220).

[0081] A processor (210) may be implemented to control the overall operation of a storage device (30). The processor (210) may perform various management operations such as cache / buffer management, firmware management, garbage collection management, wear leveling management, data deduplication management, read refresh / reclaim management, bad block management, multi-stream management, mapping management of host data and non-volatile memory, Quality of Service (QoS) management, system resource allocation management, non-volatile memory queue management, read level management, erase / program management, hot / cold data management, power loss protection management, dynamic thermal management, initialization management, and Redundant Array of Inexpensive Disks (RAID) management.

[0082] The processor (210) may be implemented to run firmware. The processor (210) may read a blockchain ledger from a non-volatile memory device (100) and use the blockchain ledger to perform device authentication operations, firmware credentialing operations, or firmware update operations as described in FIGS. 2 through 18.

[0083] The buffer memory (220) can be implemented as volatile memory (e.g., SRAM (Static Random Access Memory), DRAM (Dynamic RAM), SDRAM (Synchronous RAM), etc.) or non-volatile memory (flash memory, PRAM (Phase-change RAM), MRAM (Magneto-resistive RAM), ReRAM (Resistive RAM), FRAM (Ferro-electric RAM), etc.).

[0084] FIG. 20 is a diagram illustrating an exemplary controller (200) according to an embodiment of the present invention. Referring to FIG. 20, the controller (200) may include a host interface (201), a memory interface (202), at least one CPU (210), a buffer memory (220), an error correction circuit (230), a flash conversion layer manager (240), a packet manager (250), and a security module (260).

[0085] A host interface (201) may be implemented to transmit and receive packets to and from a host. A packet transmitted from the host to the host interface (201) may contain a command or data to be written to a non-volatile memory device (100). A packet transmitted from the host interface (201) to the host may contain a response to a command or data read from a non-volatile memory device (100). A memory interface (202) may transmit data to be written to a non-volatile memory device (100) to the non-volatile memory device (100) or receive data read from a non-volatile memory device (100). Such a memory interface (202) may be implemented to comply with standard protocols such as JEDEC Toggle or ONFI (Open NAND Flash Interface).

[0086] The buffer memory (220) can temporarily store data to be written to the non-volatile memory device (100) or data read from the non-volatile memory device (100). In an embodiment, the buffer memory (220) may be a configuration provided within the controller (200). In another embodiment, the buffer memory (220) may be placed outside the controller (200).

[0087] The ECC circuit (230) can be implemented to generate an error correction code during program operation and to recover data using the error correction code during read operation. That is, the ECC circuit (230) can generate an error correction code (ECC) to correct a fail bit or an error bit of data received from the non-volatile memory device (100). The ECC circuit (230) can form data (DATA) with a parity bit added by performing error correction encoding of the data provided to the non-volatile memory device (100). The parity bit can be stored in the non-volatile memory device (100).

[0088] Additionally, the ECC circuit (230) can perform error correction decoding on data (DATA) output from the non-volatile memory device (100). The ECC circuit (230) can correct errors using parity. The ECC circuit (230) can correct errors using coded modulations such as LDPC (Low Density Parity Check) code, BCH code, Turbo code, Reed-Solomon code, Convolution code, RSC (Recursive Systematic Code), TCM (Trellis-Coded Modulation), and BCM (Block Coded Modulation). Meanwhile, when error correction is not possible in the error correction circuit (230), a read retry operation may be performed.

[0089] The flash conversion layer manager (240) can perform various functions such as address mapping, wear-leveling, and garbage collection. Address mapping is an operation that converts a logical address received from a host into a physical address used to actually store data within the non-volatile memory device (100). Wear-leveling is a technique to prevent excessive degradation of a specific block by ensuring that blocks within the non-volatile memory device (100) are used uniformly, and can be implemented, for example, through firmware technology that balances the erase counts of physical blocks. Garbage collection is a technique to secure usable capacity within the non-volatile memory device (100) by erasing the existing block after copying the valid data of the block to a new block.

[0090] The packet manager (250) can generate packets according to the protocol of the interface agreed upon with the host, or parse various information from packets received from the host.

[0091] The security module (260) can perform at least one of the encryption and decryption operations on data input to the CPU (210) using a symmetric-key algorithm. The security module (260) may include an encryption module and a decryption module. In an embodiment, the security module (260) may be implemented in hardware, software, or firmware. Additionally, the security module (260) may be implemented to perform authentication operations with an external device or to perform a fully homomorphic encryption function.

[0092] The security module (260) may be implemented to perform security functions for the storage device (30). For example, the security module (260) may perform a Self Encryption Disk (SED) function or a Trusted Computing Group (TCG) security function. The SED function may store encrypted data in the non-volatile memory device (100) or decrypt encrypted data from the non-volatile memory device (100) using a cryptographic algorithm. These encryption / decryption operations may be performed using an internally generated encryption key. In an embodiment, the cryptographic algorithm may be the Advanced Encryption Standard (AES) cryptographic algorithm. Meanwhile, it should be understood that the cryptographic algorithm is not limited thereto. The TCG security function may provide a mechanism that enables access control to user data of the storage device (30). For example, the TCG security function may perform an authentication procedure between an external device and the storage device (30). In an embodiment, the SED function or the TCG security function may be optionally selected.

[0093] Meanwhile, the storage device of the present invention is applicable to a data server system.

[0094] FIG. 21 is a diagram illustrating an exemplary data center to which a memory device according to an embodiment of the present invention is applied. Referring to FIG. 21, the data center (7000) may include application servers (7100 to 7100n) and storage servers (7200 to 7200m). The number of application servers (7100 to 7100n) and the number of storage servers (7200 to 7200m) may be selected in various ways according to the embodiment, and the number of application servers (7100 to 7100n) and the number of storage servers (7200 to 7200m) may differ from each other.

[0095] The application server (7100) or storage server (7200) may include at least one of a processor (7110, 7210) and memory (7120, 7220). To describe the storage server (7200) as an example, the processor (7210) can control the overall operation of the storage server (7200) and can access the memory (7220) to execute instructions or data loaded into the memory (7220). The memory (7220) may be DDR SDRAM (Double Data Rate Synchronous DRAM), HBM (High Bandwidth Memory), HMC (Hybrid Memory Cube), DIMM (Dual In-line Memory Module), Optane DIMM, or NVMDIMM (Non-Volatile DIMM). Depending on the embodiment, the number of processors (7210) and the number of memory (7220) included in the storage server (7200) may be selected in various ways. In an embodiment, the processor (7210) and memory (7220) may provide a processor-memory pair. In an embodiment, the number of processors (7210) and memory (7220) may differ. The processor (7210) may include a single-core processor or a multi-core processor. The above description of the storage server (7200) may similarly apply to the application server (7100). Depending on the embodiment, the application server (7100) may not include a storage device (7150). The storage server (7200) may include at least one storage device (7250). The number of storage devices (7250) included in the storage server (7200) may be selected differently depending on the embodiment.

[0096] Application servers (7100 to 7100n) and storage servers (7200 to 7200m) can communicate with each other through a network (7300). The network (7300) can be implemented using a Fiber Channel (FC) or Ethernet, etc. In this case, the FC is a medium used for relatively high-speed data transmission, and an optical switch device that provides high performance / high availability can be used. Depending on the access method of the network (7300), the storage servers (7200 to 7200m) can be provided as file storage media, block storage media, or object storage media.

[0097] In an embodiment, the network (7300) may be a storage-only network such as a Storage Area Network (SAN). For example, the SAN may be an FC-SAN that uses an FC network and is implemented according to the FC Protocol (FCP). In another example, the SAN may be an IP-SAN that uses a TCP / IP network and is implemented according to the iSCSI (SCSI over TCP / IP or Internet SCSI) protocol. In another embodiment, the network (7300) may be a general network such as a TCP / IP network. For example, the network (7300) may be implemented according to protocols such as FC over Ethernet (FCoE), Network Attached Storage (NAS), and NVMe over Fabrics (NVMe-oF). The description of the application server (7100) may also apply to other application servers (7100n), and the description of the storage server (7200) may also apply to other storage servers (7200m).

[0098] The application server (7100) can store data requested for storage by a user or client in one of the storage servers (7200 to 7200m) via the network (7300). Additionally, the application server (7100) can obtain data requested for reading by a user or client from one of the storage servers (7200 to 7200m) via the network (7300). For example, the application server (7100) can be implemented as a web server or a DBMS (Database Management System).

[0099] The application server (7100) can access memory (7120n) or storage device (7150n) contained in another application server (7100n) through the network (7300), or can access memory (7220 ~ 7220m) or storage device (7250 ~ 7250m) contained in a storage server (7200 ~ 7200m) through the network (7300). By doing so, the application server (7100) can perform various operations on data stored in the application servers (7100 ~ 7100n) or storage servers (7200 ~ 7200m). For example, the application server (7100) can execute a command to move or copy data between the application servers (7100 ~ 7100n) or storage servers (7200 ~ 7200m). At this time, data can be moved from the storage devices (7250 ~ 7250m) of the storage servers (7200 ~ 7200m) through the memories (7220 ~ 7220m) of the storage servers (7200 ~ 7200m), or directly to the memories (7120 ~ 7120n) of the application servers (7100 ~ 7100n). Data moving through the network (7300) may be encrypted data for security or privacy.

[0100] To illustrate with the storage server (7200) as an example, the interface (7254) can provide a physical connection between the processor (7210) and the controller (7251) and a physical connection between the NIC (7240) and the controller (7251). For example, the interface (7254) can be implemented in a Direct Attached Storage (DAS) manner, which directly connects the storage device (7250) with a dedicated cable. In addition, for example, the interface (1254) can be implemented in various interface methods such as ATA (Advanced Technology Attachment), SATA (Serial ATA), e-SATA (external SATA), SCSI (Small Computer Small Interface), SAS (Serial Attached SCSI), PCI (Peripheral Component Interconnection), PCIe (PCI express), NVMe (NVM express), IEEE 1394, USB (universal serial bus), SD (secure digital) card, MMC (multi-media card), eMMC (embedded multi-media card), UFS (Universal Flash Storage), eUFS (embedded Universal Flash Storage), CF (compact flash) card interface, etc.

[0101] The storage server (7200) may further include a switch device (7230) and a NIC (7240). The switch device (7230) may selectively connect the processor (7210) and the storage device (7250) or selectively connect the NIC (7240) and the storage device (7250) under the control of the processor (7210).

[0102] In the embodiment, the NIC (7240) may include a network interface card, a network adapter, etc. The NIC (7240) may be connected to a network (7300) by a wired interface, a wireless interface, a Bluetooth interface, an optical interface, etc. The NIC (7240) may include internal memory, a DSP, a host bus interface, etc., and may be connected to a processor (7210) or a switch device (7230), etc., through the host bus interface. The host bus interface may be implemented as one of the examples of the interface (7254) described above. In the embodiment, the NIC (7240) may be integrated with at least one of the processor (7210), the switch device (7230), and the storage device (7250).

[0103] In a storage server (7200 ~ 7200m) or application server (7100 ~ 7100n), the processor can program or read data by transmitting commands to a storage device (7130 ~ 7130n, 7250 ~ 7250m) or memory (7120 ~ 7120n, 7220 ~ 7220m). At this time, the data may be data that has been error-corrected through an ECC (Error Correction Code) engine. The data may be data that has undergone Data Bus Inversion (DBI) or Data Masking (DM) processing and may include Cyclic Redundancy Code (CRC) information. The data may be data that has been encrypted for security or privacy.

[0104] The storage device (7150 ~ 7150m, 7250 ~ 7250m) can transmit control signals and command / address signals to the NAND flash memory device (7252 ~ 7252m) in response to a read command received from the processor. Accordingly, when reading data from the NAND flash memory device (7252 ~ 7252m), the RE (Read Enable) signal is input as a data output control signal and can serve to output data to the DQ bus. A DQS (Data Strobe) can be generated using the RE signal. The command and address signals can be latched in the page buffer depending on the rising edge or falling edge of the WE (Write Enable) signal.

[0105] In an embodiment, the storage device (7150 ~ 7150m, 7250 ~ 7250m) can perform device authentication / firmware credentialing / firmware updates using a blockchain as described in FIGS. 2 to 18.

[0106] The controller (7251) can control the overall operation of the storage device (7250). In an embodiment, the controller (7251) may include a Static Random Access Memory (SRAM). The controller (7251) can write data to the NAND flash (7252) in response to a write command, or read data from the NAND flash (7252) in response to a read command. For example, the write command or the read command may be provided by a processor (7210) in a storage server (7200), a processor (7210m) in another storage server (7200m), or a processor (7110, 7110n) in an application server (7100, 7100n). The DRAM (7253) can temporarily store (buffer) data to be written to the NAND flash (7252) or data read from the NAND flash (7252). Additionally, the DRAM (7253) can store metadata. Here, the metadata is data generated by the controller (7251) to manage user data or the NAND flash (7252).

[0107] A storage device according to an embodiment of the present invention may include a non-volatile memory device that stores a blockchain ledger containing information of the storage device, and a controller that reads and writes the blockchain ledger from the non-volatile memory device. In an embodiment, the controller may request device information from an external device and process the corresponding value and the information of the external device recorded in the blockchain ledger. In an embodiment, the information stored in the blockchain ledger may include a Public Key. The controller may receive a private key signature from the external device and use the public key of the external device stored in the blockchain ledger to decrypt the signed certificate, thereby authenticating that the external device is a legitimate device.

[0108] In an embodiment, the information stored in the blockchain ledger may include measurement values ​​of firmware operations executed on multiple devices. In an embodiment, the controller may request measurement values ​​during firmware operation from an external device and determine whether they match by comparing the measurement values ​​received from the external device with the firmware measurement values ​​during normal operation of the corresponding external device recorded in the blockchain ledger.

[0109] A storage system according to an embodiment of the present invention may include SSD1 having a blockchain ledger and SSD2 having a blockchain ledger. Here, information of SSD1 and SSD2 may be stored in the blockchain ledger. In an embodiment, SSD1 may request information from SSD2, and SSD2 may transmit the corresponding value to SSD1. In an embodiment, SSD1 may read information of SSD2 from the blockchain ledger and process the read information and the information received from SSD2. In an embodiment, the information stored in the blockchain ledger may include a public key. In an embodiment, SSD1 may receive a private key signature from SSD2 and authenticate that it is SSD2 by decrypting the signature using the public key of SSD2 stored in the blockchain. In an embodiment, the information stored in the blockchain ledger may include measurement values ​​during F / W operations executed on multiple devices. In an embodiment, SSD1 may request measurement values ​​during F / W operations from SSD2 and determine whether they match by reading the received measurement values ​​and the F / W measurement values ​​during normal operation of SSD2 recorded in the blockchain.

[0110] The device described above may be implemented as a hardware component, a software component, and / or a combination of a hardware component and a software component. For example, the device and components described in the embodiments may be implemented using one or more general-purpose or special-purpose computers, such as a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing unit may execute an operating system (OS) and one or more software applications executed on said operating system. Additionally, the processing unit may access, store, manipulate, process, and generate data in response to the execution of the software. For ease of understanding, the processing unit may be described as being used as a single unit, but those skilled in the art will understand that the processing unit may include multiple processing elements or multiple types of processing elements. For example, the processing unit may include multiple processors or one processor and one controller. In addition, other processing configurations, such as parallel processors, are also possible.

[0111] Software may include computer programs, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired or instruct the processing unit independently or collectively. Software and / or data may be embodied in any type of machine, component, physical device, virtual equipment, computer storage medium, or device so as to be interpreted by the processing unit or to provide instructions or data to the processing unit. Software may be distributed over networked computer systems and may be stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

[0112] Meanwhile, the above-described contents of the present invention are merely specific embodiments for carrying out the invention. The present invention will include not only the concrete and practically usable means themselves, but also technical ideas, which are abstract and conceptual ideas that can be utilized as technology in the future. Explanation of the symbols

[0113] 30: Storage device 100: Non-volatile memory device 200: Controller 210: Central Processing Unit 220: Buffer memory 1000, 2000, 3000: Storage system 1100: Host 1300: Switch device 1410 ~ 1440: Device

Claims

Claim 1 A method of operating a storage device comprising: transmitting an authentication request message to another storage device; receiving a certificate signed with the private key of the other storage device from the other storage device; reading the public key of the other storage device from a blockchain ledger; and decrypting the signed certificate with the public key, wherein the storage device shares the blockchain ledger with the other storage device independently from a host. Claim 2 A method according to claim 1, further comprising the step of the storage device and the other storage device sharing the blockchain ledger. Claim 3 A method according to claim 2, further comprising the step of storing the shared blockchain ledger in a non-volatile memory device from the other storage device. Claim 4 A method according to claim 1, characterized in that the storage device and the other storage device communicate through a peer-to-peer interface. Claim 5 A method according to claim 1, further comprising the step of performing a qualification verification for the firmware of the other storage device in the storage device. Claim 6 In claim 5, the step of performing the qualification verification comprises: requesting a measurement value according to the operation of the firmware from the other storage device; receiving the firmware measurement value from the other storage device; reading the measurement value of the other storage device from the blockchain ledger; and comparing the read measurement value with the received measurement value. Claim 7 A method according to claim 6, characterized in that when the read measurement value and the received measurement value match, it is determined that the firmware of the other storage device is operating normally. Claim 8 A method according to claim 6, characterized in that when the difference between the read measurement value and the received measurement value exists within a predetermined range, the firmware of the other storage device is determined to be operating normally. Claim 9 A method according to claim 1, further comprising the step of searching for a target device having target firmware in the blockchain ledger. Claim 10 A method according to claim 9, further comprising the steps of: requesting target firmware from the target device; performing authentication with the target device; receiving the target firmware from the target device after performing authentication of the target device; and updating the target firmware. Claim 11 A method according to claim 10, further comprising the step of sharing a new blockchain ledger reflecting the updated firmware with the storage device, the other storage device, and the target device. Claim 12 A storage device comprising: at least one non-volatile memory device having a plurality of memory blocks having a plurality of memory cells connected to word lines and bit lines, and storing a blockchain ledger in at least one of the plurality of memory blocks; and a controller controlling the at least one non-volatile memory device; wherein the controller receives an authentication request message from an external device, independently of a host, refers to the blockchain ledger to transmit authentication information corresponding to the authentication request message to the external device, and performs an authentication operation for another device using the blockchain ledger. Claim 13 A storage device according to claim 12, wherein the authentication information includes a value in which an authentication request message is signed with the private key of the storage device, and the private key of the storage device corresponds to the public key of the storage device stored in the blockchain ledger. Claim 14 A storage device according to claim 12, characterized in that the authentication information includes device information of the storage device stored in the blockchain ledger. Claim 15 A storage device according to claim 12, characterized in that the controller performs a credential verification operation for the firmware of another device using the blockchain ledger. Claim 16 A storage system comprising: a first storage device for storing a blockchain ledger; and a second storage device for storing the blockchain ledger shared with the first storage device, wherein the first storage device transmits an authentication request message to the second storage device, receives a certificate corresponding to the authentication request message from the second storage device, reads the public key of the second storage device from the blockchain ledger independently from a host, and authenticates the second storage device by decrypting the certificate using the public key. Claim 17 A storage system according to claim 16, wherein the second storage device receives the authentication request message from the first storage device and generates the certificate by signing the authentication request message using the private key of the second storage device. Claim 18 A storage system according to claim 16, characterized in that the first storage device performs credential verification of firmware running on the second storage device using the blockchain ledger. Claim 19 A storage system according to claim 16, wherein the first storage device transmits a firmware request message to the second storage device, receives firmware corresponding to the firmware request message from the second storage device, and updates the firmware. Claim 20 A storage system according to claim 16, wherein the first storage device monitors whether the second storage device is reconnected, and performs authentication of the second storage device using the blockchain ledger when the second storage device is reconnected.

Images