System, device and method for writing data in protected region

Abstract

A method for writing data to a protected area in response to a request from a host may include: receiving a first write request from a host including a first host message authentication code and a first random number; verifying the first write request based on a write counter, a first random number and a first host message authentication code; updating the write counter based on the verification result of the first write request; generating a first device message authentication code based on the updated write counter and the first random number; and providing a first response to the host including the first device message authentication code and the verification result.

Description

Technology Field

[0001] The technical concept of the present disclosure relates to a storage device, and more specifically, to a system, device, and method for writing data to a protected area. Background Technology

[0002] Storage devices for storing data can be used in various applications, and recently, storage devices including memory devices manufactured by semiconductor processes are widely used. A storage device can provide a protected area to the host for storing data requiring security and may allow only authenticated access to the protected area. Various attacks can occur on the storage device and / or the host to acquire and / or modify data stored in the protected area or to insert errors into access to the protected area. Accordingly, it may be important to accurately authenticate access to the protected area. The problem to be solved

[0003] The technical concept of the present disclosure provides a system, device, and method for protecting the writing of data to a protected area from attacks. means of solving the problem

[0004] To achieve the above objectives, according to one aspect of the technical concept of the present disclosure, a method for writing data to a protected area in response to a request from a host may include: receiving a first write request from a host including a first host message authentication code and a first random number; verifying the first write request based on a write counter, the first random number and the first host message authentication code; updating the write counter based on the result of verifying the first write request; generating a first device message authentication code based on the updated write counter and the first random number; and providing a first response to the host including the first device message authentication code and the verification result.

[0005] According to one aspect of the technical concept of the present disclosure, a storage device communicating with a host may include a memory including a protected area, and a controller that receives a first write request from a host including a first host message authentication code, a first write counter, and a first random number, verifies the first write request based on the write counter, the first random number, and the first host message authentication code, and writes data included in the first write request to the protected area upon successful verification of the first write request.

[0006] According to one aspect of the technical concept of the present disclosure, a method for writing data to a storage device including a protection area may include: generating a first host message authentication code based on a write counter and a first random number; providing a first write request to the storage device including the first host message authentication code and the first random number; receiving a first response from the storage device including a first device message authentication code; verifying the first response based on an incremented value from the write counter, the first random number, and the first device message authentication code; and updating the write counter based on the verification result of the first response. Effects of the invention

[0007] According to the system, device, and method of the exemplary embodiment of the present disclosure, an attack on access to a protected area of ​​a storage device can be effectively detected, and accordingly, the security of the protected area can be further enhanced.

[0008] In addition, according to the system, device, and method of the exemplary embodiment of the present disclosure, changes to the interface between the host and the storage device may be unnecessary or minimized, and accordingly, the security of the protected area may be enhanced more efficiently and easily.

[0009] The effects obtainable from the exemplary embodiments of the present disclosure are not limited to those mentioned above, and other unmentioned effects can be clearly derived and understood by those skilled in the art to which the exemplary embodiments of the present disclosure belong from the description below. That is, unintended effects resulting from the implementation of the exemplary embodiments of the present disclosure can also be derived by those skilled in the art from the exemplary embodiments of the present disclosure. Brief explanation of the drawing

[0010] FIG. 1 is a block diagram showing a system according to an exemplary embodiment of the present disclosure. FIG. 2 is a drawing showing a message data frame according to an exemplary embodiment of the present disclosure. Figures 3a and 3b are message diagrams showing examples of attacks. FIG. 4 is a message diagram illustrating a method for writing data to a protection area according to an exemplary embodiment of the present disclosure. FIG. 5 is a flowchart illustrating a method for writing data to a protected area according to an exemplary embodiment of the present disclosure. FIG. 6 is a flowchart illustrating a method for writing data to a protected area according to an exemplary embodiment of the present disclosure. FIG. 7 is a flowchart illustrating a method for writing data to a protected area according to an exemplary embodiment of the present disclosure. FIG. 8 is a flowchart illustrating a method for writing data to a protected area according to an exemplary embodiment of the present disclosure. FIG. 9 is a message diagram illustrating a method for writing data to a protection area according to an exemplary embodiment of the present disclosure. FIGS. 10a and FIGS. 10b are message diagrams illustrating examples of methods for writing data to a protected area according to exemplary embodiments of the present disclosure. FIG. 11 is a drawing illustrating a system to which a storage device according to one embodiment of the present invention is applied. FIG. 12 is a drawing for explaining a UFS system according to one embodiment of the present invention. FIGS. 13a to 13c are drawings for explaining the form factor of a UFS card. FIG. 14 is a block diagram showing a non-volatile storage according to an embodiment of the present invention. FIG. 15 is a block diagram showing a non-volatile storage according to one embodiment of the present invention. FIG. 16 is an exemplary block diagram showing the memory device of FIG. 15. FIG. 17 is a drawing for explaining a 3D V-NAND structure that can be applied to a UFS device according to one embodiment of the present invention. FIG. 18 is a drawing for explaining a BVNAND structure that can be applied to a UFS device according to one embodiment of the present invention. Specific details for implementing the invention

[0011] FIG. 1 is a block diagram illustrating a system (10) according to an exemplary embodiment of the present disclosure. The system (10) may be any system comprising a storage device (100) and a host (200) that communicate with each other. For example, the system (10) may be a stationary system such as a desktop computer, workstation, server, television, video game console, etc., or a portable system such as a laptop computer, tablet PC, mobile phone, e-book, wearable device, etc. In some embodiments, the system (10) may be referred to as a storage system.

[0012] The host (200) may refer to any device that communicates with the storage device (100) and may also be referred to as a host device. For example, the host (200) may include at least one programmable device such as a CPU (central processing unit), DSP (digital signal processor), GPU (graphic processing unit), NPU (neural network processing unit), etc., may include a reconfigurable device such as a field programmable gate array (FPGA), etc., and may include a device that provides fixed functions such as an IP (intellectual property) core, etc. In some embodiments, the host (200) may include a host controller that performs operations described below with reference to the drawings, and the host controller may include at least one programmable device configured to execute software, at least one reconfigurable device and / or at least one device that provides fixed functions.

[0013] A host (200) can communicate with a storage device (100) based on any interface. For example, the host (200) can communicate with the storage device (100) based on a SATA (serial advanced technology attachment) interface, SCSI (small computer small interface), PCIe (peripheral component interconnect express) interface, USB (universal serial bus) interface, UFS (universal flash storage) interface, eMMC (embedded multi-media card) interface, etc. As illustrated in FIG. 1, the host (200) can send a request (REQ) to the storage device (100) based on the interface and receive a response (RES) from the storage device (100).

[0014] The host (200) may include a random number generator (220) and may provide a request (REQ) containing a random number generated by the random number generator (220) to the storage device (100). Accordingly, the request (REQ) may include a unique value (e.g., 24 in FIG. 2), and the host (200) may verify a response (RES) corresponding to the request (REQ) based on the unique value included in the request (REQ). Additionally, the storage device (100) may extract a unique value from the request (REQ) and verify the request (REQ) or generate a response (RES) based on the extracted value.

[0015] The storage device (100) may refer to any storage that includes a memory (140) for storing data. For example, the storage device (100) may be an embedded device that supports embedded universal flash storage (eUFS), embedded multimedia card (eMMC), etc., and may be detachably connected to a host (200), such as a flash memory card, compact flash (CF), secure digital (SD), micro-SD, mini-SD, extreme digital (XD), memory stick, etc. As illustrated in FIG. 1, the storage device (100) may include a controller (120) and a memory (140).

[0016] The memory (140) may have any structure for storing data and may be referred to as a memory device. In some embodiments, the memory (140) may include non-volatile memory such as flash memory, RRAM (resistive random access memory), etc. In some embodiments, the storage device (100) may include a buffer including volatile memory such as DRAM (dynamic random access memory). Also, in some embodiments, the storage device (100) may be a bufferless (or DRAMless) storage that utilizes a portion of the memory (140) as a buffer. As illustrated in FIG. 1, the memory (140) may include a protection area (142), and the protection area (142) may be managed by a controller (120) described later.

[0017] The controller (120) can control the memory (140) and may be referred to as a memory controller. As illustrated in FIG. 1, the controller (120) can receive a request (REQ) from the host (200), control the memory (140) based on the request (REQ), and provide a response (RES) corresponding to the request (REQ) to the host (200). For example, if the host (200) requests data writing through the request (REQ), the controller (120) can write data to the memory (140) based on the address included in the request (REQ) and provide a response (RES) indicating the completion of data writing to the host (200). Additionally, when the host (200) requests to read data through a request (REQ), the controller (120) can read data from memory (140) based on the address included in the request (REQ) and can provide a response (RES) containing the read data to the host (200).

[0018] The controller (120) may define a protected area (142) as part of the memory (140). In some embodiments, the protected area (142) may correspond to a replay protected memory block (RPMB) defined in UFS. The controller (120) may allow only authenticated access to the protected area (142), and accordingly, the host (200) may store data requiring security, i.e., secure data, in the protected area (142) and read the secure data stored in the protected area (142). To this end, the storage device (100) and the host (200) may share an authentication key in advance and use the key to authenticate requests (REQ) and / or responses (RES). For example, as illustrated in FIG. 1, the controller (120) may use a device key (KEY D You can use ), and the device key (KEY D) can be stored in a space accessible only to the controller (120), such as a part of a protected area (142). Similarly, the host (200) has a host key (KEY H ) can be used, and the host key (KEY H ) can be stored in a space accessible only to the host (200) (or host controller). In this specification, operations performed by the controller (120) may simply be referred to as operations performed by the storage device (100).

[0019] Device Key (KEY D ) and host key (KEY H ) can be provisioned to the storage device (100) and the host (200), respectively, in various ways. In some embodiments, the device key (KEY D ) and host key (KEY H ) can be injected, respectively, during the manufacturing process of the storage device (100) and the host (200). In some embodiments, the device key (KEY D ) can be injected into the storage device (100) by a request (REQ) from the host (200), and the injected device key (KEY D ) may not be rewriteable or readable. In some embodiments, the device key (KEY D ) and host key (KEY H ) can be the same.

[0020] The controller (120) may include a register (122), and the register (122) may store a write counter. For example, the controller (120) may count the write operation for the protected area (142) performed in response to a write request for the protected area (142). The host (200) may provide the storage device (100) with a request (REQ) for reading the current write counter (i.e., a write count read request), the controller (120) may read the write counter stored in the register (122), and may provide the host (200) with a response (RES) containing the read write counter. The host (200) may provide the storage device (100) with a request (REQ) for writing data, i.e., a write request, and the request (REQ) may include a write counter. The controller (120) can determine that the verification of the request (REQ) has failed if the write counter included in the request (REQ) is different from the current write counter, i.e., the write counter stored in the register (122). In this specification, the write counter managed by the host (200) may be referred to as the host write counter, and the write counter managed by the storage device (100), i.e. the controller (120), may be referred to as the device write counter.

[0021] A storage device (100) and a host (200) have a write counter, a device key (KEY D ) and host key (KEY HEven though access to the protected area (142) is authenticated using ), various attacks to acquire and / or modify data stored in the protected area (142) or to insert errors into access to the protected area may occur in the system (10). For example, as described below with reference to FIGS. 3a and 3b, an attack to insert errors into access for writing data to the protected area (142) may occur, and such attack may cause serious errors in the system (10). As described below with reference to the drawings, the host (200) may generate a request (REQ) for writing data based on a random number generated by a random number generator (220). The storage device (100) may verify the request (REQ) based on the random number included in the request (REQ) and may provide a response (RES) corresponding to the request (REQ) to the host (200). The host (200) can identify whether the operation caused by the request (REQ), i.e., the write operation, has been successfully completed by verifying the response (RES) based on the random number used when generating the request (REQ). Accordingly, a man-in-the-middle attack (MITM) can be effectively detected in the storage device (100) and the host (200), the insertion of errors caused by the man-in-the-middle attack can be prevented, and the security of the protection area (142) can be strengthened. In addition, changes to the interface between the storage device (100) and the host (200) may be unnecessary or minimized, and accordingly, the security of the protection area (142) can be strengthened more efficiently and easily.

[0022] FIG. 2 is a drawing illustrating a message data frame (20) according to an exemplary embodiment of the present disclosure. Specifically, the message data frame (20) of FIG. 2 represents an RPMB message data frame of UFS, and in some embodiments, a request (REQ) and a response (RES) for access to the protected area (142) of FIG. 1 may have a common message data frame (20). As illustrated in FIG. 2, the message data frame (20) may include a plurality of fields (21 to 29). Hereinafter, FIG. 2 will be described with reference to FIG. 1.

[0023] Referring to FIG. 2, the message data frame (20) may have a length of 512 bytes, and stuff bytes (21) having a length of 196 bytes and indicating the start of the data frame (20) may be placed at the beginning of the data frame (20). Following the stuff bytes (21), the message data frame (20) may sequentially include a message authentication code (MAC) (22), data (23), a nonce (24), a write counter (25), an address (26), a block count (27), a result (28), and a message type (29). As described below, data (23), nonce (24), write counter (25), address (26), block count (27), result (28), and message type (29) can be used to generate a message authentication code (22) together with an authentication key, and as illustrated in FIG. 2, may be collectively referred to as a message (MSG) in this specification. Accordingly, a request (REQ) and a response (RES), each may be referred to as including a message authentication code (MAC) and a message (MSG). In this specification, among the fields included in the message (MSG), the nonce (24) and the write counter (25) may be primarily illustrated and described, and the illustration and description of other fields of the message (MSG) may be omitted.

