Patent Description:
A semiconductor memory device may be classified as a volatile memory, which loses data stored therein when a power supply is turned off (e.g., a dynamic random access memory (DRAM) or a static RAM (SRAM)), or a nonvolatile memory, which retains data stored therein even when a power supply is turned off (e.g., a flash memory, a phase-change RAM (PRAM), a magnetic RAM (MRAM), resistive RAM (ReRAM), or a ferroelectric random access memory (FRAM)).

A flash memory-based solid state drive (SSD) is widely used as a high-capacity storage medium. In general, an SSD communicates with a host through a given interface and a cryptographic key. For example, an SSD may be configured to encode data received from a host with a given cryptographic key and to store the encoded data.

<CIT> discloses: Systems and methods for using encryption keys to manage data retention include receiving data such as user data from a host of the storage drive, encrypting the data using an encryption key, writing the encrypted data to the storage drive, and retaining the encrypted data on the storage drive based at least in part on a validity of the encryption key.

<CIT> discloses: Periodically re-encrypting user data stored on a storage device, including: reading user data stored on the storage device, wherein the user data is associated with a user-visible identifier; determining, from metadata associated with the user data, whether the user data is encrypted utilizing an expiring data encryption key; responsive to determining that the user data is encrypted utilizing the expiring data encryption key, re-encrypting the user data utilizing a current data encryption key; and writing the user data that is encrypted with the current data encryption key to the storage device, wherein the user data remains associated with the user-visible identifier.

<CIT> B <NUM> discloses: Secure information is managed for each host or machine in an electronic environment using cryptographic keys. A globally distributed system manages and rotates keys across various nodes within the system based on a predetermined schedule of each key's lifecycle. The predetermined schedule decides when keys are created, distributed, and used with respect to each key's pre-assigned time (e.g., an expiration time, a creation time). The schedule of the key's lifecycle may be predetermined and adjusted based on various system requirements. The keys may be automatically rotated throughout the various nodes in the system in a way such that the keys are not unnecessarily exposed for too long but are accessible to the ciphertext producers and the ciphertext consumers when needed. Further, the keys are created and rotated in a way to ensure robustness of the system in the event of a global WAN outage or network partition.

Embodiments of the invention are defined in the appended claims. Embodiments of the present disclosure provide a storage device capable of preventing data loss and leakage even when a host is hacked, and an operation method thereof.

According to an embodiment, an operation method of a storage device which includes a nonvolatile memory device and is configured to communicate with a host based on a cryptographic key may include setting up a first key identifier and a first lifetime of a first cryptographic key based on a first command received from the host, and after the first lifetime is expires, when a second command including the first key identifier is received from the host, performing a data protect operation with regard to the first cryptographic key.

Embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. Like reference numerals may refer to like elements throughout the accompanying drawings
Components that are described in the detailed description with reference to the terms "driver", "block", etc. may be implemented with software, hardware, or a combination thereof. For example, the software may be a machine code, firmware, an embedded code, and application software. For example, the hardware may include an electrical circuit, an electronic circuit, a processor, a computer, integrated circuit cores, a pressure sensor, a micro electromechanical system (MEMS), a passive element, or a combination thereof.

It will be understood that the terms "first," "second," "third," etc. are used herein to distinguish one element from another, and the elements are not limited by these terms. Thus, a "first" element in an embodiment may be described as a "second" element in another embodiment.

It should be understood that descriptions of features or aspects within each embodiment should typically be considered as available for other similar features or aspects in other embodiments, unless the context clearly indicates otherwise.

<FIG> is a block diagram illustrating a storage system according to an embodiment of the present disclosure.

Referring to <FIG>, a storage system <NUM> may include a host <NUM> and a storage device <NUM>. In an embodiment, the storage system <NUM> may include at least one of various information processing devices such as, for example, a personal computer, a laptop computer, a server, a workstation, a smartphone, and a tablet PC.

The host <NUM> may access the storage device <NUM>. For example, the host <NUM> may send a command to the storage device <NUM> to store data in the storage device <NUM> or to read data stored in the storage device <NUM>.

The storage device <NUM> may include a storage controller <NUM> and a nonvolatile memory device <NUM>. The storage device <NUM> may operate under control of the host <NUM>. For example, based on a command issued from the host <NUM>, the storage controller <NUM> may store data in the nonvolatile memory device <NUM> or may read data from the nonvolatile memory device <NUM>.

In an embodiment, the storage device <NUM> may communicate with the host <NUM> based on, for example, a Peripheral Component Interconnect express (PCI-express) interface or a PCI-express based Nonvolatile Memory Express (NVMe) interface. However, embodiments of the present disclosure are not limited thereto. For example, the storage device <NUM> and the host <NUM> may be implemented with various interfaces such as, for example, an Advanced Technology Attachment (ATA) interface, a Serial ATA (SATA) interface, an external SATA (e-SATA) interface, a Small Computer Small Interface (SCSI), a Serial Attached SCSI (SAS) interface, a Peripheral Component Interconnection (PCI) interface, an IEEE <NUM> interface, a Universal Serial Bus (USB) interface, a Secure Digital (SD) card interface, a Multi-Media Card (MMC) interface, an embedded Multi-Media Card (eMMC) interface, a Universal Flash Storage (UFS) interface, an embedded Universal Flash Storage (eUFS) interface, and a Compact Flash (CF) card interface.

The storage controller <NUM> may communicate with the host <NUM> by using a cryptographic key. For example, the storage controller <NUM> may include a cryptographic module <NUM>. Based on the cryptographic key, the cryptographic module <NUM> may encode data to be stored in the nonvolatile memory device <NUM> or may decode data read from the nonvolatile memory device <NUM>.

For example, the storage controller <NUM> may receive raw data from the host <NUM>. The cryptographic module <NUM> may encode the received raw data with the cryptographic key, and the storage controller <NUM> may store the encoded data in the nonvolatile memory device <NUM>. The cryptographic module <NUM> may decode data read from the nonvolatile memory device <NUM>, and the storage controller <NUM> may provide the decoded data (e.g., raw data) to the host <NUM>.

In an embodiment, the storage controller <NUM> may communicate with the host <NUM> based on a plurality of cryptographic keys. In this case, the plurality of cryptographic keys may be different from each other. The plurality of cryptographic keys may respectively correspond to different regions of the nonvolatile memory device <NUM>.

The host <NUM> may determine a lifetime of a cryptographic key. That is, the storage controller <NUM> may set up a lifetime of a cryptographic key under control of the host <NUM>. For example, the storage device <NUM> may include a security module <NUM>. The security module <NUM> may set up a lifetime of each of a plurality of cryptographic keys under control of the host <NUM>. The security module <NUM> may allow the storage controller <NUM> to perform a data protect operation on a cryptographic key whose lifetime expires.

For example, a first command (e.g., a read command or a write command) provided from the host <NUM> to the storage controller <NUM> may include a first key identifier (Key ID) corresponding to the first cryptographic key. In this case, the security module <NUM> may identify the first cryptographic key corresponding to the first key identifier included in the first command. The security module <NUM> may determine whether a lifetime of the first cryptographic key that has been identified expires. That is, the security module <NUM> may determine whether the lifetime of the first cryptographic key related to the first command received from the host <NUM> expires.

