KR20090071348A - Flash memory device having secure file deletion function and method for securely deleting flash file - Google Patents

Abstract

A flash memory device having a secure file deletion function and a method for securely deleting a flash file are provided to store encoded data and a decoding key in a separate memory block and disable recovery of the encoded data through deletion of the decoding key, thereby guaranteeing quick and secure deletion of a flash file. An end node having the same binary value as LSB(Least Significant Bits) of file ID of a flash file which is a deletion target is searched(S120). A header block indicating the end node is copied to a DRAM(Dynamic Random Access Memory). An object header having the file ID of a deletion target file is set invalid(S140). Effective object headers are stored in the header block(S150). The copied header block is deleted from the DRAM(S160).

Description

FLASH MEMORY DEVICE HAVING SECURE FILE DELETION FUNCTION AND METHOD FOR SECURELY DELETING FLASH FILE}

The present invention relates to a flash memory device and a flash file deleting method, and more particularly, to a flash memory device having a file safe deletion function and a flash file safe deletion method.

The present invention is derived from the research conducted as part of the IT growth engine technology development project of the Ministry of Information and Communication and the Ministry of Information and Communication Research and Development. [Task management number: 2006-S-039-02, Title: Development of embedded security operating system technology Secure Operating System Technology Development)].

In most file systems, the metadata for the file is deleted or changed by the file delete command, but the data of the file itself is not deleted but remains on the physical medium. Thus it is possible to recover erased files. However, some users do not want this recovery. This demand is growing in embedded systems that use flash memory as a storage medium.

A method of securely deleting data from a magnetic recording medium is known. This method uses overwriting to overwrite other bit patterns with data to delete the data. Specifically, this technique consists of overwriting data with 4 random bit patterns, then overwriting data with 27 predetermined patterns, and finally overwriting data with 4 random bit patterns. Therefore, a total of 35 overwrites are performed.

A method for safely deleting data from a magnetic disk has also been proposed. The DoD 5220 22-M method of the Department of Defense overwrites data with an arbitrary bit pattern, then overwrites the data with the complement of the arbitrary bit pattern, and then overwrites the data with an arbitrary bit pattern seven times. Repeat. Therefore, a total of 21 overwrites are performed.

In order to replace the data recorded in the flash memory with other data, the erase operation must be preceded. Data erase operations in the flash memory are performed in units of blocks and write operations are performed in units of pages. In general, a block consists of 32 pages of 512 bytes or 64 pages of 2048 bytes. Because of this discrepancy between write and delete units, log-structured file systems are commonly used in flash file systems.

When a file is modified in the log-based file system, the file before the modification is not deleted but only invalid, and then the contents of the file are recorded in a new page. In addition, in the log-based structure file system, secure deletion is realized by searching the entire file system and deleting invalidated pages together.

Even if data is deleted through the above-described multi-step process for the magnetic recording medium or the magnetic disk, magnetic afterimage remains in the erased data. Therefore, the original data can be extracted with a device that can detect traces of the weak magnetic field of the disk even if the corresponding data is deleted by overwriting the other bit patterns.

Further, the conventional data safe erasing method relates to a magnetic recording medium or a magnetic disk, and thus cannot be applied to a method of safely erasing data from a flash memory that is structurally different from the magnetic medium.

In addition, the conventional method of securely deleting files in a flash file system, that is, a log-based file system, is inefficient. This is because you must search the entire file system and delete the invalidated pages together for safe deletion.

It is an object of the present invention to provide a method and apparatus for quickly and securely deleting files without having to navigate the entire file system through encryption and object header block management of files.

The present invention provides a method for securely deleting files in a flash memory based file system. To this end, the inventors of the present invention designed a file system for a flash memory having a safe erase function by changing a YAFFS (YetFS) which is a file system most commonly used in an embedded system. However, the present invention is not limited to YAFFS and can be applied to other types of flash file systems.

The present invention is based on encryption and realizes secure deletion of a file by deleting a decryption key used to encrypt a particular file. In addition, the present invention separately stores an object header having metadata of a file including a decryption key and data which is the actual content of the file in a header block and a data block, respectively. Therefore, it is possible to find and delete only the object header to be deleted from the header block without having to search the entire file system for file deletion, which greatly reduces the processing time required for deletion. In addition, the present invention provides a binary tree technique that can quickly and easily find a file that requires safe deletion.