[0024] The Message Authentication Code (MAC) (22) may have a length of 32 bytes and may be included in the Request (REQ) and Response (RES), respectively. The Message Authentication Code (MAC) (22) may have a value used to validate the message data frame (20), i.e., the Request (REQ) and Response (RES). For example, the host (200) may include a message (MSG) (which may be referred to as a host message in this specification) and a host key (KEY) to be included in the Request (REQ). H A message authentication code (MAC) (which may be referred to as a host message authentication code in this specification) to be included in a request (REQ) can be generated based on ), and the storage device (100) can generate a message (MSG) (i.e., a host message) and a device key (KEY) included in the request (REQ). D Based on ), the message authentication code (MAC) (i.e., host message authentication code) included in the request (REQ) can be verified. Similarly, the storage device (100) can verify the message (MSG) (which may be referred to as a device message in this specification) and the device key (KEY) to be included in the response (RES). D Based on ), a message authentication code (MAC) (which may be referred to as a device message authentication code in this specification) to be included in the response (RES) can be generated, and the host (200) can generate a message (MSG) (i.e., device message) and a host key (KEY) included in the response (RES). H Based on ), the message authentication code (MAC) (i.e., device message authentication code) included in the response (RES) can be verified. In some embodiments, the message authentication code (MAC) (22) may be used to transmit an authentication key having a length of 32 bytes in an authentication key programming request (Message Type = 0001h).

[0025] In some embodiments, a message authentication code (MAC) may be generated based on a hash function from an authentication key and a message (MSG), and the message authentication code (MAC) may be referred to as a hash message authentication code (hash MAC; HMAC). For example, each of the storage device (100) and the host (200) may generate a message authentication code (MAC) from the concatenation (i.e., bytes [228:511]) of fields included in the authentication key and the message (MSG) based on a hash function such as MD5 (message digest algorithm 5), SHA1 (secure hash algorithm 1), SHA256 (secure hash algorithm 256), and may include a hash engine for implementing the hash function.

[0026] Data (23) may have a length of 256 bytes and may be included in the request (REQ) and response (RES), respectively. For example, the data (23) included in the request (REQ) may correspond to data to be written to the storage device (100), and the data (23) included in the response (RES) may correspond to data read from the storage device (100). The nonce (24) may have a length of 16 bytes and may be included in the request (REQ) and response (RES), respectively, and may include a random number generated by the host (200). The write counter (25) may have a length of 4 bytes and may be included in the request (REQ) and response (RES), respectively, and may include a value counting the write operation for the protected area (142). The nonce (24) and write counter (25) can be used to verify the message data frame (20) together with the message authentication code (MAC) (22).

[0027] The address (26) may have a length of 2 bytes and may be included in the request (REQ) and response (RES), respectively, and may include a value indicating an area in the protected area (142) where data (23) is to be written or read. The block count (27) may have a length of 2 bytes and may be included in the request (REQ) and response (RES), respectively, and may include the number of 256-byte logical blocks requested to be read or programmed. The result (28) may have a length of 2 bytes and may be included in the response (RES), and may include a value indicating the result of the operation.

[0028] The message type (29) may have a length of 2 bytes and may be included in the request (REQ) and the response (RES), respectively. The message type (29) included in the request (REQ) may be referred to as the request message type and may have a value defining the request. For example, the request message type may include a value representing one of the requests: an authentication key programming request, a write count reading request, an authenticated data writing request, an authenticated data reading request, a result reading request, a secure write protection configuration block writing request, and a secure write protection configuration block reading request. Additionally, the response message type may include a value representing one of the responses: an authentication key programming response, a write counter reading response, an authenticated data writing response, an authenticated data reading response, a secure write protection configuration block writing response, and a secure write protection configuration block reading response.

[0029] FIGS. 3a and 3b are message diagrams illustrating examples of attacks. Specifically, FIGS. 3a and 3b illustrate examples of Man-in-the-Middle (MITM) attacks. As illustrated in FIG. 3a, an attacker (32a) may exist between a host (31a) and a storage device (33a), and as illustrated in FIG. 3b, an attacker (32b) may exist between a host (31b) and a storage device (33b). In FIGS. 3a and 3b, the requests are write requests for a protected area, and the response is assumed to occur in response to the write request without a separate request (e.g., a result read request). Below, mutually redundant descriptions of FIGS. 3a and 3b will be omitted.

[0030] Referring to FIG. 3a, the host (31a) may include at least one processor running software including an operating system (OS) and applications running on the operating system. The operating system (OS) may include a device driver that provides an interface to a storage device (33a) to the applications, and an attacker (32a) may be included in the device driver as software or may exist between the device driver and the storage device (33a) and may cause a relay attack as described below.

[0031] In step S30a, the host (31a) may issue a first write request (REQ1), and the attacker (32a) may receive the first write request (REQ1). As described above with reference to FIG. 2, the first write request (REQ1) may include a plurality of fields, and among the plurality of fields, the message type may have a value corresponding to the write request (e.g., 0003h). In step S31a, the attacker (32a) may store the first write request (REQ1). The attacker (32a) may store the first write request (REQ1) provided by the host (31a) in step S30a in order to provide the first write request (REQ1) to the storage device (33a) in step S36a described later.

[0032] In step S32a, the attacker (32a) may provide a second write request (REQ2) to the storage device (33a). The attacker (32a) may generate a second write request (REQ2) different from the first write request (REQ1) and provide the second write request (REQ2) to the storage device (33a) in order to obtain a response indicating a failure of verification of the write request, i.e., the first response (RES1) of step S34a. In some embodiments, the attacker (32a) may generate the second write request (REQ2) by modifying at least one field included in the first write request (REQ1), such as a Message Authentication Code (MAC) and / or data.

[0033] In step S33a, the storage device (33a) can determine that the verification of the second write request (REQ2) has failed. For example, the storage device (33a) may determine the device key (KEY DA message verification code (MVC) generated based on at least one field included in the second write request (REQ2) can be compared with a message authentication code (MAC) included in the second write request (REQ2), and in response to the fact that the message verification code and the message authentication code (MAC) are different, it can be identified that the second write request (REQ2) is not an authenticated request.

[0034] In step S34a, the storage device (33a) may issue a first response (RES1) indicating a failure to verify the second write request (REQ2), and the attacker (32a) may receive the first response (RES1). In step S35a, the attacker (32a) may store the first response (RES1). The attacker (32a) may store the first response (RES1) provided from the storage device (33a) in step S34a in order to provide the first response (RES1) to the host (31a) in step S39a described later.

[0035] In step S36a, the attacker (32a) may provide the first write request (REQ1) to the storage device (33a). The attacker (32a) may provide the first write request (REQ1) stored in step S31a to the storage device (33a) as is.

[0036] In step S33a, the storage device (33a) can determine the success of the verification of the first write request (REQ1). In step S36a, since the first write request (REQ1) provided by the attacker (32a) matches the one issued by the host (31a) in step S30a, the storage device (33a) can identify the first write request (REQ1) as an authenticated request. Accordingly, the data contained in the first write request (REQ1) can be successfully written to the storage device (33a).

[0037] In step S38a, the storage device (33a) may issue a second response (RES2) indicating the success of the verification of the first write request (REQ1), and the attacker (32a) may receive the second response (RES2) from the storage device (33a). In step S39a, the attacker (32a) may provide the first response (RES1) to the host (31a). Instead of the second response (RES2) indicating the success of the verification of the first write request (REQ1), the attacker (32a) may provide the first response (RES1) stored in step S35a, indicating the failure of the verification of the second write request (REQ2), to the host (31a). Accordingly, the host (31a) can identify that the write operation requested through the first write request (REQ1) issued in step S30a has failed, whereas the storage device (33a) can normally store the data requested to be written through the first write request (REQ1). As a result, due to the attacker (32a), the host (31a) can identify a state different from the actual state of the storage device (33a), and an error may occur in the system including the host (31a) and the storage device (33a).

[0038] Referring to FIG. 3b, in step S30b, the host (31b) may issue a first write request (REQ1), and the attacker (32b) may receive the first write request (REQ1). In step S31b, the attacker (32b) may store the first write request (REQ1). The attacker (32b) may store the first write request (REQ1) provided by the host (31b) in step S30b in order to provide the first write request (REQ1) to the storage device (33b) in step S33b, which is described later. As illustrated in FIG. 3b, the attacker (32b) may not provide any write requests to the storage device (33b) after storing the first write request (REQ1).

[0039] In step S32b, the host (31b) may issue a second write request (REQ2), and the attacker (32b) may receive the second write request (REQ2). For example, the host (31b) may issue a second write request (REQ2) containing second data that is different from the first data included in the first write request (REQ1).

[0040] In step S33b, the attacker (32b) may provide a first write request (REQ1) to the storage device (33b). The attacker (32b) may provide the first write request (REQ1) stored in step S31b to the storage device (33b) as is, instead of the second write request (REQ2) received in step S32b, in order to write the second data.

[0041] In step S34b, the storage device (33b) can determine the success of the verification of the first write request (REQ1). In step S33b, since the first write request (REQ1) provided by the attacker (32b) matches the one issued by the host (31b) in step S30b, the storage device (33b) can identify the first write request (REQ1) as an authenticated request. Accordingly, the first data included in the first write request (REQ1) can be successfully written to the storage device (33b).

[0042] In step S35b, the storage device (33b) may issue a first response (RES1) indicating the successful verification of the first write request (REQ1), and the attacker (32b) may receive the first response (RES1) from the storage device (33b). In step S36b, the attacker (32b) may provide the first response (RES1) to the host (31b). Accordingly, the host (31b) may identify that the write operation of the second data requested through the second write request (REQ2) issued in step S32b has succeeded, while the storage device (33b) may store the first data requested for write through the first write request (REQ1). Consequently, due to the attacker (32b), the host (31b) may identify a state different from the actual state of the storage device (33b), and an error may occur in the system including the host (31b) and the storage device (33b).

[0043] FIG. 4 is a message diagram illustrating a method for writing data to a protected area according to an exemplary embodiment of the present disclosure. Compared to the examples of FIG. 3a and FIG. 3b, the writing request in the example of FIG. 4 may include a random number, i.e., a nonce.

[0044] Referring to FIG. 4, in step S401, the host (41) requests a write counter readout (REQ WC ) can be provided to the storage device (42). For example, a write counter read request (REQ WC Among the multiple fields included in ), the message type may have a value corresponding to the write counter read request (e.g., 0002h).

[0045] In step S402, the storage device (42) writes a read counter response (RES WC ) can be provided to the host (41). For example, a write counter read response (RES WCAmong the multiple fields included in ), the message type may have a value corresponding to the write counter read response (e.g., 0200h), and the read counter is a device write counter (K D ) can have. The host (41) has a host write counter (K H ) Write counter read response (RES WC Device write counter (K) included in ) D It can be set to ).

[0046] In step S403, the host (41) can generate a first nonce (N1). For example, the host (41) can generate a first nonce (N1) corresponding to a random number generated by a random number generator, and accordingly, the first nonce (N1) may be different from the nonce included in a previously issued write request.

[0047] In step S404, the host (41) has a first host message authentication code (MAC H1 ) can be generated. For example, as shown in FIG. 4, the host (41) can generate the first data (D1), the host write counter (K H ), first nonce (N1) and host key (KEY H Based on the hash function (h) from ), the first host message authentication code (MAC H1 ) can be generated. Accordingly, the first host message authentication code (MAC H1 ) can rely on the first nonce (N1) generated in step S403.

[0048] In step S405, the host (41) may provide a first request (REQ1) to the storage device (42). For example, among the multiple fields included in the first request (REQ1), the message type may have a value corresponding to an authenticated data write request (e.g., 0003h). As illustrated in FIG. 4, the first request (REQ1) is a first host message authentication code (MAC H1 ), 1st data (D1), host write counter (KH It may include ) and a first nonce (N1). The first request (REQ1) may be a write request requesting the write of the first data (D1) to a protected area, and a host write counter (K) included in the first request (REQ1). H ) is the device write counter (K) received from the storage device (42) in step S402. D It can match ).

[0049] In step S406, the host (41) may store the first nonce (N1). As described below, the storage device (42) may use the first nonce (N1) when generating a response corresponding to the first request (REQ1), i.e., the first response (RES1) of step S410, and the host (41) may store the first nonce (N1) for verification of the first response (RES1). For example, the host (41) may store the first nonce (N1) in a security register.

[0050] In step S407, the storage device (42) can verify the first request (REQ1). For example, the storage device (42) can verify the device key (KEY D ) and the first host message authentication code (H1), first data (D1), and host write counter (K) included in the first request (REQ1). H The first request (REQ1) can be verified based on ) and the first nonce (N1). The storage device (42) is a host write counter (K H In addition, the first request (REQ1) can be verified based on the first nonce (N1), and accordingly, a man-in-the-middle (MITM) attack can be detected as described below with reference to FIG. 10a and FIG. 10b. If the verification of the first request (REQ1) is successful, the storage device (42) can write the first data (D1) to the protected area. An example of step S407 will be described below with reference to FIG. 5.

[0051] In step S408, the storage device (42) is a device write counter (K D) can be updated. For example, the storage device (42) can update the device write counter (K) based on the verification result of the first request (REQ1) in step S407. D ) can be updated, and accordingly, the device write counter (K D ) may be maintained or changed. An example of step S408 will be described later with reference to FIG. 6.

[0052] In step S409, the storage device (42) has a first device message authentication code (MAC D1 ) can be generated. For example, as shown in FIG. 4, the storage device (42) can generate a device write counter (K D ), first nonce (N1) and device key (KEY D Based on the hash function (h) from ), the first device message authentication code (MAC D1 ) can be generated. A device write counter (K) used to generate the first device message authentication code (MADC1). D ) can have the value updated in step S408.

[0053] In step S410, the storage device (42) may provide a first response (RES1) to the host (41). For example, among the multiple fields included in the first response (RES1), the message type may have a value corresponding to an authenticated data write response (e.g., 0300h). As illustrated in FIG. 4, the first response (RES1) is a first device message authentication code (MAC) generated in step S409. D1 It may include ). Additionally, the first response (RES1) may include a result, and the result may have a value corresponding to success or failure depending on the verification result of the first request (REQ1) of step S407.