When it is determined that the lifetime of the first cryptographic key does not expire, the security module <NUM> may allow the storage controller <NUM> to perform a normal operation. In this case, the cryptographic module <NUM> may encode or decode data by using the first cryptographic key. The storage controller <NUM> may store the encoded data in the nonvolatile memory device <NUM> or may send the decoded data to the host <NUM>.

However, when it is determined that the lifetime of the first cryptographic key expires, the security module <NUM> may allow the storage controller <NUM> to return an error or a dummy response to the first command. In this case, even in a case in which, for example, the host <NUM> is hacked, data stored in the storage device <NUM> may be protected.

For example, when the first command is the read command, the storage controller <NUM> may return an error or garbage data to the host <NUM>. In this case, the garbage data may not be related to data stored in the nonvolatile memory device <NUM> or may be randomly generated data. In contrast, when the first command is the write command, the storage controller <NUM> may return an error to the host <NUM>, or the storage controller <NUM> may return a completion acknowledgment to the host <NUM> and may not write data in the nonvolatile memory device <NUM>. As in the above description, when the first command is an erase command, the storage controller <NUM> may return an error to the host <NUM>, or the storage controller <NUM> may return a completion acknowledgment to the host <NUM> and may not erase stored data in the nonvolatile memory device <NUM>.

That is, as the storage device <NUM> returns an error or a dummy response to the hacked host, data stored in the nonvolatile memory device <NUM> may be protected. Accordingly, according to an embodiment of the present disclosure, the security of the storage device <NUM> may be increased. A configuration of the security module <NUM> and an operation of the storage device <NUM> will be described in detail with reference to the following drawings.

<FIG> is a block diagram illustrating a storage controller of <FIG> according to an embodiment of the present disclosure.

Referring to <FIG> and <FIG>, the storage controller <NUM> may include the cryptographic module <NUM>, the security module <NUM>, a processor <NUM>, a host interface layer <NUM>, a volatile memory device <NUM>, and a nonvolatile memory device interface <NUM>. The security module <NUM>, the processor <NUM>, the host interface layer <NUM>, the volatile memory device <NUM>, and the nonvolatile memory device interface <NUM> may be connected to each other via a bus.

The processor <NUM> may control an overall operation of the storage controller <NUM>. For example, the processor <NUM> may execute various applications (e.g., a flash translation layer (FTL)) on the storage controller <NUM>.

The storage controller <NUM> may communicate with the host <NUM> through the host interface layer <NUM>. In an embodiment, the host interface layer <NUM> may include at least one of various host interfaces such as, for example, a Peripheral Component Interconnect express (PCI-express) interface, a nonvolatile memory express (NVMe) interface, a Serial ATA (SATA) interface, a Serial Attached SCSI (SAS) interface, and a Universal Flash Storage (UFS) interface. For brevity of description, below, it is assumed that the host interface layer <NUM> communicates with the host <NUM> based on the PCI-express interface.

The volatile memory device <NUM> may be used as, for example, a working memory, a buffer memory, or a cache memory of the storage controller <NUM>. For example, the volatile memory device <NUM> may be implemented with a static random access memory (SRAM) or a dynamic random access memory (DRAM).

The storage controller <NUM> may communicate with the nonvolatile memory device <NUM> through the nonvolatile memory device interface <NUM>. For example, the nonvolatile memory device interface <NUM> may be a NAND interface.

The security module <NUM> may set up, store, and manage a lifetime of a cryptographic key that is used for communication with the host <NUM>. For example, the security module <NUM> may include key storage 112a, a timer 112b, and a key manager 112c.

The key storage 112a may store a variety of information related to a cryptographic key that is used for communication with the host <NUM>. For example, the key storage 112a may store a cryptographic key, a key identifier (Key ID) for the cryptographic key, and information about a lifetime of the cryptographic key.

In an embodiment, the key identifier may be used to call the corresponding cryptographic key. For example, the host <NUM> may send various types of commands, such as a read command and a write command, to the storage device <NUM>. In this case, the host <NUM> may include the corresponding key identifier instead of directly including the cryptographic key in the command to be sent. The storage device <NUM> may perform various operations (e.g., a read operation and a write operation) on the nonvolatile memory device <NUM> based on the key identifier included in the command provided from the host <NUM> and the corresponding cryptographic key. For example, based on the command from the host <NUM>, the storage controller <NUM> may store data encoded through the cryptographic module <NUM> in the nonvolatile memory device <NUM> or may return data decoded through the cryptographic module <NUM> to the host <NUM>.

The timer 112b may measure a time that passes from a point in time when a lifetime of a cryptographic key is set up. For example, the timer 112b may be configured to measure a length of a time, which passes from a point in time when a lifetime of a specific cryptographic key is set up, based on a clock signal. In an embodiment, the timer 112b may perform a time measure operation only when a power of the storage device <NUM> is turned on.

The key manager 112c may control the storage controller <NUM> based on a lifetime determined with respect to a cryptographic key. For example, the key manager 112c may calculate a remaining lifetime of a cryptographic key from a difference between the determined lifetime and a time measured by the timer 112b. Below, for brevity of description, the case where a value obtained by subtracting the time measured by the timer 112b from the determined lifetime is less than "<NUM>" is referred to as the case where a remaining lifetime is "<NUM>".

The key manager 112c may control the storage controller <NUM> to perform the data protect operation on a cryptographic key whose lifetime expires (e.g., whose remaining lifetime is "<NUM>"). Below, the case where a specific remaining lifetime is "<NUM>" is referred to as the case where a lifetime of a corresponding cryptographic key expires. In contrast, the case where the specific remaining lifetime is not "<NUM>" is referred to as the case where the lifetime of the corresponding cryptographic key does not expire.

That is, the key manager 112c may control the storage controller <NUM> to perform the data protect operation on a cryptographic key, when a time measured by the timer 112b is longer than a lifetime of the cryptographic key. For example, when a time passing after the first cryptographic key is set up is longer than a lifetime determined with respect to the first cryptographic key, the key manager 112c may determine that the lifetime of the first cryptographic key expires. In this case the key manager 112c may control the storage controller <NUM> to perform the data protect operation on the first cryptographic key.

In an embodiment, the key manager 112c may extend a lifetime stored in the key manager 112c under control of the host <NUM>. The manner in which the key manager 112c extends a lifetime stored in the key manager 112c under control of the host <NUM> according to an embodiment will be described in detail with reference to <FIG>.

In an embodiment, the key manager 112c may renew an expired lifetime under control of the host <NUM>. The manner in which the key manager 112c renews a lifetime under control of the host <NUM> will be described in detail with reference to <FIG>.