Specifically, in order to achieve the above object, the flash memory device of the present invention, a flash memory consisting of memory blocks for storing a flash file, and the data block of the memory block in the encrypted data of the flash file And a memory controller configured to control the flash memory to store an object header including a decryption key for decrypting the encrypted data in a header block of the memory blocks, wherein the memory controller stores the encrypted data. In response to the delete command of the flash file, the object header including the decryption key for decrypting the encrypted data is deleted from the header block.

In addition, in order to achieve the above object, according to the flash file safe erasing method of the present invention, the encrypted data of the flash file is stored in the data block of the flash memory, and the encrypted data is decrypted in the header block of the flash memory. Storing an object header including a decryption key to delete the object header including a decryption key for decrypting the encrypted data in response to a delete command of the flash file having encrypted data; Steps.

According to this configuration of the present invention, if the encrypted data and the decryption key are stored in separate memory blocks, and only the decryption key is deleted at the time of deletion, recovery of the encrypted data may be impossible, thereby safely deleting the flash file. Is achieved quickly and easily. In the case of flash memory, since the overhead for the delete operation is quite large, it is much more efficient to reduce the number of delete operations even if an encryption overhead occurs.

In this case, the deleting may include copying a header block in which the object header including the decryption key is stored, to the temporary storage device, deleting the header block from the flash memory, and in the copied header block, Invalidating an object header including a decryption key, reassigning the deleted header block to the flash memory, and valid object header among the object headers of the copied header block; Storing in a block.

In addition, it is preferable to store object headers of a flash file having the same file ID in the same header block. Therefore, you can delete the desired object headers in only one header block at a time without having to navigate the entire system, ensuring fast and safe flash file deletion. In a log-based file system, there can be multiple object headers in a file. Therefore, to delete a file, not only the valid object header but also all invalid object headers that have been invalidated must be found and deleted. According to the present invention, since the object headers for the same flash file are all gathered in one header block, fast file safe deletion is ensured.

In addition, in the flash memory device and the flash file safe erasing method of the present invention, a binary tree composed of nodes having a binary value associated with a file ID is used for a header block search. Therefore, fast header block search is guaranteed.

According to the present invention, if the encrypted data and the decryption key are stored in separate memory blocks, and only the decryption key is deleted at the time of deletion, recovery of the encrypted data can be impossible, thereby ensuring safe safe deletion of the flash file. .

In addition, according to the present invention, since the desired object header can be deleted at one time only in one header block without searching the entire system, the fast and safe deletion of the flash file is guaranteed.

In addition, according to the present invention, a fast header block search is ensured by utilizing a binary tree composed of nodes having a binary value associated with a file ID in the header block search.

Hereinafter, with reference to the accompanying drawings will be described an embodiment of the present invention.

1 illustrates a flash memory device 10 having a function of securely deleting a flash file according to an embodiment of the present invention. The flash memory device 10 includes a flash memory 20 and a memory controller 30. When the flash memory device 10 is a USB flash drive, the flash memory device 10 further includes a connector for exchanging files and control signals with an external device.

The flash memory 20 is composed of a plurality of memory blocks for storing a flash file, and may be, for example, but not limited to, a NAND gate flash memory. Each memory block may consist of 32 pages of 512 bytes in size.

The memory controller 30 controls the flash memory 20 so that the memory blocks are divided into data blocks and header blocks. The data block stores data which is the actual content of the flash file. The header block stores an object header having metadata including a file ID of a flash file, a location of a data block in which data of the file is stored, and the like.

In addition, the memory controller 30 encrypts the data of the flash file and stores it in the data block, and the decryption key for decrypting the encrypted data is included in the object header of the corresponding flash file and stored in the header block. When deleting a flash file, the flash file can be deleted quickly and safely by deleting only the decryption key of the flash file from the header block.

Hereinafter, an operation of the memory controller 30 that creates / changes a flash file and deletes the flash file will be described in detail.

1. Binary Tree for Header Block Search