[0054] In step S411, the host (41) can verify the first response (RES1). For example, the host (41) can verify the host key (KEY H), 1st nonce (N1), host write counter (K H ), first device message authentication code (MAC D1 The first response (RES1) can be verified based on ). At this time, when verifying the first response (RES1), the host (41) can verify the host write counter (K H An increased value of ) can be used. The host (41) can verify the first response (RES1) based on the first nonce (N1) preserved in step S406, and accordingly, a man-in-the-middle attack (MTM) can be detected as described below with reference to FIGS. 10a and 10b. If the verification of the first response (RES1) is successful, the host (41) can trust the results contained in the first response (RES1), whereas if the verification of the first response (RES1) fails, the host (41) may not trust the results contained in the first response (RES1). An example of step S411 will be described below with reference to FIG. 7.

[0055] In step S412, the host (41) has a host write counter (K H ) can be updated. For example, the host (41) can update the host write counter (K) based on the verification result of the first response (RES1) in step S411. H ) can be updated, and accordingly, the host write counter (K H ) may be maintained or changed. An example of step S412 will be described later with reference to FIG. 8.

[0056] FIG. 5 is a flowchart illustrating a method for writing data to a protection area according to an exemplary embodiment of the present disclosure. Specifically, the flowchart of FIG. 5 illustrates an example of step S407 of FIG. 4. As described above with reference to FIG. 4, in step S407' of FIG. 5, the storage device (42) may verify a first request (REQ1). As illustrated in FIG. 5, step S407' may include a plurality of steps (S407_1, S407_2, S407_3, S407_4, S407_5, S407_6). In some embodiments, step S407' of FIG. 5 may be performed by the storage device (42) of FIG. 4, and FIG. 5 will be described below with reference to FIG. 4.

[0057] Referring to FIG. 5, in step S407_1, the device write counter (K D ) and host write counter(K H ) can be compared. For example, the storage device (42) has a host write counter (K) included in the first request (REQ1) received from the host (41). H ) is the device entry counter (K) that it manages. D It can be compared with ). As shown in FIG. 5, the device write counter (K D ) and host write counter(K H If ) matches, step S407_2 may be performed subsequently. On the other hand, the device write counter (K D ) and host write counter(K H If ) is different, the verification failure of the first entry request (REQ1) may be determined, and steps S407_7 and S407_8 may be performed subsequently.

[0058] In step S407_2, it can be determined whether the first nonce (N1) is included in the nonce list (NL). As described above with reference to FIGS. 1 and FIGS. 4, etc., the host (41) may generate a random number when generating a write request and may include a nonce corresponding to the random number in the write request, and accordingly, the write request may have a nonce of a unique value. The storage device (42) may collect the nonce included in the request when the request verification fails and may manage a nonce list (NL) containing the collected nonces. In some embodiments, the storage device (42) may store the nonce list (NL) in a memory device (e.g., RAM) and / or a part of memory (e.g., 142 in FIG. 1) included in the controller (e.g., 120 in FIG. 1). If the nonce list (NL) contains a nonce that matches the first nonce (N1), the storage device (42) may identify the first request (REQ1) as invalid. Accordingly, as illustrated in FIG. 5, if the first nonce (N1) is not included in the nonce list (NL), step S407_3 may be performed subsequently. On the other hand, if the first nonce (N1) is included in the nonce list (NL), the verification failure of the first write request (REQ1) may be determined, and steps S407_7 and S407_8 may be performed subsequently.

[0059] In step S407_3, the first host message validation code (MVC H1 ) can be generated. For example, as shown in FIG. 5, the storage device (42) may have a first data (D1), a device write counter (K D ), first nonce (N1) and device key (KEY D Based on the hash function (h) from ), the first host message verification code (MVC H1) can be generated. The storage device (42) can extract the first data (D1) and the first nonce (N1) from the first request (REQ1), and the extracted first data (D1) and the first nonce (N1), as well as the device write counter (K D ) and device key (KEY D Based on ), the first host message validation code (MVC H1 Can generate ).

[0060] In step S407_4, the first host message validation code (MVC H1 ) and the first host message authentication code (MAC H1 ) can be compared. In step S404 of FIG. 4, the first host message authentication code (MAC) by the host (41) H1 The first data (D1) used to generate ), the host write counter (K H ), first nonce (N1) and host key (KEY H ) is, in step S407_3, the first host message verification code (MVC) by the storage device (42). H1 The first data (D1) used to generate ), the device write counter (K D ), first nonce (N1) and device key (KEY D If they match ) respectively, the first host message validation code (MVC H1 ) and the first host message authentication code (MAC H1 ) can match. As shown in FIG. 5, the first host message validation code (MVC H1 ) and the first host message authentication code (MAC H1 If ) matches, the verification of the first request (REQ1) may be determined to be successful, and steps S407_5 and S407_6 may be performed subsequently. On the other hand, the first host message verification code (MVC H1 ) and the first host message authentication code (MAC H1If ) is different, the verification failure of the first request (REQ1) may be determined, and steps S407_7 and S407_8 may be performed subsequently.

[0061] If the verification of the first request (REQ1) is determined to be successful, the result in step S407_5 may be set to a value corresponding to the success. As described above with reference to FIG. 4, the result set in step S407_5 may be included in the first response (RES1) provided by the storage device (42) to the host (41) in response to the first request (REQ1) (or a separate result read request). Then, in step S407_6, the nonce list (NL) may be updated. For example, as shown in FIG. 5, if the verification of the first request (REQ1) is successful, the storage device (42) may delete the nonces included in the nonce list (NL), that is, the nonces stored in the requests that failed verification.

[0062] If it is determined that the verification of the first request (REQ1) has failed, the result in step S407_7 may be set to a value corresponding to the failure. As described above with reference to FIG. 4, the result set in step S407_7 may be included in the first response (RES1) provided by the storage device (42) to the host (41) in response to the first request (REQ1) (or a separate result read request). Then, in step S407_8, the nonce list (NL) may be updated. For example, the storage device (42) may add the first nonce (N1) to the nonce list (NL) if the verification of the first request (REQ1) has failed, as shown in FIG. 5.

[0063] FIG. 6 is a flowchart illustrating a method for writing data to a protection area according to an exemplary embodiment of the present disclosure. Specifically, the flowchart of FIG. 6 illustrates an example of step S408 of FIG. 4. As described above with reference to FIG. 4, in step S408' of FIG. 6, the storage device (42) writes to a device write counter (K) based on the verification result of the first request (REQ1). D ) can be updated. As illustrated in FIG. 6, step S408' may include step S408_2 and step S408_4. In some embodiments, step S408' of FIG. 6 may be performed by the storage device (42) of FIG. 4, and FIG. 6 will be described below with reference to FIG. 4.

[0064] Referring to FIG. 6, the value of the result set in step S408_2 can be identified. As described above with reference to FIG. 5, the storage device (42) can set the result to a value corresponding to success if the verification of the first request (REQ1) is successful, while it can set the result to a value corresponding to failure if the verification of the first request (REQ1) fails. As illustrated in FIG. 6, if the verification of the first request (REQ1) fails, step S408' can be terminated, and accordingly, the device write counter (K D ) can be maintained.

[0065] If the verification of the first request (REQ1) is successful, in step S408_4, the device write counter (K D ) can be increased. For example, as shown in FIG. 6, the storage device (42) has a device write counter (K D ) can be increased by 1, and the increased write counter (K D ) can be stored in a register (e.g., 122 in FIG. 1). As described below with reference to FIG. 8, if the host (41) also succeeds in verifying the first response (RES1), the host write counter (K H) can be increased by 1, and subsequent write requests can be processed validly accordingly.

[0066] FIG. 7 is a flowchart illustrating a method for writing data to a protected area according to an exemplary embodiment of the present disclosure. Specifically, the flowchart of FIG. 7 illustrates an example of step S411 of FIG. 4. As described above with reference to FIG. 4, in step S411' of FIG. 7, the host (41) can verify the first response (RES1). As illustrated in FIG. 7, step S411' may include a plurality of steps (S411_2, S411_4, S411_6, S411_8). In some embodiments, step S411' of FIG. 7 may be performed by the host (41) of FIG. 4, and FIG. 7 will be described below with reference to FIG. 4.

[0067] Referring to FIG. 7, in step S411_2, the first device message verification code (MVC D1 ) can be generated. For example, the host (41) can have an increased host write counter (K) as shown in FIG. 7. H +1), first nonce (N1) and host key (KEY H Based on the hash function (h) from ), the first device message verification code (MVC D1 ) can be generated. As described above with reference to FIGS. 4 and 6, when the writing of the first data (D1) is successfully completed in the storage device (42) by the first request (REQ1), the first device message authentication code (MAC) included in the first response (RES1) D1 ) is the device write counter (K) increased by 1. D It can be generated based on ). Accordingly, the host (41) verifies the first response (RES1), the host key (KEY H ) and the first nonce (N1) preserved in step S406 of FIG. 4, as well as the host write counter (K) increased by 1 H You can use ).

[0068] In step S411_4, the first device message verification code (MVC D1 ) and the first device message authentication code (MAC D1 ) can be compared. In step S409 of FIG. 4, the first device message authentication code (MAC) by the storage device (42) D1 The device write counter (K) used to create ) D ), first nonce (N1) and device key (KEY D ) is, in step S411_2, the first device message verification code (MVC) by the host (41). D1 The incremented host write counter (K) used to generate ) H +1), first nonce (N1) and host key (KEY H If they match ) respectively, the first device message verification code (MVC D1 ) and the first device message authentication code (MAC D1 ) can match. As shown in FIG. 7, the first device message verification code (MVC D1 ) and the first device message authentication code (MAC D1 If ) matches, the verification success of the first response (RES1) can be determined in step S411_6. On the other hand, the first device message verification code (MVC D1 ) and the first device message authentication code (MAC D1 If ) is different, the verification failure of the first response (RES1) may be determined in step S411_8.

[0069] FIG. 8 is a flowchart illustrating a method for writing data to a protected area according to an exemplary embodiment of the present disclosure. Specifically, the flowchart of FIG. 8 illustrates an example of step S412 of FIG. 4. As described above with reference to FIG. 4, in step S412' of FIG. 8, the host (41) writes to a host write counter (K ​​based on the verification result of the first response (RES1). H) can be updated. As illustrated in FIG. 8, step S412' may include step S412_2 and step S412_4. In some embodiments, step S412' of FIG. 8 may be performed by the host (41) of FIG. 4, and FIG. 8 will be described below with reference to FIG. 4.

[0070] Referring to FIG. 8, the verification result of the first response (RES1) can be identified in step S412_2. As described above with reference to FIG. 7, the host (41) has a first device message verification code (MVC D1 ) and the first device message authentication code (MAC D1 While the success of verification of the first response (RES1) can be determined if ) matches, the first device message verification code (MVC D1 ) and the first device message authentication code (MAC D1 If ) is different, it can be determined that the verification of the first response (RES1) has failed. As illustrated in FIG. 8, if the verification of the first response (RES1) fails, step S412' can be terminated, and accordingly, the host write counter (K H ) can be maintained.

[0071] If the verification of the first response (RES1) is successful, in step S412_4, the host write counter (K H ) can be increased. For example, as shown in FIG. 8, the host (41) has a host write counter (K H ) can be increased by 1, and the increased host write counter (K H You can generate a subsequent entry request based on ).

[0072] FIG. 9 is a message diagram illustrating a method for writing data to a protected area according to an exemplary embodiment of the present disclosure. Compared to the example of FIG. 4, in the example of FIG. 9, the storage device (92) may provide a response including a nonce to the host (91). In FIG. 9, the host (91) is assumed to be an authenticated entity capable of accessing the protected area of ​​the storage device (92). In the following description of FIG. 9, any content that overlaps with the description of FIG. 4 will be omitted.

[0073] Referring to FIG. 9, in step S901, the host (91) requests a read counter (REQ WC ) can be provided to the storage device (92), and in step S902, the storage device (92) provides a write counter read response (RES WC ) can be provided to the host (91). For example, a write counter read request (REQ WC Among the multiple fields included in ), the message type may have a value corresponding to a write counter read request (e.g., 0002h), and the write counter read response (RES WC Among the multiple fields included in ), the message type may have a value corresponding to the write counter read response (e.g., 0200h). As shown in FIG. 9, the write counter read response (RES WC ) is the device write counter (K D It may include ).

[0074] In step S903, the host (91) can generate a first nonce (N1). Then, in step S904, the host (91) generates a first host message authentication code (MAC H1 ) can be generated. For example, as shown in FIG. 9, the host (91) can generate the first data (D1), the host write counter (K H ), first nonce (N1) and host key (KEY H Based on ), the first host message authentication code (MAC H1Can generate ).

[0075] In step S905, the host (91) may provide a first request (REQ1) to the storage device (92). For example, among the multiple fields included in the first request (REQ1), the message type may have a value corresponding to an authenticated data write request (e.g., 0003h). As illustrated in FIG. 9, the first request (REQ1) is a first host message authentication code (MAC H1 It may include ) and a first host message authentication code (MAC H1 The first data (D1) used to generate ), the host write counter (K H It may include ) and a first nonce (N1). In step S906, the host (91) may store the first nonce (N1). The first nonce (N1) stored in step S906 may be used to verify the response provided by the storage device (92) in response to the first request (REQ1), i.e., the first response (RES1) of step S909.

[0076] In step S907, the storage device (92) is a device write counter (K D ) can be increased by 1. For example, the storage device (92) can verify a first request (REQ1) provided by an authenticated host (91), and in response to the successful verification of the first request (REQ1), the device write counter (K D ) can be increased by 1. In step S908, the storage device (92) has a first device message authentication code (MAC D1 ) can be generated. As illustrated in FIG. 9, the storage device (92) has a device write counter (K D ), first nonce (N1) and device key (KEY D Based on ), the first device message authentication code (MAC D1 ) can be generated, and at this time, the device write counter (K D ) can have an increased value in step S906.