In an embodiment, the cryptographic module <NUM> and the security module <NUM> may be implemented in the form of hardware, software, or a combination thereof. For example, at least a part of the cryptographic module <NUM> or the security module <NUM> may be included in the storage controller <NUM> in the form of a separate circuit, device, or chip. Alternatively, at least a part of the cryptographic module <NUM> or the security module <NUM> may be implemented in the form of a software module that is loaded to the volatile memory device <NUM> by the processor <NUM>. For brevity of description, an example in which the cryptographic module <NUM> and the security module <NUM> are separate components is illustrated in <FIG>. However, embodiments of the present disclosure are not limited thereto. For example, part or all of the cryptographic module <NUM> and the security module <NUM> may be included in one or more of any other components.

<FIG> is a table illustrating the manner in which a storage controller of <FIG> operates based on a remaining lifetime according to an embodiment of the present disclosure.

Referring to <FIG>, the storage controller <NUM> may communicate with the host <NUM> based on various cryptographic keys. For example, the storage controller <NUM> may communicate with the host <NUM> based on cryptographic key "0x123ABC" (hereinafter referred to as a "first cryptographic key"), may communicate with the host <NUM> based on cryptographic key "0x123DEF" (hereinafter referred to as a "second cryptographic key"), may communicate with the host <NUM> based on cryptographic key "0x123GHI" (hereinafter referred to as a "third cryptographic key"), may communicate with the host <NUM> based on cryptographic key "0x123JKL" (hereinafter referred to as a "fourth cryptographic key"), and may communicate with the host <NUM> based on cryptographic key "0x123MNO" (hereinafter referred to as a "fifth cryptographic key").

The first to fifth cryptographic keys may be called through different key identifiers (Key ID). For example, the first cryptographic key may be called through key identifier "A", the second cryptographic key may be called through key identifier "B", the third cryptographic key may be called through key identifier "C", the fourth cryptographic key may be called through key identifier "D", and the fifth cryptographic key may be called through key identifier "E". However, the cryptographic keys and key identifiers described above are used for brevity of description, and embodiments of the present disclosure are not limited to a specific number of cryptographic keys, a specific size of a cryptographic key, or a specific size of a key identifier.

To call a cryptographic key, the host <NUM> may use a corresponding key identifier. For example, a command that the host <NUM> sends to the storage device <NUM> may include a key identifier instead of a cryptographic key. For example, when the host <NUM> sends the read command for data encoded by using the first cryptographic key to the storage device <NUM>, the key identifier "A" may be included in the read command. In this case, the storage controller <NUM> may decode data stored in the nonvolatile memory device <NUM> by using the first cryptographic key. The storage controller <NUM> may provide the decoded data (e.g., raw data) to the host <NUM>.

The storage controller <NUM> may set up or may not set up a lifetime of each of the first to fifth cryptographic keys under control of the host <NUM>. Below, an embodiment in which the storage controller <NUM> does not set up a lifetime of the first cryptographic key and sets up lifetimes of the second to fifth cryptographic keys under control of the host <NUM> will be described as an example.

The storage controller <NUM> may not set up the lifetime of the first cryptographic key under control of the host <NUM>. In this case, the storage device <NUM> may operate in an unprotect mode with regard to the first cryptographic key. That is, the storage device <NUM> may normally operate in response to a command received from the host <NUM>. For example, when the read command including the key identifier "A" is received, regardless of a lifetime, the storage controller <NUM> may perform the read operation on the nonvolatile memory device <NUM>. When the write command including the key identifier "A" is received, regardless of a lifetime, the storage controller <NUM> may perform the write operation on the nonvolatile memory device <NUM>. When the erase command including the key identifier "A" is received, regardless of a lifetime, the storage controller <NUM> may erase data stored in the nonvolatile memory device <NUM>.

The storage controller <NUM> may set up a lifetime of each of the second to fifth cryptographic keys under control of the host <NUM>. In this case, the lifetimes of the second to fifth cryptographic keys may be identical to or different from each other, or the remaining lifetimes of the second to fifth cryptographic keys may be identical to or different from each other. For example, the remaining lifetime of the second cryptographic key may be "Ta", the remaining lifetime of the third cryptographic key may be "Tb", and the remaining lifetimes of the fourth and fifth cryptographic keys may be "<NUM>".

The storage device <NUM> may operate in a protect mode with regard to a cryptographic key whose remaining lifetime is greater than "<NUM>". For example, the storage device <NUM> may operate in the protect mode with regard to the second and third cryptographic keys. In this case, until the remaining lifetime is "<NUM>", the storage device <NUM> may operate in response to a command received from the host <NUM> (e.g., may operate normally). The operation of the storage device <NUM> that operates in response to a command received from the host <NUM> is similar to the above description, and thus, additional description will be omitted to avoid redundancy.

The storage device <NUM> may operate in a lock mode with regard to a cryptographic key whose remaining lifetime is "<NUM>". For example, the storage device <NUM> may operate in the lock mode with regard to the fourth and fifth cryptographic keys. In this case, the storage controller <NUM> may perform the data protect operation in response to a command related to the fourth or fifth cryptographic key.

The storage device <NUM> that operates in the lock mode may return an error in response to a request from a host. For example, the storage controller <NUM> may return an error in response to a command related to the fourth cryptographic key. That is, the storage controller <NUM> may return an error in response to a command including the key identifier "D".

Alternatively, the storage device <NUM> that operates in the lock mode may return a dummy response to a request from a host. For example, the storage controller <NUM> may return the dummy response to a command related to the fifth cryptographic key. That is, the storage controller <NUM> may return the dummy response to a command including the key identifier "E".

For example, when the read command including the key identifier "E" is received, the storage controller <NUM> may return garbage data to the host <NUM> instead of data stored in the nonvolatile memory device <NUM>. When the write command including the key identifier "E" is received, the storage controller <NUM> may return a completion acknowledgment to the host <NUM> without writing data in the nonvolatile memory device <NUM>. When the erase command including the key identifier "E" is received, the storage controller <NUM> may return a completion acknowledgment to the host <NUM> without erasing data stored in the nonvolatile memory device <NUM>.

In an embodiment, whether to return an error or a dummy response to the host <NUM> when the storage controller <NUM> performs the data protect operation may be determined in the process of setting up a cryptographic key. That is, the host <NUM> may determine a way to protect data related to a specific cryptographic key.

In an embodiment, as the storage controller <NUM> sets up a lifetime of a cryptographic key under control of the host <NUM>, the security of the storage device <NUM> may be increased. For example, after the host <NUM> is hacked, when a lifetime of a specific cryptographic key is not extended, the storage device <NUM> may enter the lock mode after the lifetime of the cryptographic key expires. In this case, because the access of the hacked host to data stored in the storage device <NUM> is blocked, the data of the storage device <NUM> may be protected even though a host is hacked.

In an embodiment, with regard to a cryptographic key whose lifetime expires, the storage controller <NUM> may return a dummy response to the host <NUM>, and thus, the security of the storage device <NUM> may be increased. For example, when the hacked host sends the read command to the storage device <NUM>, the hacked host may receive garbage data. In this case, the the hacked host may determine that data stored in the storage device <NUM> are damaged. Accordingly, the security of the storage device <NUM> may be increased.

<FIG> is a flowchart illustrating an operation method of a storage device of <FIG> according to an embodiment of the present disclosure.

