Secure Deletion for NAND Flash File System Jaeheung Lee1, Junyoung Heo1, Yookun Cho1, Jiman Hong*2, Sung Y. Shin3 1
School of Computer Science and Engineering, Seoul National University, Seoul, Korea 2
3
School of Computing, Soongsil University, Seoul, Korea
Computer Science Department, South Dakota State University, Brookings, SD 57007, USA
{jhlee, jyheo, cho}@ssrnet.snu.ac.kr,
[email protected],
[email protected] ABSTRACT
recovered.
In most file systems, if a file is deleted, only the metadata of the file is deleted or modified and the file’s data is still stored on the physical media. Some users require that deleted files no longer be accessible. This requirement is more important in embedded systems that employ flash memory as a storage medium. In this paper, we have designed a NAND flash file system that has a secure deletion functionality. We modified YAFFS to support secure deletion. Our method uses encryption to delete files and forces all keys of a specific file to be stored in the same block. Therefore, only one erase operation is required to securely delete a file. The proposed method securely deletes not only keys but also all of the metadata of that file. Our simulation results show that the number of block erases due to file creation and file modification is very low and the amortized number of block erases is lower than the simple encryption method. Even though we applied our method only to the YAFFS, our method can be easily applied to other NAND flash file systems.
Another general misconception is that if a file is overwritten, the previous version of the file cannot be restored. In the case of magnetic media such as a hard disk, a file can still be recovered even if the data of the file is overwritten [13]. Therefore, many secure deletion methods for magnetic media delete files by overwriting multiple times [2, 10]. As the number of embedded systems in everyday usage continues to grow, many embedded systems have become to contain more confidential information. Since most embedded systems are portable, they are highly susceptible to theft. Once a device is stolen, not only existing but also already deleted files can be accessed. Flash memory is becoming pervasive as nonvolatile storages for embedded systems because of its superiority in terms of high access speeds, low power consumption, shock/temperature resistance, small size, light weight and its mute characteristics [7]. These properties come from the fact that flash memory does not have mechanical limitations and latencies of hard drives.
Categories and Subject Descriptors
There are two types of flash memory: NOR and NAND. NAND flash is cheaper and offers more storage capacity. Moreover, in the case of large data read/write, it provides better performance than NOR flash. Therefore, NAND flash is widely used as mass data storage for mobile embedded systems.
D.4.3 [Operating Systems]: File Systems Management; D.4.6 [Operating Systems]: Security and Protection – Cryptographic controls
General Terms
Flash memory must be erased before it is re-written or programmed. In flash memory, data is erased at the block level and programming is done on a page basis. In general, a block size is either 32 pages of 512 bytes or 64 pages of 2048 bytes. Due to this mismatch, log-structured file systems [16] are generally used for flash file systems. Therefore, most flash file systems including YAFFS [1], the first NAND-specific flash file system, are logstructured file systems.
Algorithms, Performance, Design, Security
Keywords Secure deletion, File system, Flash memory, Encryption, Key management
1. INTRODUCTION Generally, people think that when they delete a file, all of the blocks that the file was using are physically erased. However, when the file is deleted, only the metadata of the file is deleted or modified and the file’s data is still stored on the physical media in most file systems [12]. Therefore, a deleted file can be easily
There are two types of secure deletion methods [11]. The first type is overwriting the whole data of a file [10]. The second is encrypting the data and using the first method to securely delete a key which has been used to encrypt the data [4]. The second method is more preferable in flash environment because an erase operation in flash memory adds more overhead than an en/decryption operation.
* Corresponding author
In this paper we propose a secure deletion method for NAND flash file system. We modified YAFFS to support secure deletion. Our method uses encryption to delete files. Since YAFFS is a logstructured file system, there may not only be current but also many previous keys of a file in the flash memory. Our method forces all keys of a specific file to be stored in the same block. Therefore, only one erase operation is required to securely delete a file. Since the key which has been used to encrypt file’s data is
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’08, March 16-20, 2008, Fortaleza, Ceará, Brazil. Copyright 2008 ACM 978-1-59593-753-7/08/0003…$5.00.
1710
sequence number is introduced to meet the “write once” requirement of modern NAND flash. A sequence number is monotonically increasing and marked on every newly written block. When multiple pages have identical file ids and chunk numbers, YAFFS2 can choose which one to use by taking the largest sequence number. Each page’s file id, chunk number and sequence number are stored in the “spare data” region of the flash memory.
stored in an object header that stores a file’s metadata, the proposed method securely deletes not only keys but also all of the metadata of that file. Even though we applied our method only to the YAFFS, it can be easily applied to other NAND flash file systems. The rest of this paper is organized as follows. We review some previous work on secure deletion and YAFFS in section 2, and we present our method in section 3. We evaluate our method in section 4 and conclusion will be presented in section 5.
YAFFS uses the sequential allocation scheme. Pages are allocated sequentially from the current block and when all the pages in the current block are used, another clean block is selected for allocation.
2. RELATED WORKS 2.1 Secure Deletion
3. PROPOSED METHOD
There are two types of secure deletion methods, overwriting and encryption.
In this section, we describe our secure deletion method for NAND flash file system. Our method uses encryption to securely delete files. In our method, all files are encrypted with keys which differ from file to file. These keys are generated randomly when the corresponding files are created or modified. The key that is used to encrypt a file’s data is stored in an object header which stores file’s metadata. Thus, if all object headers of a file are securely deleted, it is impossible to recover the data of the file. But as mentioned in the previous section, multiple pages can have an identical file ids and chunk numbers in YAFFS2. This is due to the log-structured design of YAFFS. Therefore, not only current but also all previous object headers of the file should be deleted to ensure that the data of the file is irrecoverable. Our method forces all object headers of a specific file to be stored in the same block. Thus, only one erase operation is required to securely delete a file.
In overwriting, predetermined or random sequences of data are written over the file which has to be deleted securely. It is known that even after the data on magnetic media is overwritten, there is a chance that it can potentially be recovered by using Magnetic Force Microscopes (MFM) [8]. Therefore, many overwriting based secure deletion methods overwrite data multiple times. The National Institute of Standards and Technology (NIST) recommends that magnetic media should be overwritten at least three times [9]. The U.S. Department of Defense’s standard for clearing or sanitizing sensitive information is described in the National Industrial Security Program Operating Manual (NISPOM), also called DoD 5220.22-M [6]. Guttmann’s secure deletion is more stringent than the previous ones [10]. Guttmann’s method takes 35 passes over the data to delete files securely. Bauer suggests an asynchronous secure deletion method and implements for the Linux kernel [2].
3.1 Storage Format A flash memory consists of blocks with fixed size. The proposed method classifies blocks into two categories: header block and data block. Only object headers are stored in a header block. In a data block, only file data are stored. These blocks can be distinguished by checking if the chunk number of the pages in a block is 0. If the chunk number is 0, the block is a header block. If not, the block is a data block.
In encryption-based secure deletion methods, data can be securely deleted by erasing a key which has been used to encrypt the data [4, 15]. In order to use these methods, every file should be encrypted with a different key. There are many file systems that ensure confidentiality of files by encrypting the file data with individual file or directory keys [3, 5, 14, 17, 18]. When used with these cryptographic file systems, the encryption-based secure deletion method can be applied with only a small additional cost.
The proposed method uses a binary tree structure. This tree is maintained in DRAM memory and used for the newly created object header to be stored at the designated header block. In this tree structure, each node has a unique value. The root node has a value NULL. The left child of a node has a value 0 concatenated with the value of the parent node, while the right child of a node has a value of 1 concatenated with the value of the parent node. Each leaf node has a pointer to the header block. When the newly created object header is stored at the header block, the n least significant bits of the file id should be equal to the value of the leaf node which points to the header block where n is the depth of the node. Thus all object headers with the same file id are stored in the same header block.
2.2 YAFFS YAFFS is an acronym for “yet another flash file system” [1]. YAFFS has been designed specifically for NAND flash. In flash memory, erase operation adds large overhead due to erase block size. Thus YAFFS is designed to avoid in-place rewriting. In YAFFS, each page includes a file id and a chunk number. Each file in YAFFS has its own file id. The chunk number is determined by dividing the file position by the chunk size. Each file’s metadata is stored in a page whose chunk number is 0. File data is stored in a page whose chunk number is 1, 2, 3, etc. If a file is overwritten, the previous pages are replaced by new pages with new data but same file ids and chunk numbers. In YAFFS1, the overwritten pages are marked as ‘discarded’ and a block containing only discarded pages will be erased by the garbage collector. In YAFFS2, ‘discarded’ flags are not used. Instead, all pages in YAFFS2 include a sequence number. A
In order to make it easier to construct of the binary tree when the proposed file system is mounted, we add two fields named HB_value and HB_depth to the object header structure. HB_value is the value of the node and HB_depth is the length of the node value.
1711
X 0 00
1 10
11
01 001 0001
101
011
111
1001 DRAM
object header
…
data
invalid
FLASH
Figure 1. An example of a binary tree with its associated header blocks
pointers from node to node according to the value of nth least significant bit of file id where n is the depth of the node.
Figure 1 shows an example of the binary tree and its associated header blocks. In this figure, the node whose value is ‘0001’ points to the header block which stores object headers with file id that ends with ‘0001’ in binary format. Thus all object headers with the file id that ends with ‘0001’ are stored in the same header block.
③ Check whether there is an empty space for the object header in the header block which is pointed by the leaf node that has been found at the second step. If there is an empty space, just store the object header into the header block and end the operation.
In YAFFS, each object header occupies 1 page. Since there are 32 or 64 pages in a block, each header block can contain until 32 or 64 object headers. Thus, our method limits the number of object headers in a header block to the number of pages in a block.
④ If there is not an empty space, copy the header block to DRAM. ⑤ Count the number of valid object headers in the header block.
In the next subsection, we will show you how to limit the number of object headers in a header block by describing the operations that are performed in the proposed method.
⑥ If the number of valid object headers in the header block is larger than half of the number of pages in a block, allocate two header blocks whose values are 0 and 1 concatenated with the value of the previous header block and store valid object headers and the object header to be added into these two header block according to their file id.
3.2 Operation In this subsection, we describe two operations that are performed in our method in detail. OBJECT_HEADER_ADD operation is used to add new object header to a header block and OBJECT_HEADER_DEL operation is used to delete existing object header from a header block.
⑦ Otherwise, allocate one header block whose value is the same as the value of the previous header block and store valid object headers and the object header to be added into the allocated block.
3.2.1 OBJECT_HEADER_ADD operation
⑧ Erase the block that has been copied at the fourth step.
An OBJECT_HEADER_ADD operation occurs when new file is created or existent file is changed. The OBJECT_HEADER_ADD operation is performed as follows:
If block is erased before block is allocated and stored, all object headers in the header block may be lost in case of a power failure. Thus, a block should be allocated first and stored before it is erased.
① Get the file id of the created or changed file. ② Find the leaf node that has the value equal to the n least significant bits of the file id where n is the depth of the node. This is done by starting at the root node and following
1712
3.2.2 OBJECT_HEADER_DEL operation
⑥ Erase the block which has been copied at the third step.
An OBJECT_HEADER_DEL operation occurs when a file is securely deleted. The OBJECT_HEADER_DEL operation is performed as follows:
4. EVALUATION In order to evaluate the overhead incurred from our secure deletion method, we conducted a simulation that inputs two integers, which represent the number of file creation and file modification, and outputs the number of block erases performed due to file creation and file modification. We assume that the number of pages in the block is 32.
① Get the file id of the file to be securely deleted. ② Find the leaf node that has the value equal to the n least significant bits of the file id where n is the depth of the node. This is done by starting at the root node and following pointers from node to node according to the value of nth least significant bit of file id where n is the depth of the node.
Figure 2 shows the average number of block erases per created file performed due to file creation and file modification for various numbers of created files and modification ratios. We ran the program ten times for each set of parameters and averaged the result.
③ Copy the header block which is pointed by the leaf node that has been found at the second step to DRAM. ④ Invalidate object headers which have the file id that has been found at the first step. ⑤ Allocate one header block whose value is the same as the value of the previous header block and store valid object headers into the allocated block. 0.4
modification ratio modification ratio modification ratio modification ratio modification ratio modification ratio modification ratio
Number of block erases per created file
0.35
= 0.0 = 0.1 = 0.2 = 0.5 = 1.0 = 2.0 = 5.0
0.3
0.25
0.2
0.15
0.1
0.05
0 100
1000
10000
100000
1e+006
Number of created files
Figure 2. Average number of block erases per created file for various numbers of created files and modification ratios # of block erases in the proposed method
The modification ratio represents the average number of file modification performed for each created file. For example, if the modification ratio is 2, each file is said to have been modified twice on average after the file is created. The x-axis represents the number of created files. The y-axis represents the average number of block erases per created file. This can be derived by dividing the number of block erases performed due to file creation and file modification by the number of created files.
= 1 + the number of block erases per created file (y-axis value) The simplest method of performing secure deletion with encryption is to encrypt file data with a randomly-generated key and to store it in an object header and not to do anything else. In the simple encryption method, file modification makes the existing object header invalid and the object header will be erased by the garbage collector. Thus we can think of the number of block erases due to each file modification as 1 divided by the number of pages in a block. If we assume that the object headers of a specific file are in different blocks, the amortized number of
The proposed method amortizes (spreads out) part of block erase overhead of file deletion over file creation and file modification. Since only one erase operation is required to securely delete a file in our method, the amortized number of block erases for secure deletion can be calculated as follows:
1713
[5] G. Cattaneo, L. Catuogno, A. D. Sorbo, and P. Persiano. The design and implementation of a transparent cryptographic file system for UNIX. In Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference, pages 199–212, 2001.
block erases for secure deletion in the simple encryption method can be calculated as follows: # of block erases in the simple encryption method = 1 + modification ratio + (1 / 32) * modification ratio Except when the modification ratio is 0.0, the modification ratio is always larger than the y-axis value. It means that the amortized number of block erases for secure deletion in the simple encryption method is larger than the amortized number in our method. Since a block erase is the most time-consuming operation, our method shows better performance for secure deletion of a file than the simple encryption method.
5. CONCLUSIONS We have designed a NAND flash file system that has a secure deletion functionality. To the best of our knowledge, it is the first flash file system that was designed to have secure deletion functionality.
[6] Defense Security Service. National Industrial Security Program Operating Manual (NISPOM), chapter 8: Automated Information System Security. U.S. Government Printing Office, January 1995. [7] F. Douglis, R. Caceres, F. Kaashoek, K. Li, B. Marsh, and J. A. Tauber. Storage alternatives for mobile computers. In Proceedings of the 1st Symposium on Operating Systems Design and Implementation (OSDI), pages 25-37. 1994. [8] R. Gomez, A. Adly, I. Mayergoyz, and E. Burke. Magnetic Force Scanning Tunnelling Microscope Imaging of Overwritten Data. IEEE Transactions on Magnetics, 28(5):3141.3143, September 1992. [9] T. Grance, M. Stevens, and M. Myers. Guide to Selecting Information Technology Security Products, chapter 5.9: Media Sanitizing. National Institute of Standards and Technology (NIST), October 2003.
The flash file system stores all file data in encrypted form and securely deletes the keys which have been used to encrypt the file’s data to securely delete the file. Due to the flash memory characteristics, log-structured file systems are generally used for flash file systems. There can be many keys of a specific file in a log-structured file system. To delete all keys of a specific file with only one erase operation, we have designed data structures and algorithms which force all keys of the file to be stored in the same block. Since the key which has been used to encrypt file’s data is stored in an object header which stores file’s metadata, the proposed method securely deletes not only keys but also all of the metadata of a file.
[10] P. Gutmann. Secure Deletion of Data from Magnetic and Solid-State Memory. In Proceedings of the Sixth USENIX UNIX Security Symposium, pages 77-90, San Jose, CA, July 1996. USENIX Association. [11] Nikolai Joukov, Harry Papaxenopoulos, Erez Zadok. Secure Deletion Myths, Issues, and Solutions. In Proceedings of the 2nd ACM Workshop on Storage Security and Survivability, Alexandria, Virginia, October 2006. [12] Nikolai Joukov and Erez Zadok. Adding Secure Deletion to Your Favorite File System. In Proceedings of the third international IEEE Security in Storage Workshop (SISW 2005), San Fransisco, CA, December 2005. IEEE Computer Society.
The simulation results show that the number of block erases due to file creation and file modification is very low and the amortized number of block erases is lower than the simple encryption method. Even though we applied our method only to the YAFFS, it can be easily applied to other NAND flash file systems.
[13] I. Mayergoyz, C.Seprico, C.Krafft, and C. Tse. Magnetic Imaging on a Spin-Stand. Journal of Applied Physics, 87(9):6824-6826, May 2000. [14] Microsoft Corporation. Encrypting file system for Windows 2000, 1999.
6. ACKNOWLEDGMENTS This research was supported by the Soongsil University Research Fund, and MIC & IITA through IT Leading R&D Support Project.
7. REFERENCES [1] Aleph One Ltd, Embedded Debian. Yaffs: A NAND-Flash Filesystem. http://www.aleph1.co.uk/yaffs/.
[15] Z. N. J. Peterson, R. Burns, J. Herring, A. Stubblefield and A. D. Rubin. Secure Deletion for a Versioning File System. In Proceedings of the 4th conference on USENIX Conference on File and Storage Technologies (FAST 2005), San Francisco, CA, 2005. [16] Mendel Rosenblum and John K. Ousterhout. The Design and Implementation of a Log-Structured File System. ACM Transactions on Computer Systems, 10(1), 1992.
[2] S. Bauer and N. B. Priyantha. Secure Data Deletion for Linux File Systems. In Proceedings of the 10th USENIX Security Symposium, pages 153-164, Washington, DC, August 2001. USENIX Association.
[17] C. Wright, M. Martino, and E. Zadok. Ncryptfs: A secure and convenient cryptographic file system. In Proceedings of the Annual USENIX Technical Conference, pages 197–210, 2003.
[3] M. Blaze. A cryptographic file system for UNIX. In CCS ’93: Proceedings of the 1st ACM conference on Computer and communications security, pages 9–16, 1993.
[18] E. Zadok, I. Badulescu, and A. Shender. Cryptfs: A stackable vnode level encryption file system. TR CUCS-021-98, Computer Science Department, Columbia University, 1998.
[4] D. Boneh and R. Lipton. A Revocable Backup System. In Proceedings of the 6th USENIX UNIX Security Symposium, pages 91-96, San Jose, CA, July 1996, USENIX Association.
1714