[0077] In step S909, the storage device (92) may provide a first response (RES1) to the host (91). For example, among the multiple fields included in the first response (RES1), the message type may have a value corresponding to an authenticated data write response (e.g., 0300h). Compared to the first response (RES1) of FIG. 4, the first response (RES1) may further include a first nonce (N1). For example, the storage device (92) may include a first device message authentication code (MAC D1 In addition to the ) and result, a first response (RES1) including a first nonce (N1) can be generated. Accordingly, the host (91) can generate a first device message authentication code (MAC D1 In addition, the first response (RES1) can be verified based on the first nonce (N1) included in the first response (RES1). That is, similar to what was described above with reference to FIG. 5, the host (91) can compare the first nonce (N1) preserved in step S906 with the first nonce (N1) included in the first response (RES1) received in step S909, and if the two first nonces are different, unlike the example shown in FIG. 9, the host (91) can use the first device message authentication code (MAC D1 Regardless of the verification result of ), the verification failure of the first response (RES1) can be determined.

[0078] In step S910, the host (91) has a host write counter (K H ) can be increased by 1. For example, the host (91) can verify the first response (RES1) provided by the storage device (92), and in response to the successful verification of the first response (RES1), the host write counter (K H ) can be increased by 1. Accordingly, the host write counter (K ​​updated in step S910) H ) and the device write counter (K) updated in step S907 D) can match. As described above with reference to FIG. 7, the host (91) has a host write counter (K H Before updating ), the increased host write counter (K H Based on +1), the first device message authentication code (MAC D1 ) can be verified.

[0079] In step S911, the host (91) may generate a second nonce (N2). The second nonce (N2) for the second request (REQ2) and second response (RES2) described below may differ from the first nonce (N1) for the first request (REQ1) and first response (RES1) described above, and may be unpredictable not only by the host (91) but also outside the host (91). Accordingly, each of the write requests issued by the host (91) may have a unique value, i.e., a nonce, and one unique value may be used for an authenticated pair of write requests and responses.

[0080] In step S912, the host (91) receives a second host message authentication code (MAC H2 ) can be generated. For example, the host (91) can generate the second data (D2), the host write counter (K) as shown in FIG. 9. H ), second nonce (N2) and host key (KEY H Based on ), the second host message authentication code (MAC H2 ) can be generated. At this time, the host write counter (K H ) can have an increased value in step S910.

[0081] In step S913, the host (91) may provide a second request (REQ2) to the storage device (92). For example, among the multiple fields included in the second request (REQ2), the message type may have a value corresponding to an authenticated data write request (e.g., 0003h). As illustrated in FIG. 9, the second request (REQ2) is a second host message authentication code (MACH2 It may include ) and a second host message authentication code (MAC H2 The second data (D2) used to generate ), the host write counter (K H It may include ) and a second nonce (N2). In step S914, the host (914) may save the second nonce (N2) and use the second nonce (N2) to verify a subsequent response, i.e., a second response (RES2).

[0082] In step S914, the storage device (92) is a device write counter (K D ) can be increased by 1. For example, the storage device 992) can verify a second request (REQ2) provided by the authenticated host (91), and in response to the successful verification of the second request (REQ2), the device write counter (K D ) can be increased by 1. In step S916, the storage device (92) has a second device message authentication code (MAC D2 ) can be generated. As illustrated in FIG. 9, the storage device (92) has a device write counter (K D ), second nonce (N2) and device key (KEY D Based on ), the second device message authentication code (MAC D2 ) can be generated, and at this time, the device write counter (K D ) can have an increased value in step S195.

[0083] In step S917, the storage device (92) may provide a second response (RES2) to the host (91). For example, among the multiple fields included in the second response (RES2), the message type may have a value corresponding to an authenticated data write response (e.g., 0300h). Similar to the first response (RES1) described above, the second response (RES2) may include a second nonce (N2), and accordingly, the host (91) may have a second device message authentication code (MAC D2In addition, the second response (RES2) can be verified based on the second nonce (N2) included in the second response (RES2). That is, unlike what is shown in FIG. 9, if the second nonce (N2) included in the second response (RES2) and the second nonce (N2) preserved in step S914 are different, the host (91) can determine that the verification of the second response (RES2) has failed.

[0084] In step S918, the host (91) has a host write counter (K H ) can be increased by 1. For example, the host (91) can verify the second response (RES2) provided by the storage device (92), and in response to the successful verification of the second response (RES2), the host write counter (K H ) can be increased by 1. Accordingly, the host write counter (K ​​updated in step S918) H ) and the device write counter (K ​​updated in step S915 D ) can match. As described above with reference to FIG. 7, the host (91) has a host write counter (K H Before updating ), the increased host write counter (K H Based on +1), the second device message authentication code (MAC D2 ) can be verified.

[0085] FIGS. 10a and 10b are message diagrams illustrating examples of a method for writing data to a protected area according to exemplary embodiments of the present disclosure. Specifically, the message diagrams of FIGS. 10a and 10b illustrate examples of operations for detecting man-in-the-middle attacks described with reference to FIGS. 3a and 3b. In the following description of FIGS. 10a and 10b, content that overlaps with content described with reference to the drawings will be omitted.

[0086] Referring to FIG. 10a, in step S101a, the host (101a) requests a write counter readout (REQ WC) can issue, and the attacker (102a) can request a read counter (REQ WC It can receive ). For example, a write counter read request (REQ WC Among the multiple fields included in ), the message type may have a value corresponding to a write counter read request (e.g., 0002h). In step S102a, the attacker (102a) requests a write counter read (REQ WC ) can be transmitted directly to the storage device (103a), and the storage device (103a) can read the write counter (REQ WC Can receive ).

[0087] In step S103a, the storage device (103a) has a write counter read response (RES WC ) can issue, and the attacker (102a) can write counter read response (RES WC ) can be received. For example, write counter read response (RES WC Among the multiple fields included in ), the message type may have a value corresponding to the write counter read response (e.g., 0200h). In step S104a, the attacker (102a) obtains the write counter read response (RES WC ) can be transmitted to the host (101a) as is, and the host (101a) write counter read response (RES WC ) can be received. As illustrated in FIG. 10a, a write counter read response (RES) can be received. WC ) is the device write counter (K D It may include ).

[0088] In step S105a, the host (101a) can generate a first nonce (N1). In step S106a, for a first request (REQ1), the host (101a) can generate first data (D1), a host write counter (K H ), first nonce (N1) and host key (KEY H Based on ), the first host message authentication code (MAC H1) can be generated. In step S107a, the host (101a) generates a first host message authentication code (MAC) for writing the first data (D1). H1 ), 1st data (D1), host write counter (K H A first request (REQ1) including ) and a first nonce (N1) can be issued. For example, among the multiple fields included in the first request (REQ1), the message type may have a value corresponding to an authenticated data entry request (e.g., 0003h).

[0089] In step S108a, the attacker (102a) may store the first request (REQ1). As described above with reference to FIG. 3a, the attacker (102a) may store the first request (REQ1) received from the authenticated host (101a) in step S107a in order to subsequently provide the first request (REQ1) to the storage device (103a). Then, in step S109a, the attacker (102a) may provide the modified first request (REQ1') to the storage device (103a). For example, among the multiple fields included in the modified first request (REQ1'), the message type may have a value corresponding to the authenticated data write request (e.g., 0003h). The attacker (102a) may generate the modified first request (REQ1') from the first request (REQ1) to obtain a response indicating a failure of verification of the write request. For example, as illustrated in FIG. 10a, an attacker (102a) can generate a modified first data (D1') from the first data (D1), and a modified first host message authentication code (MAC) based on the modified first data (D1'). H1 ') can be generated. Accordingly, as illustrated in FIG. 10a, the modified first request (REQ1') is the modified first host message authentication code (MAC H1 '), modified first data (D1'), host write counter (K HIt may include ) and the first nonce (N1).

[0090] In step S110a, the storage device (103a) can determine that the verification of the modified first request (REQ1') has failed. For example, the storage device (103a) may have a device write counter (K D Host write counter (K) matching ) H ) can be identified, but the changed first data (D1'), device write counter (K D ), first nonce (N1) and device key (KEY D The first host message authentication code (MAC) with the changed host message verification code generated based on ) H1 It is possible to identify differences from '). Accordingly, as illustrated in FIG. 10a, the storage device (103a) can set the result to a value corresponding to failure.

[0091] In step S111a, the storage device (103a) has a first device message authentication code (MAC D1 ) can be generated. For example, as shown in FIG. 10a, the storage device (103a) has a device write counter (K D ), first nonce (N1) and device key (KEY D Based on ), the first device message authentication code (MAC D1 ) can be generated. Due to the failure to validate the modified first request (REQ1'), the first device message authentication code (MAC D1 The device write counter (K) used to create ) D ) can be maintained and may have the value provided to the host (101a) in step S103a.

[0092] In step S112a, the storage device (130a) may issue a first response (RES1), and the attacker (102a) may receive the first response (RES1). For example, among the multiple fields included in the first response (RES1), the message type may have a value corresponding to an authenticated data write response (e.g., 0300h). As illustrated in FIG. 10a, the first response (RES1) is a first device message authentication code (MAC D1 It may include ) and results, and the results may have a value corresponding to failure as set in step S110a.

[0093] In step S113a, the attacker (102a) may store the first response (RES1). As described above with reference to FIG. 3a, the attacker (102a) may store the first response (RES1) received from the storage device (103a) in step S112a in order to provide the first response (RES1) to the host (101a) later. Then, in step S114a, the attacker (102a) may provide the first request (REQ1) to the storage device (103a). The attacker (102a) may provide the first request (REQ1) stored in step S108a to the storage device (103a) after obtaining the first response (RES1) from the storage device (103a).

[0094] In step S115a, the storage device (130a) can determine that the verification of the first request (REQ1) has failed. Although the first request (REQ1) matches the one issued by the authenticated host (101a) in step S107a, the storage device (103a) can identify that the first nonce (N1) included in the first request (REQ1) matches the first nonce (N1) used during the verification of the first request (REQ1') changed in step S110a. Accordingly, the storage device (103a) can determine that the verification of the first request (REQ1) has failed as described above with reference to FIG. 5, and can set the result to a value corresponding to the failure as illustrated in FIG. 10a. Accordingly, unlike the example in FIG. 3a, the writing of the first data (D1) to the storage device (103a) may fail.

[0095] In step S116a, the storage device (103a) is a second device message authentication code (MAC D2 ) can be generated. For example, as shown in FIG. 10a, the storage device (103a) has a device write counter (K D ), first nonce (N1) and device key (KEY D Based on ), the first device message authentication code (MAC D1 ) can be generated. Due to the verification failure of the first request (REQ1), the second device message authentication code (MAC D2 The device write counter (K) used to create ) D ) can be maintained and may have the value provided to the host (101a) in step S103a.

[0096] In step S117a, the storage device (103a) may issue a second response (RES2), and the attacker (102a) may receive the second response (RES2). For example, among the multiple fields included in the second response (RES2), the message type may have a value corresponding to an authenticated data write response (e.g., 0300h). As illustrated in FIG. 10a, the second response (RES2) is a second device message authentication code (MAC D2 It may include ) and results, and the results may have a value corresponding to failure as set in step S115a. Accordingly, the attacker (102a) can identify a failure to write the first data (D1), unlike the example in FIG. 3a.

[0097] Despite the failure to write the first data (D1), the attacker (102a) may provide the first response (RES1) received from the storage device (103a) at step S112a to the host (101a), as in the example of FIG. 3a. In this case, the host (101a) may generate a message verification code to verify the first response (RES1), and the message verification code is a first device message authentication code (MAC) included in the first response (RES1). D1It can match with ). Accordingly, the host (101a) can determine the success of the verification of the first response (RES1) and can trust the write failure indicated by the result included in the first response (RES1). Additionally, even if the attacker (102a) provides the host (101a) with the second response (RES2) received from the storage device (103a) in step S117a, the host (101a) can determine the success of the verification of the second response (RES2) and can trust the write failure indicated by the result included in the second response (RES2). Consequently, the host (101a) can identify a first state in which the first data (D1) is not written to the storage device (103a), and the attacker (102a) can fail to create a state different from the first state, that is, a second state in which the first data (D1) is successfully written to the storage device (103a).

[0098] Referring to FIG. 10b, in step S101b, the host (101b) requests a read counter (REQ WC ) can issue, and the attacker (102b) can request a read counter (REQ WC It can receive ). For example, a write counter read request (REQ WC Among the multiple fields included in ), the message type may have a value corresponding to a write counter read request (e.g., 0002h). In step S102b, the attacker (102b) requests a write counter read (REQ WC ) can be transmitted to the storage device (103b) as is, and the storage device (103b) can read the write counter request (REQ WC Can receive ).

[0099] In step S103b, the storage device (103b) has a write counter read response (RES WC ) can issue, and the attacker (102b) can write counter read response (RES WC ) can be received. For example, write counter read response (RES WCAmong the multiple fields included in ), the message type may have a value corresponding to the write counter read response (e.g., 0200h). In step S104b, the attacker (102b) obtains the write counter read response (RES WC ) can be transmitted to the host (101b) as is, and the host (101b) write counter read response (RES WC ) can be received. As illustrated in FIG. 10b, a write counter read response (RES) can be received. WC ) is the device write counter (K D It may include ).

[0100] In step S105b, the host (101b) can generate a first nonce (N1). In step S106b, for a first request (REQ1), the host (101b) can generate first data (D1), a host write counter (K H ), first nonce (N1) and host key (KEY H Based on ), the first host message authentication code (MAC H1 ) can be generated. In step S107b, the host (101b) generates a first host message authentication code (MAC) for writing the first data (D1). H1 ), 1st data (D1), host write counter (K H A first request (REQ1) including ) and a first nonce (N1) can be issued, and the attacker (102b) can receive the first request (REQ1). For example, among the multiple fields included in the first request (REQ1), the message type may have a value corresponding to an authenticated data entry request (e.g., 0003h).