Referring to <FIG>, in operation S11, the storage device <NUM> may set up a lifetime for each of a plurality of cryptographic keys. For example, the storage controller <NUM> may set up a lifetime of a cryptographic key based on commands (hereinafter referred to as "setup commands") received from the host <NUM>. In this case, each of the setup commands may include information about a cryptographic key, a key identifier, and a length of a lifetime.

In an embodiment, the storage controller <NUM> may be configured to set up lifetimes of some or all of the plurality of cryptographic keys that are used for communication with the host <NUM>.

In operation S12, the storage device <NUM> may receive a command related to one of the plurality of cryptographic keys. For example, the storage controller <NUM> may receive a command related to a specific cryptographic key from the host <NUM>. Below, for brevity of description, an embodiment in which the storage controller <NUM> receives a first command related to a first cryptographic key will be described as an example. In this case, it is assumed that the first command includes the first key identifier.

In operation S13, the storage device <NUM> may determine whether a lifetime of a cryptographic key related to a received command expires. For example, the storage controller <NUM> may determine whether the lifetime of the first cryptographic key expires. That is, the storage device <NUM> may determine an operating mode of the storage device <NUM> with regard to the first cryptographic key.

In an embodiment, when it is determined that the lifetime of the first cryptographic key expires, operation S14 may be performed. That is, when the storage device <NUM> operates in the lock mode with regard to the first cryptographic key (e.g., when a remaining lifetime of the first cryptographic key is "<NUM>"), operation S14 may be performed.

In an embodiment, when it is determined that the lifetime of the first cryptographic key does not expire, operation S15 may be performed. That is, when the storage device <NUM> operates in the protect mode with regard to the first cryptographic key (e.g., when the remaining lifetime of the first cryptographic key is greater than "<NUM>"), operation S15 may be performed.

In operation S14, the storage device <NUM> may perform the data protect operation. For example, the storage controller <NUM> may return a dummy response or an error in response to the first command.

In operation S15, the storage device <NUM> may perform the normal operation. For example, when the first command is the read command, the storage controller <NUM> may perform the read operation on the nonvolatile memory device <NUM>. When the first command is the write command, the storage controller <NUM> may perform the write operation on the nonvolatile memory device <NUM>. When the first command is the erase command, the storage controller <NUM> may erase data stored in the nonvolatile memory device <NUM>.

<FIG> is a flowchart illustrating an operation method of a storage device operating in response to a command issued from a host of <FIG> according to an embodiment of the present disclosure.

Referring to <FIG> and <FIG>, in operation S110, the host <NUM> may send a command (e.g., a setup command) for setting up a lifetime of a cryptographic key to the storage device <NUM>. In this case, the storage device <NUM> may set up the lifetime of the cryptographic key based on the setup command.

Below, for brevity of description, it is assumed that a first key identifier and a lifetime of a first time T1 are set up for the first cryptographic key and the first cryptographic key is called through the first key identifier. For example, the setup command may include information about the first cryptographic key, the first key identifier, and the first time T1. However, embodiments of the present disclosure are not limited thereto. For example, a key identifier and a lifetime for a cryptographic key may be set up through separate commands. For example, the storage device <NUM> may receive a first setup command from the host <NUM> and may set up the first cryptographic key and the first key identifier for the first cryptographic key. Subsequently, the storage device <NUM> may receive a second setup command from the host <NUM> and may set up the lifetime for the first cryptographic key.

In an embodiment, in the case where lifetime information is not included in the setup command, the storage device <NUM> may set up a lifetime determined in advance with regard to a cryptographic key. For example, the host <NUM> may provide the storage device <NUM> with the first setup command including the first cryptographic key and the first key identifier corresponding to the first cryptographic key (e.g., lifetime information not being included in the first setup command). With regard to the first cryptographic key, the storage device <NUM> may set up a lifetime of a pre-determined time length in response to the first setup command.

In an embodiment, the setup command may include information about a cryptographic key, a key identifier for the cryptographic key, and a length of a lifetime.

Before a lifetime expires, in operation S120, the storage device <NUM> may operate in the protect mode. That is, the storage device <NUM> may operate in response to a command received from the host <NUM> until the first time T1 passes.

For example, operation S120 may include operation S121 and operation S122. In operation S121, the host <NUM> may send a command related to a cryptographic key to the storage device <NUM>. For example, the host <NUM> may send a command including the first key identifier. In operation S122, the storage device <NUM> may perform the normal operation depending on the command received from the host <NUM>. For example, when the read command is received, the storage device <NUM> may perform the read operation on the nonvolatile memory device <NUM>. When the write command is received, the storage controller <NUM> may perform the write operation on the nonvolatile memory device <NUM>. When the erase command is received, the storage controller <NUM> may perform the erase operation on data stored in the nonvolatile memory device <NUM>.

In an embodiment, before a lifetime of a specific cryptographic key expires, the storage device <NUM> may extend the lifetime under control of the host <NUM>. An embodiment in which a lifetime is extended will be described in detail with reference to <FIG>.

When the lifetime expires, in operation S130, the storage device <NUM> may enter the lock mode with regard to the corresponding cryptographic key. For example, with regard to the first cryptographic key, the storage device <NUM> may enter the lock mode in response to the first time T1 passing.

After the lifetime expires, in operation S140, the storage device <NUM> may operate in the lock mode. That is, after the first time T1 passes, the storage device <NUM> may perform the data protect operation in response to a command received from the host <NUM> with regard to the first cryptographic key.

For example, operation S140 may include operation S141 and operation S142. In operation S141, the host <NUM> may send a command related to a cryptographic key to the storage device <NUM>. For example, the host <NUM> may send a command including the first key identifier. In operation S142, the storage device <NUM> may perform the data protect operation for a cryptographic key in response to the command received from the host <NUM>. For example, the storage device <NUM> may return an error or a dummy response to the host <NUM>. The data protect operation of the storage device <NUM> will be described in detail with reference to <FIG>, <FIG>, and <FIG>.

In an embodiment, after a lifetime of a specific cryptographic key expires, the storage device <NUM> may renew the lifetime under control of the host <NUM>. An embodiment related to renewing a lifetime will be described in detail with reference to <FIG>.

In an embodiment, in the case where the host <NUM> is hacked, a lifetime of a cryptographic key may not be extended. In this case, the storage device <NUM> may operate in the lock mode. Accordingly, the hacked host may fail to access (e.g., read or modify) data related to a cryptographic key whose lifetime expires. That is, data related to a cryptographic key whose lifetime expires may be protected from the hacked host. Accordingly security of the storage device <NUM> may be increased.

In an embodiment, when an access to a cryptographic key whose lifetime expires is requested, the storage device <NUM> may be implemented to operate in the lock mode with regard to all cryptographic keys. For example, after the lifetime of the first cryptographic key expires, access related to the first cryptographic key may be requested from the host <NUM>. In this case, the storage device <NUM> may operate in the lock mode with regard to both the first cryptographic key and the second cryptographic key. However, embodiments of the present disclosure are not limited thereto.

<FIG> is a diagram illustrating operation S140 of <FIG> according to an embodiment of the present disclosure.

