Patent Application
20140052893
The term “non-volatile memory” generally refers to computer memory configured to retain stored information even when the memory is not powered. Electrically erasable programmable read-only memory (EEPROM) is a type of non-volatile memory typically used to store small amounts of data. Flash memory refers to non-volatile computer storage that can be electrically erased and reprogrammed and is typically used to store larger amounts of data. Flash memory stores information in an array of memory cells formed using floating-gate transistors. NOR flash memory is a type of flash memory that uses floating-gate transistors connected in a configuration that resembles a NOR gate. NAND flash memory is another type of flash memory that uses floating-gate transistors connected in a configuration that resembles a NAND gate. Flash memory can be used with storage devices including removable universal serial bus (USB) storage devices (e.g., USB flash drives), memory cards, solid-state drives (SSD), and so forth.
Although flash memory can be read or programmed a byte or a word at a time in a random-access fashion, generally this type of memory can only be erased one data block at a time. Erasing a block generally sets all bits in the block to a value of “1.” Once a block has been erased, any location within that block can be programmed. However, once a bit has been set to a value of “0,” the bit-value may only be changed to a “1” by erasing the entire block. Thus, flash memory can provide random-access read and programming operations, but does not offer arbitrary random-access rewrite or erase operations. (It should be noted that a location can be “rewritten” as long as the new value's “0” bits are a superset of the overwritten values.) Flash memory generally has a finite number of program-erase (P/E) cycles. For example, some flash memory products are configured to withstand approximately one hundred thousand (100,000) P/E cycles before wear begins to deteriorate storage integrity.
Flash memory is typically used with a controller or file system that implements a block-level interface, often referred to as a flash transition layer (FTL), to perform wear leveling and error correction, e.g., to spread writes over the available storage space and prevent incremental writing within a block. For example, when flash memory is updated, a controller or file system typically writes a new copy of the changed data to a location different from where it was previously stored, remaps associated file pointers, and subsequently erases the old data, generally at a later time. This technique is designed to minimize the number of P/E cycles. For example, some chip firmware or file system drivers are configured to count writes and dynamically remap blocks in order to spread write operations between different sectors of flash memory. Additionally, in some instances, a technique such as bad block management (BBM) can be used to verify writes and remap blocks to spare sectors when write failures are detected. These techniques are designed to minimize and compensate for memory wear, extending the useable life of flash memory devices.
Techniques are described for implementing secure file-deletion in accordance with example implementations of the present disclosure. A device includes non-volatile memory configured to store information using data storage segments that are addressable via physical addresses. The device also includes a controller operatively coupled with the non-volatile memory. The controller is configured to receive a first write request associated with a file, where the first write request includes a first portion of data and a first logical address. The controller stores the first portion of data at a first data storage segment having a first physical address and associates the first physical address with both the first logical address and a file identifier for the file. The controller is configured to receive a second write request associated with the file, where the second write request includes a second portion of data and the first logical address, and where the second portion of data is different than the first portion of data. The controller stores the second portion of data at a second data storage segment having a second physical address and associates the second physical address with both the first logical address and the file identifier. The controller is configured to receive a file delete request associated with the file, identify the first physical address and the second physical address using the file identifier, and erase the information stored at the first data storage segment and the second data storage segment based upon the identification performed using the file identifier.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The Detailed Description is described with reference to the accompanying figures. The use of the same reference numbers in different instances in the description and the figures may indicate similar or identical items.
Information is typically “removed” from flash memory by marking a block as invalid. Invalid blocks can result from wear leveling, such as when data has been rewritten to a new location. Invalid blocks can also result from identifying a bad block and remapping the data to a different block (e.g., in the case of a write failure). In these instances, some or all of the data typically remains at the previous location, and may still be accessible. Traditional file sanitization techniques designed for hard disk drives (HDD) can make secure deletion of files stored in flash memory difficult. For example, techniques that attempt to securely delete information by repeatedly writing to a particular logical address are generally unsuccessful, as the data is written to a different block each time rather than overwriting the block where the data was previously stored. Further, with flash memory, it may be difficult to execute secure file deletion while leaving other files intact.
In an example NAND flash memory implementation, memory cells are organized by word-lines and bit-lines into pages, and the pages are organized into blocks. In some instances, a page may comprise between at least approximately five hundred and twelve (512) bytes and four thousand (4,000) bytes, and a block may comprise between at least approximately thirty-two (32) pages and five hundred and twelve (512) pages. During programming in some implementations, cell levels may only be increased and not decreased. Thus, to decrease the cell levels, an entire block of cells may have to be erased together (e.g., when the minimum erasure size is a block). In this configuration, the minimum read/program size is a page. An FTL can provide a software layer to separate logical addresses (e.g., for an OS) and physical addresses (e.g., for firmware and/or channel) in the flash memory.
Solid-state drive (SSD) storage devices that use non-volatile memory offer high performance, and are used by individuals, corporations, governments, and other entities who often desire protection of confidential data, such as sensitive information stored on an SSD. Thus, it is generally desirable to provide limited access to confidential data, as well as secure file deletion when the data is no longer required. However, current file deletion techniques, which are designed for hard disk drive (HDD) storage devices, may not be effective with SSD, as previously described. Further, it may be significantly easier to access information stored on an SSD (e.g., as compared to accessing data stored on an HDD). Thus, secure file deletion for SSD's can be difficult, especially when it is desired to leave other data stored on an SSD intact. For example, one technique would be to erase the entire contents of an SSD, also erasing information associated with other files stored on the SDD. Another technique would be to use cryptographic sanitization, which can be computationally demanding and may not provide full security in all instances. Another technique would be to scan an SSD and erase all pages with logical block addresses associated with a particular file. However, this will not necessarily erase all information associated with a particular file, e.g., when wear leveling is used and invalid blocks are present but no longer associated with the file.
Techniques are described for implementing secure file-deletion in non-volatile memory, such as NAND flash memory. Techniques of the present disclosure can be used with various signal processing techniques, including algorithms, digital signal processing (DSP), coding, read channel techniques, and so forth. File identifier (ID)-based secure file deletion techniques are described. These techniques can be used with, for example, a NAND flash memory-based SSD device. In example instances, an FTL can be used to provide an interface that writes to a different physical address each time (e.g., to wear level a device). The FTL can maintain a mapping between a logical address and a physical address. In some instances, the address granularity can be the size of a page. However, a page is provided by way of example only and is not meant to be restrictive of the present disclosure. Thus, in other implementations, the address granularity can be the size of a block. With reference to
Referring now to
After wear leveling, error correction, file creation, and so forth, new entries are inserted into the table in the row of a particular file. Then, when a confidential file is deleted, the corresponding row can be removed from the table 200. When a new confidential file is created, a new row can be inserted into the table 200. In implementations, when a confidential file is deleted, the file is located in the FPAMT, and the pages associated with that file are programmed to a value of “0.” However, table 200 and its associated structure, including rows 202, 204, 206, and 208, columns, and so forth, are provided by way of example only and are not meant to be restrictive of the present disclosure. Thus, other data structures can be used, such as a table where the columns correspond to file IDs, rows correspond to physical addresses, and so forth.
Referring now to
As illustrated in
The memory module 312 is an example of tangible computer-readable media that provides storage functionality to store various data associated with operation of the controller 304, such as software programs and/or code segments, or other data to instruct the processing module 308 and possibly other components of the controller 304 to perform the steps described herein. For example, memory module 312 may be used to store one or more tables, (e.g., table 200 described in
Referring now to
In the process 400 illustrated, a write request associated with a file is received. The write request includes data and a logical address (Block 410). For example, with reference to
Then, another write request associated with a file is received. The second write request includes different data and the same logical address (Block 440). For example, with reference to
Next, a file delete request associated with the file is received (Block 470). For example, with reference to
Although the subject matter has been described in language specific to structural features and/or process operations, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