[0101] In step S108b, the host (101b) may store the first nonce (N1) for verification of the response corresponding to the first request (REQ1). In step S109b, the attacker (102b) may store the first request (REQ1). As described above with reference to FIG. 3b, the attacker (102b) may store the first request (REQ1) received from the authenticated host (101b) in step S107b in order to provide the first request (REQ2) to the storage device (103b) later.

[0102] In step S110b, the host (101b) may generate a second nonce (N2). The second nonce (N2) for the second request (REQ2) may be different from the first nonce (N1) used to generate the first request (REQ1). In step S111b, for the second request (REQ2), the host (101b) generates second data (D2), a host write counter (K H ), second nonce (N2) and host key (KEY H Based on ), the second host message authentication code (MAC H2 ) can be generated. At this time, the host write counter (K H Since ) did not receive a response indicating the success of the write operation for the first request (REQ1), in step S106b, the first host message authentication code (MAC H1 Host write counter (K) used when creating ) H It can match ). In step S112b, the host (101b) writes the second host message authentication code (MAC) for the second data (D2). H2 ), second data (D2), host write counter (K HA second request (REQ2) including ) and a second nonce (N2) can be issued, and the attacker (102b) can receive the second request (REQ2). For example, among the multiple fields included in the second request (REQ2), the message type may have a value corresponding to an authenticated data write request (e.g., 0003h). In step S113b, the host (101b) may store the second nonce (N2).

[0103] In step S114b, the attacker (102b) may provide the first request (REQ1) to the storage device (103b). The attacker (102b) may provide the first request (REQ1) stored in step S108b to the storage device (103b) as is, and accordingly, as illustrated in FIG. 10b, the first host message authentication code (MAC H1 ), 1st data (D1), host write counter (K H A first request (REQ1) including ) and a first nonce (N1) may be provided to the storage device (103b).

[0104] In step S115b, the storage device (103b) can determine the success of the verification of the first request (REQ1). For example, the storage device (103b) may have a device write counter (K D Host write counter (K) matching ) H ), and can identify a first nonce (N1) that is different from the previous nonce (N0), and a first host message authentication code (MAC H1 A message verification code matching ) can be generated. Accordingly, as illustrated in FIG. 10b, the storage device (103b) can set the result to a value corresponding to success.

[0105] In step S116b, the storage device (103b) is a first device message authentication code (MAC D1 ) can be generated. For example, as illustrated in FIG. 10b, the storage device (103b) has a device write counter (K D), first nonce (N1) and device key (KEY D Based on ), the first device message authentication code (MAC D1 ) can be generated. Based on the successful verification of the first request (REQ1), the first device message authentication code (MAC D1 The device write counter (K) used to create ) D ) can have a value increased by 1 compared to the value provided to the host (101b) in step S103b.

[0106] In step S117b, the storage device (103b) may issue a first response (RES1), and the attacker (102b) may receive the first response (RES1). For example, among the multiple fields included in the first response (RES1), the message type may have a value corresponding to an authenticated data write response (e.g., 0300h). As illustrated in FIG. 10b, the first response (RES1) is a first device message authentication code (MAC D1 It may include ) and results, and the results may have a value corresponding to success as set in step S115b. In step S118b, the attacker (102b) may transmit the first response (RES1) as is to the host (101b).

[0107] In step S119b, the host (101b) can determine that the verification of the first response (RES1) has failed. The first device message authentication code (MAC) included in the first response (RES1) D1 While the first nonce (N1) is generated based on the first nonce (N1) in step S116b, the message verification code generated by the host (101b) in step S119b can be generated based on the second nonce (N2) preserved in step S113b. Accordingly, the first device message authentication code (MAC D1) may differ from the message verification code, and the host (101b) may determine that the verification of the first response (RES1) has failed. In some embodiments, as described above with reference to FIG. 9, if the first response (RES1) contains a first nonce (N1), the host (101b) may identify that the first nonce (N1) is different from the second nonce (N2) and thus determine that the verification of the first response (RES1) has failed. Accordingly, the host (101b) may not trust the success of the write indicated by the result included in the first result (RES1). Consequently, the attacker (102b) may fail to cause the host (101b) to identify the state of the storage device (103b), that is, a state different from the first state in which the second data (D2) is not stored, i.e., the second state in which the second data (D2) is stored in the storage device (103b).

[0108] FIG. 11 is a diagram illustrating a system to which a storage device according to an embodiment of the present invention is applied. The system (1000) of FIG. 11 may basically be a mobile system such as a portable communication terminal (mobile phone), a smartphone, a tablet PC (tablet personal computer), a wearable device, a healthcare device, or an IoT (Internet of Things) device. However, the system (1000) of FIG. 11 is not necessarily limited to a mobile system and may be a personal computer, a laptop computer, a server, a media player, or an automotive device such as a navigation system. Hereinafter, the subscripts attached to the reference numbers (e.g., a in 1200a, a in 1300a) are intended to distinguish multiple circuits that perform the same function.

[0109] Referring to FIG. 11, the system (1000) may include a main processor (1100), memory (1200a, 1200b) and storage devices (1300a, 1300b), and additionally may include one or more of an image capturing device (1410), a user input device (1420), a sensor (1430), a communication device (1440), a display (1450), a speaker (1460), a power supplying device (1470), and a connecting interface (1480).

[0110] The main processor (1100) can control the overall operation of the system (1000), more specifically, the operation of other components that make up the system (1000). Such a main processor (1100) can be implemented as a general-purpose processor, a dedicated processor, or an application processor.

[0111] The main processor (1100) may include one or more CPU cores (1110) and may further include a controller (1120) for controlling memory (1200a, 1200b) and / or storage devices (1300a, 1300b). According to an embodiment, the main processor (1100) may further include an accelerator block (1130), which is a dedicated circuit for high-speed data computation, such as artificial intelligence (AI) data computation. Such an accelerator block (1130) may include a Graphics Processing Unit (GPU), a Neural Processing Unit (NPU), and / or a Data Processing Unit (DPU), and may be implemented as a separate chip physically independent from other components of the main processor (1100).

[0112] The memory (1200a, 1200b) can be used as the main memory of the system (1000) and may include volatile memory such as SRAM and / or DRAM, but may also include non-volatile memory such as flash memory, PRAM and / or RRAM. The memory (1200a, 1200b) may also be implemented within the same package as the main processor (1100).

[0113] The storage device (1300a, 1300b) can function as a non-volatile storage device that stores data regardless of whether power is supplied, and can have a relatively large storage capacity compared to the memory (1200a, 1200b). The storage device (1300a, 1300b) may include a storage controller (1310a, 1310b) and a non-volatile memory (NVM) storage (1320a, 1320b) that stores data under the control of the storage controller (1310a, 1310b). The non-volatile storage (1320a, 1320b) may include V-NAND flash memory with a 2D (2-dimensional) or 3D (3-dimensional) structure, but may also include other types of non-volatile memory such as PRAM and / or RRAM.

[0114] The storage device (1300a, 1300b) may be included in the system (1000) in a state physically separated from the main processor (1100), or it may be implemented within the same package as the main processor (1100). Additionally, the storage device (1300a, 1300b) may have a form such as a memory card and may be detachably coupled to other components of the system (1000) through an interface such as the connection interface (1480) described later. Such storage device (1300a, 1300b) may be a device to which standard protocols such as UFS (universal flash storage) are applied, but it is not necessarily limited thereto.

[0115] The shooting device (1410) can take still images or video and may be a camera, camcorder and / or webcam, etc.

[0116] The user input device (1420) can receive various types of data input from a user of the system (1000) and may be a touch pad, keypad, keyboard, mouse and / or microphone, etc.

[0117] The sensor (1430) can detect various types of physical quantities that may be obtained from outside the system (1000) and convert the detected physical quantities into electrical signals. Such a sensor (1430) may be a temperature sensor, a pressure sensor, an illuminance sensor, a position sensor, an acceleration sensor, a biosensor and / or a gyroscope, etc.

[0118] The communication device (1440) can transmit and receive signals between other devices outside the system (1000) according to various communication protocols. Such a communication device (1440) may be implemented including an antenna, a transceiver and / or a modem.

[0119] The display (1450) and speaker (1460) can function as output devices that output visual information and auditory information, respectively, to the user of the system (1000).

[0120] The power supply unit (1470) can appropriately convert power supplied from a battery (not shown) and / or an external power source built into the system (1000) and supply it to each component of the system (1000).

[0121] The connection interface (1480) can provide a connection between the system (1000) and an external device connected to the system (1000) that can exchange data with the system (1000). The connection interface (1480) 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.

[0122] FIG. 12 is a drawing for explaining a UFS system (2000) according to an embodiment of the present invention. The UFS system (2000) is a system that follows the UFS standard published by JEDEC (Joint Electron Device Engineering Council) and may include a UFS host (2100), a UFS device (2200), and a UFS interface (2300). The description of the system (1000) of FIG. 11 described above may also be applied to the UFS system (2000) of FIG. 12 to the extent that it does not conflict with the following description of FIG. 12.

[0123] Referring to FIG. 12, the UFS host (2100) and the UFS device (2200) can be interconnected via a UFS interface (2300). If the main processor (1100) of FIG. 11 is an application processor, the UFS host (2100) can be implemented as part of the application processor. The UFS host controller (2110) and the host memory (2140) can correspond to the controller (1120) and memory (1200a, 1200b) of the main processor (1100) of FIG. 11, respectively. The UFS device (2200) may correspond to the storage device (1300a, 1300b) of FIG. 11, and the UFS device controller (2210) and non-volatile storage (2220) may correspond to the storage controller (1310a, 1310b) and non-volatile storage (1320a, 1320b) of FIG. 11, respectively.

[0124] A UFS host (2100) may include a UFS host controller (2110), an application (2120), a UFS driver (2130), a host memory (2140), and a UIC (UFS interconnect) layer (2150). A UFS device (2200) may include a UFS device controller (2210), non-volatile storage (2220), a storage interface (2230), a device memory (2240), a UIC layer (2250), and a regulator (2260). The non-volatile storage (2220) may be composed of a plurality of storage units (2221), and such storage units (2221) may include V-NAND flash memory of a 2D or 3D structure, but may also include other types of non-volatile memory such as PRAM and / or RRAM. The UFS device controller (2210) and the non-volatile storage (2220) can be connected to each other through a storage interface (2230). The storage interface (2230) can be implemented to comply with standard protocols such as Toggle or ONFI.

[0125] The application (2120) may refer to a program that wishes to communicate with the UFS device (2200) in order to use the functions of the UFS device (2200). The application (2120) may send an input-output request (IOR) to the UFS driver (2130) for input / output to the UFS device (2200). The input-output request (IOR) may refer to a data read request, a write request, and / or a discard request, but is not necessarily limited thereto.

[0126] The UFS driver (2130) can manage the UFS host controller (2110) through the UFS-HCI (host controller interface). The UFS driver (2130) can convert an I / O request generated by an application (2120) into a UFS command defined by the UFS standard and transmit the converted UFS command to the UFS host controller (2110). A single I / O request can be converted into multiple UFS commands. The UFS commands may be commands defined by the SCSI standard by default, but they may also be commands specific to the UFS standard.

[0127] The UFS host controller (2110) can transmit UFS commands converted by the UFS driver (2130) to the UIC layer (2250) of the UFS device (2200) through the UIC layer (2150) and the UFS interface (2300). In this process, the UFS host register (2111) of the UFS host controller (2110) can serve as a command queue (CQ).

[0128] The UIC layer (2150) on the UFS host (2100) side may include MIPI M-PHY (2151) and MIPI UniPro (2152), and the UIC layer (2250) on the UFS device (2200) side may also include MIPI M-PHY (2251) and MIPI UniPro (2252).

[0129] The UFS interface (2300) may include a line transmitting a reference clock (REF_CLK), a line transmitting a hardware reset signal (RESET_n) for the UFS device (2200), a pair of lines transmitting a differential input signal pair (DIN_t and DIN_c), and a pair of lines transmitting a differential output signal pair (DOUT_t and DOUT_c).

[0130] The frequency value of the reference clock (REF_CLK) provided from the UFS host (2100) to the UFS device (2200) may be one of four values: 19.2 MHz, 26 MHz, 38.4 MHz, and 52 MHz, but is not necessarily limited thereto. The UFS host (2100) may change the frequency value of the reference clock (REF_CLK) even while in operation, that is, while data transmission and reception is being performed between the UFS host (2100) and the UFS device (2200). The UFS device (2200) may generate clocks of various frequencies from the reference clock (REF_CLK) provided from the UFS host (2100) using a phase-locked loop (PLL), etc. Additionally, the UFS host (2100) may set the value of the data rate between the UFS host (2100) and the UFS device (2200) through the frequency value of the reference clock (REF_CLK). That is, the value of the data rate may be determined based on the frequency value of the reference clock (REF_CLK).

[0131] The UFS interface (2300) may support multiple lanes, and each lane may be implemented as a differential pair. For example, the UFS interface may include one or more receive lanes and one or more transmit lanes. In FIG. 12, a pair of lines transmitting a differential input signal pair (DIN_T and DIN_C) may each constitute a receive lane, and a pair of lines transmitting a differential output signal pair (DOUT_T and DOUT_C) may each constitute a transmit lane. Although FIG. 12 shows one transmit lane and one receive lane, the number of transmit lanes and receive lanes may be changed.