2 shows a binary tree for header block search performed by the memory controller 30. The binary tree is maintained in internal memory, such as DRAM, and is used to search for a header block in which a newly created object header is to be stored, and to search for a header block in which an object header to be deleted is located.

The top layer of the binary tree has a NULL value. The left child node of the parent node has a zero on the left of its parent's binary value, and the right child node has a one on its left's binary value. According to such a rule, all nodes of the binary tree are formed, and the search for each node is conveniently performed. At this time, the positions of the child nodes may be interchanged.

The binary value indicated at each node of the binary tree is a pointer indicating a position in the flash memory 20 of the header block and corresponds to n Least Significant Bits (LSBs) of the file ID. The header block is located at the location indicated by the pointer of the end node in the flash memory 20.

For example, the end node '010' indicates a header block in which an object header corresponding to a file whose LSB of the file ID is '010' is stored. Therefore, when trying to store the newly created object header in the header block, n LSBs of the file ID must be equal to the binary value of the end node whose node depth is n. In other words, the object header corresponding to the file whose LSB of the file ID is '010' is stored in a header block indicated by an end node having a binary value of '010'.

However, when the storage space of the header block is insufficient, the block manager 11 generates child nodes '0010' and '1010' of the end node of '010', and the location in the flash memory 20 indicated by the generated child nodes. Create two new header blocks in. The object headers stored in the header block pointed to by node '010' and the newly created object header are stored in two new header blocks. The header block indicated by '010' is deleted.

Meanwhile, the header block indicated by the node '10' does not exist in the flash memory. As will be described later, the header blocks indicated by the node '10' are deleted while the child nodes '010' and '110' of the node '10' are generated.

By constructing a binary tree in this way, all object headers with the same file ID are stored in the same header block. Therefore, only one header block in which the object header associated with the flash file to be deleted needs to be found according to the binary tree rule, thereby ensuring fast searching and deleting.

In the following description, an end node having a binary value "X" is represented by "end node X", and a header block indicated by the end node X is represented by "header block X".

2. Header block allocation process according to file creation / modification

Referring to Fig. 3, the process of assigning the newly generated object header to the corresponding header block will be described. The memory controller 30 executes the following "OBJECT_HEADER_ADD arithmetic algorithm" in response to a newly generated flash file storage command to perform a header block allocation process. This algorithm occurs when a new file is created or an existing file is changed.

[OBJECT_HEADER_ADD arithmetic algorithm]

In the state where the binary tree is constructed as shown in FIG. 2, when the file having the file ID of "11010010" is to be generated, the algorithm is executed in the following order. The data of the file having the file ID "11010010" is encrypted, and the decryption key and the file ID are included in the object header of the file.

(1) Obtain the file ID "11010010" of the file to be created.

(2) Fig. 3 (a): The end node having a depth of n and having a binary value equal to n LSBs of a file ID is searched for. This search starts at the root node (null) and follows the nodes of the tree in the order of the LSB value of the file ID until the end node is found.

When the file ID is "11010010", the node '0' having a binary value matching '0' which is one LSB of the file ID among the nodes having a node depth of 1 is searched first. Since node '0' is not yet an end node, among the child nodes of node '0', node '10' having a binary value matching two LSBs of file ID '10' is searched for. Since the node '10' is not yet an end node, among the child nodes of the node '10', the node '010' having a binary value matching the three LSBs of the file ID '010' is searched for. Node '010' has no child nodes and thus becomes an end node for file ID "11010010".

(3) Check whether there is space for the new object header in header block 010 pointed to by end node 010 found in (2). If there is an empty space, the object header of the file having the file ID "11010010" is stored in the header block 010, and the operation ends.

(4) FIG. 3B: If there is no free space, the header block 010 is copied to the DRAM. The header block 010 copied to the DRAM is deleted from the flash memory 20.

(5) FIG. 3C: Count the number of valid object headers of the header block 010. FIG.

(6) As a result of the calculation in FIG. The end node 1010 is generated according to the above-described binary tree rule, and the header block 0010 and the header block 1010 are allocated to the flash memory 20 (Fig. 3 (c)).