An operation in which the storage device <NUM> receives a command of the host <NUM> and returns an error will be described with reference to <FIG>. Referring to <FIG>, <FIG>, and <NUM>, operation S140 may include operation S141a and operation S142a. In this case, operation S141a may correspond to operation S141, and operation S142a may correspond to operation S142.

In operation S141a, the host <NUM> may send a command related to a cryptographic key to the storage device <NUM>. In this case, the command that the host <NUM> sends may be related to a cryptographic key whose lifetime expires. For example, the command that the host <NUM> sends may include a key identifier (e.g., the first key identifier) associated with a cryptographic key (e.g., the first cryptographic key) whose lifetime expires. In an embodiment, the command that is sent in operation S141a may be one of various types of commands such as, for example, a read command, a write command, and an erase command.

In operation S142a, the storage device <NUM> may return an error to the host <NUM>. For example, the storage device <NUM> may return an error with regard to all commands related to the first cryptographic key (or including the first key identifier).

<FIG> and <FIG> are diagrams illustrating operation S140 of <FIG> according to an embodiment of the present disclosure. An operation in which the storage device <NUM> receives a command of the host <NUM> and returns a dummy response will be described with reference to <FIG> and <FIG>.

Referring to <FIG>, <FIG>, and <FIG>, operation S140 may include operation S141b, operation S142b_1, operation S142b_2, and operation S142b_3. In this case, operation S141b may correspond to operation S141, and operation S142b_1 to S142b_3 may correspond to operation S142.

In operation S141b, the host <NUM> may send the read command to the storage controller <NUM>. In this case, the command that the host <NUM> sends may be related to a cryptographic key whose lifetime expires. For example, the command that the host <NUM> sends may include a key identifier (e.g., the first key identifier) associated with a cryptographic key (e.g., the first cryptographic key) whose lifetime expires.

In operation S142b_1, the storage controller <NUM> does not read data from the nonvolatile memory device <NUM>. That is, the storage controller <NUM> does not operate in response to the read command received from the host <NUM>.

In operation S142b_2, the storage controller <NUM> may generate garbage data. In this case, the garbage data may be generated regardless of data related to the read command that the host <NUM> sends. For example, the garbage data may be independent of data stored at a physical address of the nonvolatile memory device <NUM>, which corresponds to the read command from the host <NUM>. For example, the garbage data may be random data.

In an embodiment, the storage controller <NUM> may generate the same garbage data with respect to the same read command. That is, the storage device <NUM> may be configured to repeatedly return the same garbage data in response to the same read command.

In operation S142b_3, the storage controller <NUM> may return the generated garbage data to the host <NUM>. Accordingly, the hacked host may determine that data corresponding to the read command thus issued are damaged. In this case, the security of the storage device <NUM> may be increased.

Referring to <FIG>, <FIG>, and <FIG>, operation S140 may include operation S141c, operation S142c_1, and operation S142c_2. In this case, operation S141c may correspond to operation S141, and operation S142c_1 and S142c_2 may correspond to operation S142.

In operation S141c, the host <NUM> may send the write command or the erase command to the storage controller <NUM>. A configuration of the write command or the erase command is similar to that of the read command described with reference to <FIG>, and thus, additional description will be omitted to avoid redundancy.

In operation S142c_1, the storage controller <NUM> does not write data in the nonvolatile memory device <NUM> or does not erase data stored in the nonvolatile memory device <NUM>. That is, the storage controller <NUM> does not operate in response to the write command or the erase command received from the host <NUM>.

In operation S143c_2, the storage controller <NUM> may return a completion acknowledgment to the host <NUM>. That is, the storage controller <NUM> may notify the host <NUM> that the command received from the host <NUM> is successfully processed. Accordingly, the hacked host may determine that the write command or the erase command thus issued is successfully processed. In this case, the security of the storage device <NUM> may be increased.

<FIG> is a flowchart illustrating an operation method of a storage device of <FIG>, which extends a lifetime under control of a host, according to an embodiment of the present disclosure.

Referring to <FIG> and <FIG>, in operation S210, the host <NUM> may send the setup command to the storage device <NUM>. Operation S210 is substantially the same as operation S <NUM> described with reference to <FIG>, and thus, additional description will be omitted to avoid redundancy. Below, for brevity of description, it is assumed that the storage device <NUM> sets up the lifetime of the first time T1 with respect to a first command based on the setup command.

Before the lifetime expires, in operation S220, the host <NUM> may send an extension command for a cryptographic key to the storage device <NUM>. In this case, the extension command may indicate a command for requesting to extend a lifetime of a cryptographic key. For example, the host <NUM> may send the extension command for the first cryptographic key to the storage controller <NUM>.

In an embodiment, the extension command may include a key identifier for a cryptographic key targeted for the extension of the lifetime, instead of the cryptographic key targeted for the extension of the lifetime. For example, the extension command for the first cryptographic key may include a first key identifier.

In operation S230, the storage device <NUM> may extend the lifetime based on the extension command from the host <NUM>. For example, the storage device <NUM> may extend the lifetime of the first cryptographic key as much as a second time T2 in response to the extension command. In this case, the lifetime of the first cryptographic key present in the key storage 112a may be modified to a sum of the first time T1 and the second time T2.

In an embodiment, information about a length of the second time T2 may be included in the extension command provided in operation S220. Alternatively, the length of the second time T2 may be defined in the setup command provided in operation S210.

In an embodiment, the extension command may be encoded with a private key defined in advance between the host <NUM> and the storage device <NUM>. For example, a key identifier and/or extension time information (e.g., information about the length of the second time T2) included in the extension command may be encoded with the private key. In this case, the probability that the key identifier and/or the extension time information is leaked may decrease.

Embodiments of the present disclosure are not limited to the manner in which the extension command is implemented, and a lifetime of a cryptographic key may be extended through various schemes determined between the host <NUM> and the storage device <NUM>.

For example, the extension command may be implemented with a normal command (e.g., an NVM command) such as a read command or a write command, and not an admin command defined for lifetime extension. For example, the host <NUM> may send the first command including information about lifetime extension in some fields. The storage device <NUM> may operate based on the first command (e.g., may perform the read operation based on the first command) and may extend a lifetime of a cryptographic key related to the first command. In this case, instead of extending a lifetime through a separate admin command, the host <NUM> may continue to extend a lifetime through the normal command (e.g., a read command or a write command).

For another example, the extension command may be defined based on an access pattern by which the host <NUM> accesses a cryptographic key. For example, as described above, the extension command may not be implemented with the admin command defined for lifetime extension. Instead, the storage controller <NUM> may be configured to extend a lifetime when the host <NUM> accesses a specific cryptographic key repeatedly (or regularly).

Before the extended lifetime expires, in operation S240, the storage device <NUM> may operate in the protect mode. That is, the storage device <NUM> may operate normally, in response to a command received from the host <NUM>, until the extended lifetime has expired. The operations of the host <NUM> and the storage device <NUM> in operation S240 are the same as those in operation S120 described above, and thus, additional description will be omitted to avoid redundancy. For example, operation S240 may include operation S241 being the same as operation S121 and operation S242 being the same as operation S122.