[0132] The receiving lane and the transmitting lane can transmit data in a serial communication manner, and full-duplex communication between the UFS host (2100) and the UFS device (2200) is possible due to the structure in which the receiving lane and the transmitting lane are separated. That is, the UFS device (2200) can transmit data to the UFS host (2100) through the transmitting lane even while receiving data from the UFS host (2100) through the receiving lane. In addition, control data such as commands from the UFS host (2100) to the UFS device (2200), and user data that the UFS host (2100) intends to store in the non-volatile storage (2220) of the UFS device (2200) or read from the non-volatile storage (2220) can be transmitted through the same lane. Accordingly, there is no need to provide additional lanes for data transmission between the UFS host (2100) and the UFS device (2200) in addition to a pair of receiving lanes and a pair of transmitting lanes.

[0133] The UFS device controller (2210) of the UFS device (2200) can control the overall operation of the UFS device (2200). The UFS device controller (2210) can manage non-volatile storage (2220) through a logical unit (LU) (2211), which is a logical data storage unit. The number of LUs (2211) may be eight, but is not limited thereto. The UFS device controller (2210) may include a flash translation layer (FTL) and can convert a logical data address, such as a logical block address (LBA), transmitted from the UFS host (2100) into a physical data address, such as a physical block address (PBA), using the address mapping information of the FTL. A logical block for storing user data in the UFS system (2000) may have a size within a predetermined range. For example, the minimum size of a logical block can be set to 4Kbyte.

[0134] When a command from the UFS host (2100) is input to the UFS device (2200) through the UIC layer (2250), the UFS device controller (2210) performs an operation according to the input command, and when the operation is completed, it can send a completion response to the UFS host (2100).

[0135] For example, if the UFS host (2100) intends to store user data in the UFS device (2200), the UFS host (2100) may send a data storage command to the UFS device (2200). When the UFS host (2100) receives a response from the UFS device (2200) that the user data is ready to be transferred, the UFS host (2100) may transfer the user data to the UFS device (2200). The UFS device controller (2210) may temporarily store the transferred user data in the device memory (2240) and, based on the address mapping information of the FTL, store the user data temporarily stored in the device memory (2240) in a selected location of the non-volatile storage (2220).

[0136] As another example, if the UFS host (2100) intends to read user data stored in the UFS device (2200), the UFS host (2100) may transmit a data read command to the UFS device (2200). Upon receiving the command, the UFS device controller (2210) may read user data from the non-volatile storage (2220) based on the data read command and temporarily store the read user data in the device memory (2240). During this read process, the UFS device controller (2210) may detect and correct errors in the read user data using an embedded ECC (error correction code) circuit (not shown). Then, the UFS device controller (2210) may transmit the user data temporarily stored in the device memory (2240) to the UFS host (2100). In addition, the UFS device controller (2210) may further include an AES (advanced encryption standard) circuit (not shown), and the AES circuit can encrypt or decrypt data input to the UFS device controller (2210) using a symmetric-key algorithm.

[0137] The UFS host (2100) can store commands to be transmitted to the UFS device (2200) in order in a UFS host register (2111) that can function as a command queue, and can transmit commands to the UFS device (2200) in the said order. At this time, the UFS host (2100) can transmit the next command waiting in the command queue to the UFS device (2200) even if the previously transmitted command is still being processed by the UFS device (2200), that is, before receiving notification that the previously transmitted command has been completed by the UFS device (2200), and accordingly, the UFS device (2200) can also receive the next command from the UFS host (2100) even while processing the previously transmitted command. The maximum number of commands that can be stored in such a command queue (queue depth) may be, for example, 32. Additionally, the command queue can be implemented as a circular queue type, which indicates the start and end of the column of commands stored in the queue through a head pointer and a tail pointer, respectively.

[0138] Each of the plurality of storage units (2221) may include a memory cell array and a control circuit that controls the operation of the memory cell array. The memory cell array may include a two-dimensional memory cell array or a three-dimensional memory cell array. The memory cell array includes a plurality of memory cells, and each memory cell may be a single-level cell (SLC) that stores 1 bit of information, but may also be a cell that stores 2 bits or more of information, such as an MLC (multi-level cell), TLC (triple-level cell), or QLC (quadruple-level cell). The three-dimensional memory cell array may include a vertically oriented NAND string such that at least one memory cell is positioned above another memory cell.

[0139] VCC, VCCQ1, VCCQ2, etc., may be input as power voltages to the UFS device (2200). VCC is the main power voltage for the UFS device (2200) and may have a value of 2.4 to 3.6 V. VCCQ is a power voltage for supplying a low range of voltage, mainly for the UFS device controller (2210), and may have a value of 1.14 to 1.26 V. VCCQ2 is a power voltage for supplying a range of voltage lower than VCC but higher than VCCQ, mainly for an input / output interface such as MIPI M-PHY (2251), and may have a value of 1.7 to 1.95 V. The above power voltages may be supplied to each component of the UFS device (2200) through a regulator (2260). The regulator (2260) may be implemented as a set of unit regulators each connected to different of the aforementioned power voltages.

[0140] FIGS. 13a to 13c are drawings for explaining the form factor of a UFS card. When the UFS device (2200) described with reference to FIG. 11 is implemented in the form of a UFS card (4000), the external appearance of the UFS card (4000) may follow that shown in FIGS. 13a to 13c.

[0141] FIG. 13a illustrates an exemplary top view of a UFS card (4000). Referring to FIG. 13a, it can be seen that the UFS card (4000) follows a shark-shaped design overall. In relation to FIG. 13a, the UFS card (4000) may have dimension values ​​as exemplarily described in Table 1 below.

[0142] item Dimensions (mm) T1 9.70 T2 15.00 T3 11.00 T4 9.70 T5 5.15 T6 0.25 T7 0.60 T8 0.75 T9 R0.80

[0143] FIG. 13b illustrates an exemplary side view of a UFS card (4000). In relation to FIG. 13b, the UFS card (4000) may have dimension values ​​as described in Table 2 below, for example.

[0144] item Dimensions (mm) S1 0.74±0.06 S2 0.30 S3 0.52 S4 1.20 S5 1.05 S6 1.00

[0145] FIG. 13c illustrates an exemplary bottom view of a UFS card (4000). Referring to FIG. 13c, a plurality of pins for electrical contact with a UFS slot may be formed on the bottom surface of the UFS card (4000), and the function of each pin will be described later. Based on the symmetry between the top surface and the bottom surface of the UFS card (4000), some of the information regarding dimensions described with reference to FIG. 13a and Table 1 (e.g., T1 to T5 and T9) may also be applied to the bottom view of the UFS card (4000) as illustrated in FIG. 13c.

[0146] A plurality of pins may be formed on the bottom surface of the UFS card (4000) for electrical connection with the UFS host, and according to FIG. 13c, the total number of pins may be 12. Each pin may have a rectangular shape, and the signal name corresponding to the pin is as shown in FIG. 13c. For general information regarding each pin, refer to Table 3 below, and also refer to the description above in relation to FIG. 12.

[0148] number Shin Ho-myeong explanation Dimensions (mm) 1 VSS Ground (GND) 3.00 × 0.72±0.05 2 DIN_C Differential input signal input from the host to the UFS card (4000) (DIN_C is the negative node, DIN_T is the positive node) 1.50 × 0.72±0.05 3 DIN_T 4 VSS Same as number 1 3.00 × 0.72±0.05 5 DOUT_C Differential output signal output from UFS card (4000) to host (DOUT_C ​​is negative node, DOUT_T is positive node) 1.50 × 0.72±0.05 6 DOUT_T 7 VSS Same as number 1 3.00 × 0.72±0.05 8 REF_CLK Reference clock provided from the host to the UFS card (4000) 1.50 × 0.72±0.05 9 VCCQ2 A power supply voltage having a relatively lower value compared to Vcc, primarily provided for PHY interfaces or controllers. 3.00 × 0.72±0.05 10 C / D(GND) Card Detection Signal 1.50 × 0.72±0.05 11 VSS Same as number 1 3.00 × 0.80±0.05 12 Vcc Main power supply voltage

[0149] FIG. 14 is a block diagram showing a non-volatile storage according to an embodiment of the present invention.

[0150] Referring to FIG. 14, the non-volatile storage (2220a) may include a memory device (2224) and a memory controller (2222). The non-volatile storage (2220a) may support a plurality of channels (CH1 to CHm), and the memory device (2224) and the memory controller (2222) may be connected through the plurality of channels (CH1 to CHm). For example, the non-volatile storage (2220a) may be implemented as a storage device such as a Solid State Drive (SSD).

[0151] The memory device (2224) may include a plurality of non-volatile memory devices (NVM11 to NVMmn). Each of the non-volatile memory devices (NVM11 to NVMmn) may be connected to one of a plurality of channels (CH1 to CHm) through a corresponding way. For example, the non-volatile memory devices (NVM11 to NVM1n) may be connected to a first channel (CH1) through ways (W11 to W1n), and the non-volatile memory devices (NVM21 to NVM2n) may be connected to a second channel (CH2) through ways (W21 to W2n). In an exemplary embodiment, each of the non-volatile memory devices (NVM11 to NVMmn) may be implemented as any memory unit capable of operating according to individual commands from the memory controller (2222). For example, each of the non-volatile memory devices (NVM11 to NVMmn) may be implemented as a chip or a die, but the present invention is not limited thereto.

[0152] The memory controller (2222) can transmit and receive signals to and from the memory device (2224) through multiple channels (CH1~CHm). For example, the memory controller (2222) can transmit commands (CMDa~CMDm), addresses (ADDRa~ADDRm), and data (DATAa~DATAm) to the memory device (2224) through the channels (CH1~CHm), or receive data (DATAa~DATAm) from the memory device (2224).

[0153] The memory controller (2222) can select one of the non-volatile memory devices connected to the corresponding channel through each channel and transmit and receive signals with the selected non-volatile memory device. For example, the memory controller (2222) can select a non-volatile memory device (NVM11) among the non-volatile memory devices (NVM11 to NVM1n) connected to the first channel (CH1). The memory controller (2222) can transmit a command (CMDa), an address (ADDRa), and data (DATAa) to the selected non-volatile memory device (NVM11) through the first channel (CH1), or receive data (DATAa) from the selected non-volatile memory device (NVM11).

[0154] The memory controller (2222) can transmit and receive signals to and from the memory device (2224) in parallel through different channels. For example, the memory controller (2222) can transmit a command (CMDb) to the memory device (2224) through a second channel (CH2) while transmitting a command (CMDa) to the memory device (2224) through a first channel (CH1). For example, the memory controller (2222) can receive data (DATAb) from the memory device (2224) through a second channel (CH2) while receiving data (DATAa) from the memory device (2224) through a first channel (CH1).

[0155] The memory controller (2222) can control the overall operation of the memory device (2224). The memory controller (2222) can control each of the non-volatile memory devices (NVM11–NVMmn) connected to the channels (CH1–CHm) by transmitting signals to the channels (CH1–CHm). For example, the memory controller (2222) can control one of the selected non-volatile memory devices (NVM11–NVM1n) by transmitting a command (CMDa) and an address (ADDRa) to the first channel (CH1).

[0156] Each of the non-volatile memory devices (NVM11 to NVMmn) can operate under the control of the memory controller (2222). For example, the non-volatile memory device (NVM11) can program data (DATAa) according to a command (CMDa), an address (ADDRa), and data (DATAa) provided through the first channel (CH1). For example, the non-volatile memory device (NVM21) can read data (DATAb) according to a command (CMDb) and an address (ADDRb) provided through the second channel (CH2), and transmit the read data (DATAb) to the memory controller (2222).

[0157] FIG. 14 illustrates that a memory device (2224) communicates with a memory controller (2222) through m channels, and that the memory device (2224) includes n non-volatile memory devices corresponding to each channel, but the number of channels and the number of non-volatile memory devices connected to one channel can be varied.

[0158] FIG. 15 is a block diagram illustrating a non-volatile storage according to an embodiment of the present invention. Referring to FIG. 15, the non-volatile storage (2220b) may include a memory device (2226) and a memory controller (2222). The memory device (2226) may correspond to one of the non-volatile memory devices (NVM11 to NVMmn) that communicate with the memory controller (2222) based on one of the plurality of channels (CH1 to CHm) of FIG. 14. The memory controller (2222) may correspond to the memory controller (2222) of FIG. 14.

[0159] The memory device (2226) may include first to eighth pins (P11 to P18), a memory interface circuit (2310), a control logic circuit (2320), and a memory cell array (2330).

[0160] The memory interface circuit (2310) can receive a chip enable signal (nCE) from the memory controller (2222) through the first pin (P11). The memory interface circuit (2310) can transmit and receive signals with the memory controller (2222) through the second to eighth pins (P12 to P18) according to the chip enable signal (nCE). For example, when the chip enable signal (nCE) is in an enable state (e.g., low level), the memory interface circuit (2310) can transmit and receive signals with the memory controller (2222) through the second to eighth pins (P12 to P18).

[0161] The memory interface circuit (2310) can receive a command latch enable signal (CLE), an address latch enable signal (ALE), and a write enable signal (nWE) from the memory controller (2222) through the second to fourth pins (P12 to P14). The memory interface circuit (2310) can receive a data signal (DQ) from the memory controller (2222) or transmit a data signal (DQ) to the memory controller (2222) through the seventh pin (P17). A command (CMD), an address (ADDR), and data (DATA) can be transmitted through the data signal (DQ). For example, the data signal (DQ) can be transmitted through a plurality of data signal lines. In this case, the seventh pin (P17) may include a plurality of pins corresponding to the plurality of data signals.

[0162] The memory interface circuit (2310) can obtain a command (CMD) from a data signal (DQ) received during the enable period (e.g., high level state) of a command latch enable signal (CLE) based on the toggle timings of a write enable signal (nWE). The memory interface circuit (2310) can obtain an address (ADDR) from a data signal (DQ) received during the enable period (e.g., high level state) of an address latch enable signal (ALE) based on the toggle timings of a write enable signal (nWE).

[0163] In an exemplary embodiment, the write enable signal (nWE) may maintain a static state (e.g., high level or low level) and then toggle between the high level and the low level. For example, the write enable signal (nWE) may toggle during the interval in which a command (CMD) or an address (ADDR) is transmitted. Accordingly, the memory interface circuit (2310) may obtain a command (CMD) or an address (ADDR) based on the toggle timings of the write enable signal (nWE).