(7) FIG. 3D: Valid object headers in the header block 010 and the object header of the file having the file ID "11010010" are divided into the header block 0010 and the header block 1010 according to their file ID (for example, half Save). That is, the object headers of the file whose LSB of the file ID is '0010' are stored in the header block 0010, and the object headers of the file having the LSB of the file ID '1010' are stored in the header block 1010. Therefore, the object header of the file having the file ID "11010010" is stored in the header block 0010.

(8) If the calculation result of (5) indicates that the number of valid object headers does not exceed half of the number of pages of the header block 010, the header block 010 deleted in (4) is allocated again in the flash memory 20, and the header block 010 Stores existing valid object headers and the object header of the file with file ID "11010010".

(9) The header block copied in (4) is deleted from the DRAM.

When changing the data of the file, first, the object header of the file stored in the header block is set to invalid. Subsequently, if there is empty space in the header block, the changed object header is allocated to the empty space of the header block by the process of (3), and if there is no empty space in the header block, the process of (5) to (8) Allocates a header block.

3. Header Block Allocation Process According to File Deletion

Referring to Fig. 4, the allocation process of the header block according to the deletion of the flash file will be described. The memory controller 30 executes the following "OBJECT_HEADER_DEL algorithm" in response to the delete command of the specific flash file stored in the flash memory 20.

When attempting to delete a file whose file ID is "11010010", which was generated by the "OBJECT_HEADER_ADD arithmetic algorithm", the "OBJECT_HEADER_DEL arithmetic algorithm" is executed in the following order. The data of the file with the file ID "11010010" is encrypted, and the decryption key is included in the object header of the file. In addition, it is assumed that the object header of the file ID "11010010" is stored in the header block 010.

(1) Obtain file ID "11010010" of the file to be safely deleted.

(2) Search for the end node whose node depth is n and has the same binary value as n LSBs of the file ID. This search starts at the root node (null) and follows the nodes of the tree in the order of the LSB value of the file ID until the end node is found. This search finds the header block 010.

(3) The header block 010 found in Fig. 4A is copied to DRAM. The header block 010 copied to the DRAM is deleted from the flash memory 20.

(4) FIG. 4B: Among the object headers stored in the header block 010 in the DRAM, the object header having the file ID "11010010" is set to INVALID.

(5) (c) of FIG. 4: The header block 010 deleted in (3) is allocated to the flash memory 20 again, and all valid object headers stored in the header block 010 in the DRAM are stored in the flash memory 20. Store in the reassigned header block 010.

(6) The header block 010 copied in (3) is deleted from the DRAM.

Since the object header containing the data decryption key of the file ID "11010010" is set invalid in (4) and deleted in (6), even if data of the file remains in the flash memory 20, the data Cannot be recovered.

5 is a flowchart of a method for securely deleting a flash file according to an exemplary embodiment of the present invention. As shown in FIG. 5A, data of a flash file is encrypted and stored in a data block of the flash memory 20, and the decryption key is included in an object header to store the header block of the flash memory 20. It is stored.

According to the flowchart of FIG. 5B, first, an ID of a flash file to be deleted is obtained (S110). Subsequently, an end node having a depth of n and having the same binary value as n LSBs of the file ID is searched for (S120). This search starts at the root node (null) and follows the nodes of the tree in the order of the LSB value of the file ID until the end node is found. The header block indicated by the end node found in step S120 is copied to the DRAM, and the header block copied to the DRAM is deleted from the flash memory 20 (S130). Among the object headers stored in the header block in the DRAM, an object header having a file ID of a file to be deleted is set to INVALID (S140). The header block deleted in step S130 is allocated to the flash memory 20 again, and all valid object headers stored in the header block in the DRAM are stored in the header block allocated again in the flash memory 20 (S150). The header block copied in step S130 is deleted from the DRAM (S160).

The graph of FIG. 6 shows an experimental result of a file safe deletion method according to an embodiment of the present invention and a file safe deletion method according to a conventional example.

In the embodiment of the present invention, the memory controller 30 divides and manages a memory block into a data block and a header block, stores encrypted data in the data block, and stores a decryption key necessary for decrypting the encrypted data in the header block. All object headers of a flash file with the same file ID are stored in the same header block. In response to the delete command for the flash file, the memory controller 30 deletes all object headers in the header block corresponding to the file. In the conventional example, in response to a delete command for a flash file, corresponding memory blocks scattered throughout the flash memory are found and deleted.