When the extended lifetime expires, in operation S250, the storage device <NUM> may enter the lock mode with regard to the corresponding cryptographic key. For example, with regard to the first cryptographic key, the storage device <NUM> may enter the lock mode when both the first time T1 and the second time T2 pass.

After the extended lifetime expires, in operation S260, the storage device <NUM> may operate in the lock mode. That is, after both the first time T1 and the second time T2 pass, the storage device <NUM> may perform the data protect operation with respect to a command received from the host <NUM>. The operations of the host <NUM> and the storage device <NUM> in operation S260 are the same as those in operation S140 described above, and thus, additional description will be omitted to avoid redundancy. For example, operation S260 may include operation S261 being the same as operation S141 and operation S262 being the same as operation S142.

That is, after the host <NUM> is hacked, when a lifetime of a specific cryptographic key is not extended, the storage device <NUM> may enter the lock mode after the lifetime of the cryptographic key expires. In this case, because the access of the hacked host to data stored in the storage device <NUM> is blocked, the data of the storage device <NUM> may be protected even though the host is hacked.

In an embodiment, the storage device <NUM> may collectively extend a plurality of lifetimes of a plurality of cryptographic keys under control of the host <NUM>. For example, the storage device <NUM> may extend the lifetime of the first cryptographic key and the lifetime of the second cryptographic key in response to the extension command from the host <NUM>.

<FIG> is a flowchart illustrating an operation method of a storage device of <FIG>, which renews a lifetime under control of a host, according to an embodiment of the present disclosure.

Referring to <FIG> and <FIG>, in operation S310, the host <NUM> may send the setup command to the storage device <NUM>. When the extended lifetime expires, in operation S320, the storage device <NUM> may enter the lock mode. Operation S310 is substantially the same as operation <NUM> and operation S210 described above, and operation S320 is substantially the same as operation S130 and operation S250 described above. Thus, additional description will be omitted to avoid redundancy. Below, for brevity of description, an operation in which the storage device <NUM> renews a lifetime of the first cryptographic key will be described as an example.

In an embodiment, the storage device <NUM> may perform one or more lifetime extension operations between operation S310 and operation S320. For example, an operation in which the storage device <NUM> receives the extension command for the first cryptographic key from the host <NUM> and extends a lifetime of the first cryptographic key may be further performed between operation S310 and operation S320.

In operation S330, the storage device <NUM> may notify the host <NUM> of a cryptographic key whose lifetime expires. For example, the storage device <NUM> may notify the host <NUM> that the lifetime for the first cryptographic key expires. In this case, the storage device <NUM> may notify the host <NUM> of the lifetime expiration based on an interrupt manner. However, embodiments of the present disclosure are not limited to the manner in which the storage device <NUM> notifies the host <NUM> of the lifetime expiration.

In operation S340, the host <NUM> may send a renew command for a cryptographic key whose lifetime expires, to the storage device <NUM>. In this case, the renew command may include re-authentication information. For example, the renew command may include a key identifier for a cryptographic key whose lifetime expires.

In an embodiment, the renew command may be implemented to be the same as the extension command described with reference to operation S220. That is, in an embodiment, the renew command may be identical to the extension command. For example, the renew command may be encoded based on a private key.

Embodiments of the present disclosure are not limited to the manner in which the renew command is implemented, and a lifetime of a cryptographic key may be renewed through various schemes determined between the host <NUM> and the storage device <NUM>. Various embodiments related to the manner in which the renew command is implemented are similar to that described with reference to <FIG>, and thus, additional description will be omitted to avoid redundancy. In an embodiment, operation S340 may be performed after power of a storage device is turned off after operation S320 and is then again turned on. For example, after the storage device <NUM> that enters the lock mode with regard to a specific key is rebooted, the storage device <NUM> may perform the data protect operation before receiving re-authentication information.

In an embodiment, operation S330 may be omitted. For example, in an embodiment, after operation S320, the storage device <NUM> does not notify the host <NUM> of the lifetime expiration. In this case, after operation S320, the storage device <NUM> may perform the data protect operation until the renew command is received from the host <NUM>.

In operation S350, the storage device <NUM> may renew a lifetime of a cryptographic key corresponding to the renew command and may enter the protect mode. For example, the storage device <NUM> may set up the lifetime of the first cryptographic key with a third time T3. In this case, a length of the third time T3 may be about equal to or different from the length of the first time T1.

When the renewed lifetime expires, in operation S360, the storage device <NUM> may again enter the lock mode. For example, in the case where the third time T3 passes, the storage device <NUM> may enter the lock mode with regard to the first cryptographic key. In this case, the storage device <NUM> may perform the data protect operation with regard to the first cryptographic key.

In an embodiment, in the case where a plurality of lifetimes of a plurality of cryptographic keys expire, the storage device <NUM> may collectively renew the plurality of lifetimes under control of the host <NUM>. For example, the storage device <NUM> may renew the lifetime of the first cryptographic key and the lifetime of the second cryptographic key in response to the renew command from the host <NUM>.

<FIG> is a block diagram illustrating a storage controller according to an embodiment of the present disclosure. For brevity, the description given with reference to the above components will be omitted to avoid redundancy.

Referring to <FIG>, a storage controller <NUM> may include a security module <NUM>. The storage controller <NUM> may include a cryptographic module <NUM>, the security module <NUM>, a processor <NUM>, a host interface layer <NUM>, a volatile memory device <NUM>, and a nonvolatile memory device interface <NUM>. The cryptographic module <NUM>, the security module <NUM>, the processor <NUM>, the host interface layer <NUM>, the volatile memory device <NUM>, and the nonvolatile memory device interface <NUM> may be connected to each other via a bus. The cryptographic module <NUM>, the processor <NUM>, the host interface layer <NUM>, the volatile memory device <NUM>, and the nonvolatile memory device interface <NUM> are described with reference to <FIG>, and thus, additional description will be omitted to avoid redundancy.

In an embodiment, the security module <NUM> described with reference to <FIG> may perform the data protect operation based on a lifetime of a cryptographic key. In contrast, the security module <NUM> of <FIG> may be configured to set up durability for an access of a cryptographic key to perform the data protect operation. That is, the security module <NUM> of <FIG> may set up a limit on the number of accesses of the host <NUM> to a cryptographic key.

For example, the security module <NUM> may include key storage 212a, a counter 212b, and a key manager 212c.

The key storage 212a may store a variety of information related to a cryptographic key that is used for communication with the host <NUM>. For example, the key storage 212a may store a cryptographic key, a key identifier (Key ID) for the cryptographic key, and the durability set up with respect to the cryptographic key.

The counter 212b may count the number of accesses to a cryptographic key. That is, the counter 212b may increase a corresponding counter value when an access to a specific cryptographic key is made. For example, when the access to the first cryptographic key is requested from the host <NUM>, the counter 212b may increase a counter value for the first cryptographic key.

In an embodiment, the access may refer to a command provided from the host <NUM> with regard to a cryptographic key. For example, the access to the first cryptographic key may refer to commands each including a first key identifier. That is, the access may include various types of commands such as a read command, a write command, and an erase command.