[0164] The memory interface circuit (2310) can receive a read enable signal (nRE) from the memory controller (2222) through the fifth pin (P15). The memory interface circuit (2310) can receive a data strobe signal (DQS) from the memory controller (2222) through the sixth pin (P16) or transmit a data strobe signal (DQS) to the memory controller (2222).

[0165] In the data (DATA) output operation of the memory device (2226), the memory interface circuit (2310) may receive a read enable signal (nRE) that toggles through the fifth pin (P15) before outputting the data (DATA). The memory interface circuit (2310) may generate a data strobe signal (DQS) that toggles based on the toggling of the read enable signal (nRE). For example, the memory interface circuit (2310) may generate a data strobe signal (DQS) that begins to toggle after a predetermined delay (e.g., tDQSRE) based on the toggling start time of the read enable signal (nRE). The memory interface circuit (2310) may transmit a data signal (DQ) containing data (DATA) based on the toggling timing of the data strobe signal (DQS). Accordingly, the data (DATA) can be aligned with the toggle timing of the data strobe signal (DQS) and transmitted to the memory controller (2222).

[0166] In the data (DATA) input operation of the memory device (2226), when a data signal (DQ) containing data (DATA) is received from the memory controller (2222), the memory interface circuit (2310) may receive a data strobe signal (DQS) that toggles along with the data (DATA) from the memory controller (2222). The memory interface circuit (2310) may acquire data (DATA) from the data signal (DQ) based on the toggle timing of the data strobe signal (DQS). For example, the memory interface circuit (2310) may acquire data (DATA) by sampling the data signal (DQ) at the rising edge and falling edge of the data strobe signal (DQS).

[0167] The memory interface circuit (2310) can transmit a ready / busy output signal (nR / B) to the memory controller (2222) through the eighth pin (P18). The memory interface circuit (2310) can transmit status information of the memory device (2226) to the memory controller (2222) through the ready / busy output signal (nR / B). When the memory device (2226) is in a busy state (i.e., when internal operations of the memory device (2226) are being performed), the memory interface circuit (2310) can transmit a ready / busy output signal (nR / B) indicating the busy state to the memory controller (2222). When the memory device (2226) is in a ready state (i.e., when internal operations of the memory device (2226) are not performed or are completed), the memory interface circuit (2310) may transmit a ready / busy output signal (nR / B) indicating the ready state to the memory controller (2222). For example, while the memory device (2226) reads data (DATA) from the memory cell array (2330) in response to a page read command, the memory interface circuit (2310) may transmit a ready / busy output signal (nR / B) indicating a busy state (e.g., low level) to the memory controller (2222). For example, while the memory device (2226) programs data (DATA) into the memory cell array (2330) in response to a program command, the memory interface circuit (2310) may transmit a ready / busy output signal (nR / B) indicating a busy state to the memory controller (2222).

[0168] The control logic circuit (2320) can control various operations of the memory device (2226) overall. The control logic circuit (2320) can receive a command / address (CMD / ADDR) obtained from the memory interface circuit (2310). The control logic circuit (2320) can generate control signals to control other components of the memory device (2226) according to the received command / address (CMD / ADDR). For example, the control logic circuit (2320) can generate various control signals to program data (DATA) into the memory cell array (2330) or to read data (DATA) from the memory cell array (2330).

[0169] The memory cell array (2330) can store data (DATA) obtained from the memory interface circuit (2310) under the control of the control logic circuit (2320). The memory cell array (2330) can output the stored data (DATA) to the memory interface circuit (2310) under the control of the control logic circuit (2320).

[0170] The memory cell array (2330) may include a plurality of memory cells. For example, the plurality of memory cells may be flash memory cells. However, the present invention is not limited thereto, and the memory cells may be RRAM (Resistive Random Access Memory) cells, FRAM (Ferroelectric Random Access Memory) cells, PRAM (Phase Change Random Access Memory) cells, TRAM (Thyristor Random Access Memory) cells, or MRAM (Magnetic Random Access Memory) cells. Hereinafter, embodiments of the present invention will be described with a focus on embodiments in which the memory cells are NAND flash memory cells.

[0171] The memory controller (2222) may include first to eighth pins (P21 to P28) and a controller interface circuit (2410). The first to eighth pins (P21 to P28) may correspond to the first to eighth pins (P11 to P18) of the memory device (2226).

[0172] The controller interface circuit (2410) can transmit a chip enable signal (nCE) to a memory device (2226) through the first pin (P21). The controller interface circuit (2410) can transmit and receive signals to and from the selected memory device (2226) through the second to eighth pins (P22~P28) via the chip enable signal (nCE).

[0173] The controller interface circuit (2410) can transmit a command latch enable signal (CLE), an address latch enable signal (ALE), and a write enable signal (nWE) to the memory device (2226) through the second to fourth pins (P22 to P24). The controller interface circuit (2410) can transmit a data signal (DQ) to the memory device (2226) or receive a data signal (DQ) from the memory device (2226) through the seventh pin (P27).

[0174] The controller interface circuit (2410) can transmit a data signal (DQ) containing a command (CMD) or an address (ADDR) to the memory device (2226) along with a toggling write enable signal (nWE). The controller interface circuit (2410) can transmit a data signal (DQ) containing a command (CMD) to the memory device (2226) by transmitting a command latch enable signal (CLE) having an enable state, and can transmit a data signal (DQ) containing an address (ADDR) to the memory device (2226) by transmitting an address latch enable signal (ALE) having an enable state.

[0175] The controller interface circuit (2410) can transmit a read enable signal (nRE) to the memory device (2226) through the fifth pin (P25). The controller interface circuit (2410) can receive a data strobe signal (DQS) from the memory device (2226) or transmit a data strobe signal (DQS) to the memory device (2226) through the sixth pin (P26).

[0176] In the data (DATA) output operation of the memory device (2226), the controller interface circuit (2410) can generate a toggling read enable signal (nRE) and transmit the read enable signal (nRE) to the memory device (2226). For example, the controller interface circuit (2410) can generate a read enable signal (nRE) that changes from a fixed state (e.g., high level or low level) to a toggling state before the data (DATA) is output. Accordingly, a toggling data strobe signal (DQS) can be generated in the memory device (2226) based on the read enable signal (nRE). The controller interface circuit (2410) can receive a data signal (DQ) containing data (DATA) along with the toggling data strobe signal (DQS) from the memory device (2226). The controller interface circuit (2410) can acquire data (DATA) from the data signal (DQ) based on the toggle timing of the data strobe signal (DQS).

[0177] In the data (DATA) input operation of the memory device (2226), the controller interface circuit (2410) can generate a toggling data strobe signal (DQS). For example, the controller interface circuit (2410) can generate a data strobe signal (DQS) that changes from a fixed state (e.g., high level or low level) to a toggling state before transmitting the data (DATA). Based on the toggling timings of the data strobe signal (DQS), the controller interface circuit (2410) can transmit a data signal (DQ) containing the data (DATA) to the memory device (2226).

[0178] The controller interface circuit (2410) can receive a ready / busy output signal (nR / B) from the memory device (2226) through the eighth pin (P28). The controller interface circuit (2410) can determine the status information of the memory device (2226) based on the ready / busy output signal (nR / B).

[0179] FIG. 16 is an exemplary block diagram illustrating the memory device of FIG. 15. Referring to FIG. 16, the memory device (2226) may include a control logic circuit (2320), a memory cell array (2330), a page buffer section (2340), a voltage generator (2350), and a row decoder (3394). Although not shown in FIG. 16, the memory device (2226) may further include a memory interface circuit (2310) shown in FIG. 16, and may also further include column logic, a pre-decoder, a temperature sensor, a command decoder, an address decoder, etc.

[0180] The control logic circuit (2320) can control various operations within the memory device (2226) overall. The control logic circuit (2320) can output various control signals in response to a command (CMD) and / or an address (ADDR) from the memory interface circuit (2310). For example, the control logic circuit (2320) can output a voltage control signal (CTRL_vol), a row address (X-ADDR), and a column address (Y-ADDR).

[0181] The memory cell array (2330) may include a plurality of memory blocks (BLK1 to BLKz) (z is a positive integer), and each of the plurality of memory blocks (BLK1 to BLKz) may include a plurality of memory cells. The memory cell array (2330) may be connected to a page buffer (2340) via bit lines (BL) and may be connected to a row decoder (3394) via word lines (WL), string select lines (SSL), and ground select lines (GSL).

[0182] In an exemplary embodiment, the memory cell array (2330) may include a three-dimensional memory cell array, and the three-dimensional memory cell array may include a plurality of NAND strings. Each NAND string may include memory cells connected to word lines stacked vertically on a substrate. U.S. Patent Publication No. 7,679,133, U.S. Patent Publication No. 8,553,466, U.S. Patent Publication No. 8,654,587, U.S. Patent Publication No. 8,559,235, and U.S. Patent Application Publication No. 2011 / 0233648 are incorporated herein by reference. In an exemplary embodiment, the memory cell array (2330) may include a two-dimensional memory cell array, and the two-dimensional memory cell array may include a plurality of NAND strings arranged along row and column directions.

[0183] The page buffer unit (2340) may include a plurality of page buffers (PB1 to PBn) (where n is an integer greater than or equal to 3), and the plurality of page buffers (PB1 to PBn) may each be connected to memory cells through a plurality of bit lines (BL). The page buffer unit (2340) may select at least one bit line among the bit lines (BL) in response to a column address (Y-ADDR). The page buffer unit (2340) may operate as a write driver or a sense amplifier depending on the operation mode. For example, during a program operation, the page buffer unit (2340) may apply a bit line voltage corresponding to the data to be programmed with the selected bit line. During a read operation, the page buffer unit (2340) may detect the current or voltage of the selected bit line to detect the data stored in the memory cell.

[0184] The voltage generator (2350) can generate various types of voltages to perform program, readout, and erase operations based on the voltage control signal (CTRL_vol). For example, the voltage generator (2350) can generate a program voltage, a readout voltage, a program verification voltage, an erase voltage, etc. as a word line voltage (VWL).

[0185] The row decoder (3394) can select one of a plurality of word lines (WL) and one of a plurality of string select lines (SSL) in response to a row address (X-ADDR). For example, during a program operation, the row decoder (3394) can apply a program voltage and a program verification voltage to the selected word line, and during a read operation, it can apply a read voltage to the selected word line.

[0186] FIG. 17 is a diagram illustrating a 3D V-NAND structure that can be applied to a UFS device according to an embodiment of the present invention. When the storage module of the UFS device is implemented as a 3D V-NAND type flash memory, each of the plurality of memory blocks constituting the storage module can be represented by an equivalent circuit as shown in FIG. 17.

[0187] The memory block (BLKi) illustrated in FIG. 17 represents a three-dimensional memory block formed in a three-dimensional structure on a substrate. For example, a plurality of memory NAND strings included in the memory block (BLKi) may be formed in a direction perpendicular to the substrate.

[0188] Referring to FIG. 17, a memory block (BLKi) may include a plurality of memory NAND strings (NS11 to NS33) connected between bit lines (BL1, BL2, BL3) and a common source line (CSL). Each of the plurality of memory NAND strings (NS11 to NS33) may include a string select transistor (SST), a plurality of memory cells (MC1, MC2, ..., MC8), and a ground select transistor (GST). FIG. 17 illustrates that each of the plurality of memory NAND strings (NS11 to NS33) includes eight memory cells (MC1, MC2, ..., MC8), but is not necessarily limited thereto.

[0189] A string select transistor (SST) can be connected to corresponding string select lines (SSL1, SSL2, SSL3). Multiple memory cells (MC1, MC2, ..., MC8) can each be connected to corresponding gate lines (GTL1, GTL2, ..., GTL8). The gate lines (GTL1, GTL2, ..., GTL8) may correspond to word lines, and some of the gate lines (GTL1, GTL2, ..., GTL8) may correspond to dummy word lines. A ground select transistor (GST) can be connected to corresponding ground select lines (GSL1, GSL2, GSL3). A string select transistor (SST) is connected to corresponding bit lines (BL1, BL2, BL3), and a ground select transistor (GST) can be connected to a common source line (CSL).

[0190] Word lines of the same height (e.g., WL1) are connected in common, and ground select lines (GSL1, GSL2, GSL3) and string select lines (SSL1, SSL2, SSL3) can be separated. FIG. 17 shows a memory block (BLK) connected to eight gate lines (GTL1, GTL2, ..., GTL8) and three bit lines (BL1, BL2, BL3), but is not necessarily limited thereto.

[0191] FIG. 18 is a diagram illustrating a BVNAND structure that can be applied to a UFS device according to an embodiment of the present invention. Referring to FIG. 18, the memory device (2226) may have a C2C (chip to chip) structure. A C2C structure may mean fabricating an upper chip including a cell region (CELL) on a first wafer, fabricating a lower chip including a peripheral circuit region (PERI) on a second wafer different from the first wafer, and then connecting the upper chip and the lower chip to each other by a bonding method. For example, the bonding method may mean a method of electrically connecting a bonding metal formed on the uppermost metal layer of the upper chip and a bonding metal formed on the uppermost metal layer of the lower chip to each other. For instance, if the bonding metal is formed of copper (Cu), the bonding method may be a Cu-Cu bonding method, and the bonding metal may also be formed of aluminum or tungsten.

[0192] Each of the peripheral circuit region (PERI) and cell region (CELL) of the memory device (2226) may include an external pad bonding region (PA), a wordline bonding region (WLBA), and a bitline bonding region (BLBA).