According to the experimental result of FIG. 6, in the file safe deletion method according to the conventional example, the number of deletions of the memory block increases in direct proportion to the frequency of modifying the flash file, whereas in the file safe deletion method according to the embodiment of the present invention, However, even if the frequency of modifying a file increases, the number of deletions of a memory block rarely increases. Therefore, the file safe erase method according to the embodiment of the present invention is very useful in a flash memory having a large overhead for the erase operation of the memory block.

Although the embodiments of the present invention described above have been specified by specific configurations and drawings, it is intended to be clear that such specific embodiments do not limit the scope of the present invention. Accordingly, it is to be understood that the invention includes various modifications and equivalents thereof without departing from the spirit of the invention.

For example, constructing a binary tree with respect to n Most Significant Bits (MSBs) of a file ID is also within the scope of the present invention. In this case, the left child node is assigned a binary value with zeros to the right of the parent node's binary value, and the right child node is assigned a binary value with ones to the right of the parent node's binary value. At this time, the left and right positions of the child nodes may be interchanged.

1 is a block diagram of a flash memory device according to an embodiment of the present invention.

2 is a structural diagram of a binary tree used for header block searching.

3A to 3D are conceptual views illustrating the allocation of header blocks when creating / modifying flash files.

4A to 4C are conceptual views for explaining allocation of header blocks when deleting a flash file.

5 is a flowchart of a method for securely deleting a flash file according to an embodiment of the present invention.

6 is a graph showing experimental results according to an embodiment of the present invention.

Claims (20)