The key manager 212c may control the storage controller <NUM> based on the durability set up with respect to a cryptographic key. For example, when a counter value measured by the counter 212b is greater than the durability, the key manager 212c may control the storage controller <NUM> to perform the data protect operation. For example, when a counter value for the first cryptographic key is greater than the durability for the first cryptographic key, the key manager 212c may control the storage controller <NUM> to perform the data protect operation with regard to the first cryptographic key.

<FIG> is a table illustrating the manner in which a storage controller of <FIG> operates based on a counter value, according to an embodiment of the present disclosure.

Referring to <FIG>, the storage controller <NUM> may communicate with the host <NUM> based on various cryptographic keys. For example, the storage controller <NUM> may communicate with the host <NUM> based on cryptographic key "0x456ABC" (hereinafter referred to as a "first cryptographic key"), may communicate with the host <NUM> based on cryptographic key "0x456DEF" (hereinafter referred to as a "second cryptographic key"), may communicate with the host <NUM> based on cryptographic key "0x456GHI" (hereinafter referred to as a "third cryptographic key"), may communicate with the host <NUM> based on cryptographic key "0x456JKL" (hereinafter referred to as a "fourth cryptographic key"), and may communicate with the host <NUM> based on cryptographic key "0x456MNO" (hereinafter referred to as a "fifth cryptographic key").

The first to fifth cryptographic keys may be called through different key identifiers. The first to fifth cryptographic keys may be respectively called through key identifiers "F", "G", "H", "I", and "J".

The storage controller <NUM> may set up or may not set up the durability of each of the first to fifth cryptographic keys under control of the host <NUM>. Below, an embodiment in which the storage controller <NUM> does not set up the durability of the first cryptographic key and sets up the durability of each of the second to fifth cryptographic keys will be described as an example.

The storage controller <NUM> may not set up the lifetime of the first cryptographic key under control of the host <NUM>. In this case, the storage device <NUM> may operate in the unprotect mode with regard to the first cryptographic key.

The storage device <NUM> may operate in a protect mode with regard to a cryptographic key whose durability is greater than or about equal to a corresponding counter value. For example, with regard to the second cryptographic key (in which the durability Na is greater than "<NUM>") and the third cryptographic key (in which the durability Nb is same as a counter value Nb), the key manager 212c may allow the storage device <NUM> to operate in the protect mode.

The storage device <NUM> may operate in the lock mode with regard to a cryptographic key whose durability is less than a corresponding counter value. For example, the storage device <NUM> may operate in the lock mode with regard to the fourth and fifth cryptographic keys.

In an embodiment, the case where the durability of a specific cryptographic key is less than a corresponding counter value may refer to the case where the durability of the cryptographic key is exhausted (or worn out).

Methods in which the storage device <NUM> operates in the unprotect mode, the protect mode, and the lock mode are similar to those described with reference to <FIG> and <FIG> and <FIG>, and thus, additional description will be omitted to avoid redundancy.

In an embodiment, before the durability of the specific cryptographic key is exhausted, under control of the host <NUM>, the storage device <NUM> may increase the durability or may decrease a counter value. For example, in response to a recovery command received from the host <NUM>, the storage device <NUM> may increase the durability of the corresponding cryptographic key or may decrease a counter value.

In an embodiment, the recovery command may include a key identifier related to a cryptographic key targeted for an increase in durability or a decrease in a counter value.

In an embodiment, the recovery command may be encoded with a private key. For example, the recovery command may include an encoded key identifier.

<FIG> is a flowchart illustrating an operation method of a storage device of <FIG>, which includes a storage controller of <FIG>, according to an embodiment of the present disclosure.

Referring to <FIG> and <FIG> to <FIG>, in operation S21, the storage device <NUM> may set up the durability of a cryptographic key under control of the host <NUM>. Below, an embodiment in which the durability of the first cryptographic key is set up will be described as an example.

In operation S22, the storage device <NUM> may receive a command related to a cryptographic key whose durability is set up. That is, the storage device <NUM> may receive an access related to a cryptographic key from the host <NUM>. For example, the storage device <NUM> may receive a command including the key identifier corresponding to the first cryptographic key.

In operation S23, the storage device <NUM> may compare the durability and a counter value. For example, the key manager 212c may compare the durability of the first cryptographic key with a counter value related to the first cryptographic key.

In an embodiment, when the counter value is less than or about equal to the durability, operation S24 and operation S25 may be performed. In operation S24, the storage device <NUM> may perform the normal operation. That is, the storage device <NUM> may operate in response to the command received from the host <NUM>. For example, when the command received in operation S22 is the read command, the storage controller <NUM> may read data from the nonvolatile memory device <NUM>.

In operation S25, the storage device <NUM> may increase the counter value by "<NUM>". For example, the counter 212b may increase the counter value related to the first cryptographic key by "<NUM>".

In an embodiment, when the counter value is greater than the durability, operation S26 may be performed. In operation S26, the storage device <NUM> may perform the data protect operation. For example, the storage controller <NUM> may perform the data protect operation with regard to the first cryptographic key.

In an embodiment, as the storage controller <NUM> sets up the durability of a cryptographic key, the security of the storage device <NUM> may be increased. For example, after the host <NUM> is hacked, when the recovery command for a specific cryptographic key is not received, the storage device <NUM> may enter the lock mode after the durability of the cryptographic key is exhausted (or worn out). In this case, because the access of the hacked host to data stored in the storage device <NUM> is blocked, the data of the storage device <NUM> may be protected even though a host is hacked.

<FIG> is a diagram of a data center <NUM> to which a memory device is applied, according to an embodiment.

Referring to <FIG>, the data center <NUM> may be a facility that collects various types of pieces of data and provides services, and may be referred to as a data storage center. The data center <NUM> may be a system for operating a search engine and a database, and may be a computing system used by companies, such as, for example, banks, or government agencies. The data center <NUM> may include application servers 2100_1 to 2100_n and storage servers 2200_1 to 2200_m, in which each of n and m is a positive integer. The number of application servers 2100_1 to 2100_n and the number of storage servers 2200_1 to 2200_m may be variously selected according to embodiments. The number of application servers 2100_1 to 2100_n may be different from the number of storage servers 2200_1 to 2200_m.

Below, for convenience of description, an embodiment of the first storage server 2200_1 will be described. Each of the other storage servers 2200_2 to 2200_m and the plurality of application servers 2100_1 to 2100_n may have a similar configuration or structure of the first storage server 2200_1.

The storage server 2200_1 may include at least one of a processor 2210_1, a memory 2220_1, a network interface card (NIC) 2240_1, and a storage device 2250_1. The processor 2210_1 may control all operations of the storage server 2200_1, access the memory 2220_1, and execute instructions and/or data loaded in the memory 2220_1. The memory 2220_1 may be, for example, a double-data-rate synchronous DRAM (DDR SDRAM), a high-bandwidth memory (HBM), a hybrid memory cube (HMC), a dual in-line memory module (DIMM), Optane DIMM, and/or a non-volatile DIMM (NVMDIMM).