[0193] The peripheral circuit region (PERI) may include a first substrate (3210), an interlayer insulating layer (3215), a plurality of circuit elements (3220a, 3220b, 3220c) formed on the first substrate (3210), a first metal layer (3230a, 3230b, 3230c) connected to each of the plurality of circuit elements (3220a, 3220b, 3220c), and a second metal layer (3240a, 3240b, 3240c) formed on the first metal layer (3230a, 3230b, 3230c). In one embodiment, the first metal layer (3230a, 3230b, 3230c) may be formed of tungsten, which has relatively high resistance, and the second metal layer (3240a, 3240b, 3240c) may be formed of copper, which has relatively low resistance.

[0194] In this specification, only the first metal layer (3230a, 3230b, 3230c) and the second metal layer (3240a, 3240b, 3240c) are illustrated and described, but are not limited thereto, and at least one additional metal layer may be formed on the second metal layer (3240a, 3240b, 3240c). At least some of the one or more metal layers formed on the upper part of the second metal layer (3240a, 3240b, 3240c) may be formed of aluminum or the like, having a lower resistance than the copper forming the second metal layer (3240a, 3240b, 3240c).

[0195] The interlayer insulating layer (3215) is disposed on a first substrate (3210) to cover a plurality of circuit elements (3220a, 3220b, 3220c), a first metal layer (3230a, 3230b, 3230c), and a second metal layer (3240a, 3240b, 3240c), and may include an insulating material such as silicon oxide, silicon nitride, etc.

[0196] A lower bonding metal (3271b, 3272b) may be formed on the second metal layer (3240b) of the wordline bonding region (WLBA). In the wordline bonding region (WLBA), the lower bonding metal (3271b, 3272b) of the peripheral circuit region (PERI) may be electrically connected to the upper bonding metal (3371b, 3372b) of the cell region (CELL) by a bonding method, and the lower bonding metal (3271b, 3272b) and the upper bonding metal (3371b, 3372b) may be formed of aluminum, copper, or tungsten, etc.

[0197] A cell region (CELL) may provide at least one memory block. The cell region (CELL) may include a second substrate (3310) and a common source line (3320). On the second substrate (3310), a plurality of word lines (3331-338; 330) may be stacked along a direction perpendicular to the upper surface of the second substrate (3310) (Z-axis direction). String selection lines and ground selection lines may be disposed on the upper and lower sides of each of the word lines (3330), and a plurality of word lines (3330) may be disposed between the string selection lines and the ground selection lines.

[0198] In the bitline bonding region (BLBA), the channel structure (CH) may extend in a direction perpendicular to the upper surface of the second substrate (3310) and penetrate word lines (3330), string select lines, and ground select lines. The channel structure (CH) may include a data storage layer, a channel layer, and a buried insulating layer, and the channel layer may be electrically connected to the first metal layer (3350c) and the second metal layer (3360c). For example, the first metal layer (3350c) may be a bitline contact, and the second metal layer (3360c) may be a bitline. In one embodiment, the bitline (3360c) may extend along a first direction (Y-axis direction) parallel to the upper surface of the second substrate (3310).

[0199] In one embodiment illustrated in FIG. 18, the area where the channel structure (CH) and the bit line (3360c) are placed may be defined as a bit line bonding area (BLBA). The bit line (3360c) may be electrically connected to circuit elements (3220c) that provide a page buffer (3393) in the peripheral circuit area (PERI) in the bit line bonding area (BLBA). For example, the bit line (3360c) may be connected to an upper bonding metal (3371c, 3372c) in the peripheral circuit area (PERI), and the upper bonding metal (3371c, 3372c) may be connected to a lower bonding metal (3271c, 3272c) that is connected to the circuit elements (3220c) of the page buffer (3393).

[0200] In the wordline bonding area (WLBA), wordlines (3330) may extend along a second direction (X-axis direction) parallel to the upper surface of the second substrate (3310) and may be connected to a plurality of cell contact plugs (3341-347; 340). The wordlines (3330) and the cell contact plugs (3340) may be connected to each other at pads provided by extending at least some of the wordlines (3330) along the second direction at different lengths. A first metal layer (3350b) and a second metal layer (3360b) may be connected in sequence to the upper portion of the cell contact plugs (3340) connected to the wordlines (3330). The cell contact plugs (3340) can be connected to the peripheral circuit area (PERI) through the upper bonding metal (3371b, 3372b) of the cell area (CELL) and the lower bonding metal (3271b, 3272b) of the peripheral circuit area (PERI) in the wordline bonding area (WLBA).

[0201] Cell contact plugs (3340) may be electrically connected to circuit elements (3220b) that provide a row decoder (3394) in the peripheral circuit region (PERI). In one embodiment, the operating voltage of the circuit elements (3220b) that provide the row decoder (3394) may be different from the operating voltage of the circuit elements (3220c) that provide the page buffer (3393). For example, the operating voltage of the circuit elements (3220c) that provide the page buffer (3393) may be greater than the operating voltage of the circuit elements (3220b) that provide the row decoder (3394).

[0202] A common source line contact plug (3380) may be disposed in the external pad bonding area (PA). The common source line contact plug (3380) is formed of a conductive material such as a metal, a metal compound, or polysilicon and may be electrically connected to a common source line (3320). A first metal layer (3350a) and a second metal layer (3360a) may be sequentially laminated on top of the common source line contact plug (3380). For example, the area where the common source line contact plug (3380), the first metal layer (3350a), and the second metal layer (3360a) are disposed may be defined as the external pad bonding area (PA).

[0203] Meanwhile, input / output pads (3205, 3305) may be disposed in the external pad bonding area (PA). Referring to FIG. 18, a lower insulating film (3201) covering the lower surface of the first substrate (3210) may be formed on the lower surface of the first substrate (3210), and a first input / output pad (3205) may be formed on the lower insulating film (3201). The first input / output pad (3205) is connected to at least one of a plurality of circuit elements (3220a, 3220b, 3220c) disposed in the peripheral circuit area (PERI) through the first input / output contact plug (3203), and may be separated from the first substrate (3210) by the lower insulating film (3201). Additionally, a side insulating film is disposed between the first input / output contact plug (3203) and the first substrate (3210) to electrically separate the first input / output contact plug (3203) and the first substrate (3210).

[0204] Referring to FIG. 18, an upper insulating film (3301) covering the upper surface of the second substrate (3310) may be formed on the upper surface of the second substrate (3310), and a second input / output pad (3305) may be disposed on the upper insulating film (3301). The second input / output pad (3305) may be connected to at least one of a plurality of circuit elements (3220a, 3220b, 3220c) disposed in the peripheral circuit region (PERI) through a second input / output contact plug (3303).

[0205] According to the embodiments, the second substrate (3310) and common source line (3320), etc., may not be placed in the area where the second input / output contact plug (3303) is placed. Additionally, the second input / output pad (3305) may not overlap with the word lines (3330) in the third direction (Z-axis direction). Referring to FIG. 18, the second input / output contact plug (3303) is separated from the second substrate (3310) in a direction parallel to the upper surface of the second substrate (3310) and may be connected to the second input / output pad (3305) by penetrating the interlayer insulating layer (3315) of the cell area (CELL).

[0206] According to embodiments, the first input / output pad (3205) and the second input / output pad (3305) may be formed optionally. For example, the memory device (2226) may include only the first input / output pad (3205) disposed on the upper part of the first substrate (3210), or only the second input / output pad (3305) disposed on the upper part of the second substrate (3310). Alternatively, the memory device (2226) may include both the first input / output pad (3205) and the second input / output pad (3305).

[0207] In each of the external pad bonding region (PA) and bitline bonding region (BLBA) included in the cell region (CELL) and peripheral circuit region (PERI), the metal pattern of the top metal layer may exist as a dummy pattern, or the top metal layer may be empty.

[0208] The memory device (2226) may form a lower metal pattern (3273a) of the same shape as the upper metal pattern (3372a) of the cell region (CELL) on the upper metal layer of the peripheral circuit region (PERI) in the external pad bonding region (PA), corresponding to the upper metal pattern (3372a) formed on the upper metal layer of the cell region (CELL). The lower metal pattern (3273a) formed on the upper metal layer of the peripheral circuit region (PERI) may not be connected to a separate contact in the peripheral circuit region (PERI). Similarly, the memory device may form an upper metal pattern of the same shape as the lower metal pattern of the peripheral circuit region (PERI) on the upper metal layer of the cell region (CELL) in the external pad bonding region (PA), corresponding to the lower metal pattern formed on the upper metal layer of the peripheral circuit region (PERI).

[0209] A lower bonding metal (3271b, 3272b) may be formed on the second metal layer (3240b) of the wordline bonding region (WLBA). In the wordline bonding region (WLBA), the lower bonding metal (3271b, 3272b) of the peripheral circuit region (PERI) may be electrically connected to the upper bonding metal (3371b, 3372b) of the cell region (CELL) by a bonding method.

[0210] Additionally, in the bitline bonding area (BLBA), an upper metal pattern (3392) of the same shape as the lower metal pattern (3252) of the peripheral circuit area (PERI) can be formed on the upper metal layer of the cell area (CELL) in correspondence with the lower metal pattern (3252) formed on the upper metal layer of the peripheral circuit area (PERI). A contact may not be formed on the upper metal pattern (3392) formed on the upper metal layer of the cell area (CELL).

[0211] As described above, exemplary embodiments have been disclosed in the drawings and specification. Although specific terms have been used to describe the embodiments in this specification, they are used only for the purpose of explaining the technical concept of this disclosure and are not intended to limit the meaning or the scope of this disclosure as defined in the claims. Therefore, those skilled in the art will understand that various modifications and equivalent alternative embodiments are possible therefrom. Accordingly, the true technical scope of protection of this disclosure should be determined by the technical concept of the appended claims.

Claims

Claim 1 A method for writing data to a protected area of ​​a storage device in response to a request from a host, comprising: the storage device receiving a first write request from the host, the first write request including a first host message authentication code and a first random number; the storage device verifying the first write request based on a write counter stored in the storage device, the first random number, and the first host message authentication code; the storage device updating the write counter based on the result of verifying the first write request; the storage device generating a first device message authentication code based on the updated write counter and the first random number; and the storage device providing a first response to the host, the first response including the first device message authentication code and the verification result. Claim 2 A method according to claim 1, wherein the step of updating the write counter comprises: a step of increasing the write counter of the storage device upon successful verification of the first write request; and a step of maintaining the write counter of the storage device upon failure of verification of the first write request. Claim 3 A method according to claim 1, wherein the storage device receives a second write request from the host, the second write request comprising a second host message authentication code, a second write counter, and a second random number; and the storage device further comprises the step of verifying the second write request based on the updated write counter, the second random number, and the second host message authentication code. Claim 4 A method according to claim 3, wherein the storage device generates a second device message authentication code based on the updated write counter and the second random number; and the storage device provides a second response to the host including the second device message authentication code and the verification result of the second write request. Claim 5 A method according to claim 1, wherein the first response further comprises the first random number. Claim 6 A method according to claim 1, wherein the step of verifying the first write request comprises: the storage device generating a first host message verification code based on the write counter and the first random number; and the storage device comparing the first host message verification code and the first host message authentication code. Claim 7 A method according to claim 6, wherein the first entry request includes a first entry counter, and the step of verifying the first entry request further includes the step of the storage device comparing the entry counter and the first entry counter. Claim 8 A method according to claim 6, wherein the step of generating the first host message verification code is based on a key previously shared with the host, the write counter, and the first random number, and the step of generating the first device message authentication code is based on the key, the updated write counter, and the first random number. Claim 9 A storage device configured to communicate with a host, comprising: a memory including a protected area; and a controller configured to receive a first write request from the host, the first write request including a first host message authentication code, a first write counter, and a first random number, verify the first write request based on the write counter, the first random number, and the first host message authentication code stored in the storage device, and write data included in the first write request to the protected area upon successful verification of the first write request. Claim 10 A storage device according to claim 9, wherein the controller is configured to update the write counter based on the verification result of the first write request, generate a first device message authentication code based on the updated write counter and the first random number, and provide a first response including the first device message authentication code and the verification result to the host. Claim 11 A storage device according to claim 10, wherein the first response further comprises the first random number. Claim 12 A storage device according to claim 9, wherein the controller is configured to generate a first host message verification code based on the write counter and the first random number, and to verify the first write request by comparing the first host message verification code and the first host message authentication code. Claim 13 A method for a host to write data to a storage device including a protected area, the method comprising: the host generating a first host message authentication code based on a write counter managed by the host and a first random number; the host providing a first write request to the storage device including the first host message authentication code and the first random number; the host receiving a first response from the storage device including the first device message authentication code; the host verifying the first response based on an incremented value from the write counter, the first random number, and the first device message authentication code; and the host updating the write counter based on the result of verifying the first response. Claim 14 A method according to claim 13, wherein the step of updating the entry counter comprises: the step of the host increasing the entry counter upon successful verification of the first response; and the step of the host maintaining the entry counter upon failure of verification of the first response. Claim 15 A method according to claim 13, further comprising: the host generating a second random number; the host generating a second host message authentication code based on the updated write counter and the second random number; and the host providing a second write request including the second host message authentication code and the second random number to the storage device. Claim 16 A method according to claim 15, further comprising: the step of the host receiving a second response from the storage device including a second device message authentication code; and the step of the host verifying the second response based on an incremented value from the updated write counter, the second random number, and the second device message authentication code. Claim 17 A method according to claim 13, wherein the step of verifying the first response comprises: the host generating a first device message verification code based on the value incremented from the write counter and the first random number; and the host comparing the first device message verification code and the first device message authentication code. Claim 18 A method according to claim 17, wherein the step of the host verifying the first response further comprises the step of comparing the first random number and the third random number included in the first response. Claim 19 A method according to claim 17, wherein the step of generating the first host message authentication code is based on a key previously shared with the storage device, the write counter, and the first random number, and the step of generating the first device message verification code is based on the key, the value increased from the write counter, and the first random number. Claim 20 A method according to claim 13, further comprising the steps of: the host providing a write counter read request to the storage device; and the host receiving a write counter read response including the write counter from the storage device.

Images