A flash memory composed of memory blocks for storing a flash file, Controlling the flash memory to store encrypted data of a flash file in a data block of the memory blocks, and an object header including a decryption key for decrypting the encrypted data in a header block of the memory blocks. A memory controller, And the memory controller deletes an object header including a decryption key for decrypting the encrypted data from the header block in response to a delete command of the flash file having encrypted data. The memory controller of claim 1, wherein the memory controller copies the header block, in which the object header including the decryption key, is stored, to the temporary storage device, and deletes the header block from the flash memory. In the copied header block, set the object header including the decryption key to be invalid, reassign the deleted header block to the flash memory, and reassign the valid object header among the object headers of the copied header block. Memory device to store in the header block. The flash memory device of claim 1, wherein the memory controller stores object headers of a flash file having a same file ID in a same header block. The memory controller of claim 1, wherein the node of depth n has a binary value representing n LSBs of a file ID of a flash file, and the binary value of an end node constitutes a binary tree indicating a position of a header block in the flash memory. and, Further, the memory controller stores the object header of the flash file having the binary value of the terminal node as the LSB of the file ID in a header block indicated by the terminal node, and searches the binary tree in the depth direction to delete the object. A flash memory device that locates a header block containing an object header. The flash memory device of claim 4, wherein the memory controller configures the binary tree such that two child nodes have a binary value appended with 0 and 1 to the left of the binary value of the parent node, respectively. The memory controller of claim 1, wherein the node of depth n has a binary value representing n MSBs of a file ID of a flash file, and the binary value of an end node constitutes a binary tree indicating a position of a header block in the flash memory. and, Further, the memory controller stores the object header of the flash file having the binary value of the terminal node as the MSB of the file ID in a header block indicated by the terminal node, and searches the binary tree in the depth direction to delete the object. A flash memory device that locates a header block containing an object header. 7. The flash memory device of claim 6, wherein the memory controller configures the binary tree such that two child nodes have a binary value appended with 0 and 1 to the right of the binary value of the parent node, respectively. The flash memory device of claim 1, wherein the memory controller stores an object header of the newly generated flash file in an empty space of the header block in response to a storage command of the newly generated flash file. The method of claim 8, wherein when there is no empty space in the header block, the memory controller determines that the valid object header and the object header of the newly generated flash file are 2 if the number of valid object headers in the header block is greater than or equal to a predetermined number. Storing the valid object header and the object header of the newly generated flash file in one header block newly allocated to the flash memory when the number of valid object headers is less than the predetermined number. , Flash memory device. The binary controller of claim 1, wherein the node of depth n has a binary value indicating n LSBs or MSBs of a file ID of a flash file, and the binary value of an end node indicates a binary tree indicating a position of a header block in the flash memory. Configure In response to a newly generated flash file save command, the memory controller stores an object header of a flash file having the binary value of the end node as the LSB or MSB of the file ID, in a header block indicated by the end node, In addition, when there is no empty space in the header block, the memory controller copies the header block to the temporary storage device and then deletes the header block from the flash memory. In this case, two child nodes of the end node are generated, two header blocks respectively indicated by the two generated child nodes are allocated in the flash memory, and the valid object header and the object header of the newly generated flash file are assigned. And storing the divided header blocks in the flash memory if the number of valid object headers in the copied header blocks is less than the predetermined number, and re-allocating the deleted header blocks in the flash memory. To store the object header of the allocated flash file in the reallocated header block, Flash memory device. Storing encrypted data of a flash file in a data block of a flash memory, and storing an object header including a decryption key for decrypting the encrypted data in a header block of the flash memory; In response to a delete command of the flash file having encrypted data, deleting from the header block an object header containing a decryption key for decrypting the encrypted data. The method of claim 11, wherein the deleting step, Copying a header block in which an object header including the decryption key is stored, to a temporary storage device; Deleting the header block from the flash memory; Invalidating an object header including the decryption key in the copied header block; Reallocating the deleted header block to the flash memory; And storing a valid object header among the object headers of the copied header block in the reallocated header block. The method of claim 11, wherein the storing step stores object headers of a flash file having the same file ID in the same header block. The method of claim 11, wherein the storing step, Constructing a binary tree where a node of depth n has a binary value representing n LSBs of a file ID of a flash file and a binary value of an end node represents a location of a header block in the flash memory; Storing an object header of a flash file having a binary value as the LSB of the file ID, in a header block pointed to by the end node; The deleting step, Finding a header block containing an object header to be deleted by searching the binary tree in a depth direction. 15. The method of claim 14, wherein in the constructing the binary tree, the binary tree is configured such that two child nodes have binary values appended with 0 and 1 to the left of the binary value of the parent node, respectively. . The method of claim 11, wherein the storing step, Constructing a binary tree configured to have a node of depth n having a binary value representing n MSBs of a file ID of a flash file and the binary value of an end node representing a location of a header block in the flash memory; Storing an object header of a flash file having a binary value as the MSB of the file ID in a header block pointed to by the end node, The deleting step, Finding a header block containing an object header to be deleted by searching the binary tree in a depth direction. 17. The method of claim 16, wherein in the constructing the binary tree, constructing the binary tree such that two child nodes have a binary value appended with 0 and 1 to the right of the binary value of the parent node, respectively. . 12. The method of claim 11, further comprising storing an object header of the newly created flash file in an empty space of the header block in response to a storage command of the newly created flash file. 19. The method of claim 18, wherein in the step of storing the object header of the newly generated flash file, if there is no empty space in the header block, the valid object header if the number of valid object headers in the header block is greater than or equal to a predetermined number. And storing the object header of the newly generated flash file in two new header blocks, and if the number of valid object headers is less than the predetermined number, flashing the valid object header and the object header of the newly generated flash file. A method for securely deleting a flash file, which is stored in one header block newly allocated to memory. 12. The method of claim 11, wherein the storing step comprises: a node of depth n having a binary value representing n LSBs or MSBs of a file ID of a flash file and a binary value of an end node indicating a position of a header block in the flash memory. And storing an object header of a flash file having the binary value of the end node as the LSB or the MSB of the file ID in a header block indicated by the end node in response to a command for storing the newly generated flash file. Including steps If there is no empty space in the header block, the header block is copied to the temporary storage device and then deleted from the flash memory, and if the number of valid object headers in the copied header block is greater than or equal to a predetermined number, Create two child nodes, allocate two header blocks each pointed to by the two generated child nodes in the flash memory, and assign the valid object header and the object header of the newly generated flash file to the two header blocks. Divide and store, and if the number of valid object headers in the copied header block is less than the predetermined number, reallocate the deleted header block in the flash memory, and the valid object header and the object header of the newly generated flash file. Storing in the reallocated header block.

Images