In some embodiments, the numbers of processors 2210_1 and memories 2220_1 included in the storage server 2200_1 may be variously selected. In an embodiment, the processor 2210_1 and the memory 2220_1 may provide a processor-memory pair. In an embodiment, the number of processors 2210_1 may be different from the number of memories 2220_1. The processor 2210_1 may include a single-core processor or a multi-core processor.

The switch 2230_1 may selectively connect the processor 2210_1 to the storage device 2250_1 or selectively connect the NIC 2240_1 to the storage device 2250_1 via the control of the processor 2210_1.

The NIC 2240_1 may be configured to connect the first storage server 2200_1 with a network NT. In an embodiment, the NIC 2240_1 may include a network interface card and a network adaptor. The NIC 2240_1 may be connected to the network NT by, for example, a wired interface, a wireless interface, a BLUETOOTH interface, or an optical interface. The NIC 2240_1 may include an internal memory, a digital signal processor (DSP), and a host bus interface, and may be connected to the processor 2210_1 and/or the switch 2230_1 through the host bus interface. The host bus interface may be implemented as one of the above-described examples of the interface 2254_1 such as, for example, ATA, SATA, e-SATA, an SCSI, SAS, PCI, PCIe, NVMe, IEEE <NUM>, a USB interface, an SD card interface, an MMC interface, an eMMC interface, a UFS interface, an eUFS interface, and/or a CF card interface. In an embodiment, the NIC 2240_1 may be integrated with at least one of the processor 2210_1, the switch 2230_1, and the storage device 2250_1.

The storage device 2250_1 may store or read out data under the control of the processor 2210_1. The storage device 2250_1 may include a controller 2251_1, a nonvolatile memory 2252_1, DRAM 2253_1, and an interface 2254_1. In an embodiment, the storage device 2250_1 may include a secure element (SE) for security or privacy.

The controller 2251_1 may control all operations of the storage device 2250_1. In an embodiment, the controller 2251_1 may include SRAM. The controller 2251_1 may write data to the nonvolatile memory 2252_1 in response to a write command or read data from the nonvolatile memory device 2252_1 in response to a read command. In an embodiment, the controller 2251_1 may be configured to control the nonvolatile memory 2252_1 based on a Toggle interface or an ONFI interface.

The DRAM 2253_1 may temporarily store (or buffer) data to be written to the nonvolatile memory 2252_1 or data read from the nonvolatile memory 2252_1. Also, the DRAM 2253_1 may store data utilized for the controller 2251_1 to operate, such as, for example, metadata or mapping data. The interface 2254_1 may provide a physical connection between the at least one of the processor 2210_1, the memory 2220_1, the network interface card (NIC) 2240_1, and the controller 2251_1. In an embodiment, the interface 2254_1 may be implemented using a direct attached storage (DAS) scheme in which the storage device 2250_1 is directly connected to a dedicated cable. In an embodiment, the interface 2254_1 may be implemented by using various interface schemes, such as, for example, ATA, SATA, e-SATA, an SCSI, SAS, PCI, PCIe, NVMe, IEEE <NUM>, a USB interface, an SD card interface, an MMC interface, an eMMC interface, a UFS interface, an eUFS interface, and/or a CF card interface.

The above configuration of the storage server 2200_1 is merely an example, and embodiments of the present disclosure are not limited thereto. The above configuration of the storage server 2200_1 may be applied to each of other storage servers or the plurality of application servers. In an embodiment, in each of the plurality of application servers 2100_1 to 2100_n, the storage device may be selectively omitted.

The application servers 2100_1 to 2100_n may communicate with the storage servers 2200_1 to 2200_m through the network NT. The network NT may be implemented by using, for example, a fiber channel (FC) or Ethernet. In this case, the FC may be a medium used for relatively high-speed data transmission and may use an optical switch with high performance and high availability. The storage servers 2200_1 to 2200_m may be provided as, for example, file storages, block storages, or object storages according to an access method of the network NT.

In an embodiment, the network NT may be a storage-dedicated network, such as a storage area network (SAN). For example, the SAN may be an FC-SAN, which uses an FC network and is implemented according to an FC protocol (FCP). As another example, the SAN may be an Internet protocol (IP)-SAN, which uses a transmission control protocol (TCP)/IP network and is implemented according to a SCSI over TCP/IP or Internet SCSI (iSCSI) protocol. In an embodiment, the network NT may be a general network, such as a TCP/IP network. For example, the network NT may be implemented according to a protocol, such as, for example, FC over Ethernet (FCoE), network attached storage (NAS), and NVMe over Fabrics (NVMe-oF).

In an embodiment, at least one of the plurality of application servers 2100_1 to 2100_n may be configured to access at least another one of the plurality of application servers 2100_1 to 2100_n or at least one of the plurality of storage servers 2200_1 to 2200_m.

For example, the application server 2100_1 may store data, which is requested by a user or a client to be stored, in one of the storage servers 2200_1 to 2200_m through the network NT. Also, the application server 2100_1 may obtain data, which is requested by the user or the client to be read, from one of the storage servers 2200_1 to 2200_m through the network NT. For example, the application server 2100_1 may be implemented as a web server or a database management system (DBMS).

The application server 2100_1 may access a memory 2120_n or a storage device 2150_n, which is included in another application server 2100_n, through the network NT. Alternatively, the application server 2100_1 may access memories 2220_1 to 2220_m or storage devices 2250_1 to 2250_m, which are included in the storage servers 2200_1 to 2200_m, through the network NT. Thus, the application server 2100_1 may perform various operations on data stored in application servers 2100_1 to 2100_n and/or the storage servers 2200_1 to 2200_m. For example, the application server 2100_1 may execute an instruction for moving or copying data between the application servers 2100_1 to 2100_n and/or the storage servers 2200_1 to 2200_m. In this case, the data may be moved from the storage devices 2250_1 to 2250_m of the storage servers 2200_1 to 2200_m to the memories 2120_1 to 2120_n of the application servers 2100_1 to 2100_n directly or through the memories 2220_1 to 2220_m of the storage servers 2200_1 to 2200_m. The data moved through the network NT may be data encrypted for security or privacy.

In an embodiment, each of the storage servers 2200_1 to 2200_m or the storage devices 2150_1 to 2150_n and 2250_1 to 2250_m may include a secure module. For example, at least one of the storage servers 2200_1 to 2200_m or the storage devices 2150_1 to 2150_n and 2250_1 to 2250_m may be configured to perform the data protect operation with reference to a cryptographic key, based on the method described with reference to <FIG>.

Claim 1:
An operation method of a storage device (<NUM>), which includes a nonvolatile memory device (<NUM>) and is configured to communicate with a host (<NUM>) based on a cryptographic key, the method comprising:
setting up (S11) a first key identifier and a first lifetime for a first cryptographic key, based on a first command received from the host (<NUM>);
before the first lifetime expires, extending the first lifetime for the first cryptographic key in response to an extension command received from the host (<NUM>), wherein the extension command comprises the first key identifier encoded with a private key shared between the host (<NUM>) and the storage device (<NUM>); and
after the first lifetime expires (S13), when a second command (S12) including the first key identifier is received from the host (<NUM>), performing a data protect operation (S14) regarding to the first cryptographic key.