An Efficient Secure Deletion Scheme for Flash File Systems

JOURNAL OF INFORMATION SCIENCE AND ENGINEERING 26, 27-38 (2010)

An Efficient Secure Deletion Scheme for Flash File Systems* JAEHEUNG LEE, SANGHO YI**, JUNYOUNG HEO***, HYUNGBAE PARK+, SUNG Y. SHIN++ AND YOOKUN CHO School of Computer Science and Engineering Seoul National University Seoul, 151-172 Korea E-mail: {jhlee; shyi; ykcho}@ssrnet.snu.ac.kr + Department of Computer Science and Electrical Engineering University of Missouri at Kansas City Kansas City, MO 64110, U.S.A. E-mail: [email protected] ++ Computer Science Department South Dakota State University Brookings, SD 57007, U.S.A. E-mail: [email protected] *** Department of Computer Engineering Hansung University Seoul, 136-792 Korea E-mail: [email protected] Secure deletion for flash file systems is essential for enhancing the security of embedded systems. Due to the characteristics of flash memory, existing secure deletion schemes cannot be directly adapted to flash file systems. In this paper, we propose an efficient secure deletion scheme for flash file systems. It encrypts a file’s data and stores all keys of the file in the same block. This ensures that a single erase operation is sufficient to securely delete a file. Experimental results show that our scheme significantly reduces secure deletion overhead compared with the simple encryption scheme. Keywords: secure deletion, file system, flash memory, encryption, key management

1. INTRODUCTION Generally, users assume that when they delete a file, all the blocks that store the file are physically erased. However, traditional file deletion simply removes the metadata of the file but leaves the file data intact [1]. This may violate user privacy, because the deleted file can be easily recovered. Another general misconception is that if a file was overwritten, the previous version of the file cannot be restored. In the case of magnetic media such as a hard disk, the file can still be recovered, even if the file data was overwritten [2]. Therefore, many types of secure deletion schemes for magnetic media delete files by overwriting many times [3, 4]. As the number of embedded systems in routine use increases, the number of embedded systems containing confidential information also increases. Since most embedded systems are portable, they are highly susceptible to theft. Once a device is stolen, both Received September 30, 2008; accepted January 7, 2009. Communicated by Sung Y. Shin, Jiman Hong and Tei-Wei Kuo. * This work was supported by the IT R&D program of MKE/IITA, Rep. of Korea (2008-S-023-01, Development of NanoQplus-Based Sensor Network Simulator). ** Corresponding author.

27

28

JAEHEUNG LEE, SANGHO YI, JUNYOUNG HEO, HYUNGBAE PARK, SUNG Y. SHIN AND YOOKUN CHO

existing and previously deleted files can be accessed. Flash memory is becoming a pervasive nonvolatile type of storage for embedded systems, because it is superior in terms of high access speeds, low power consumption, shock/temperature resistance, small size, light weight and mute characteristics [5]. However, because of the following characteristics of flash memory, it is hard to adapt existing secure deletion schemes to flash file systems. First, flash memory must be erased before it is over-written or programmed. Second, data erasure must be performed at the block level, while programming is performed on a page-to-page basis. For this reason, it is a challenging task to design an efficient secure deletion scheme for flash file systems. In this paper we propose an efficient secure deletion scheme for flash file systems that is adapted to YAFFS [6]. Our scheme uses encryption to delete files. Since most flash file systems are log-structured [7], there may be both current and previous file keys in flash memory. Via an unbalanced binary hash tree, our scheme ensures that all of a particular file’s keys are stored in the same block. This ensures that a single erase operation is sufficient to securely delete a file. Since the key that was used to encrypt a file’s data is contained in the file header that stores the file’s metadata, our scheme securely deletes both the keys and all the metadata of the file. Experimental results show that our scheme significantly reduces secure deletion overhead compared with the simple encryption scheme. Even though the scheme in this paper is only adapted to YAFFS, our scheme can be easily adapted to other flash file systems. The remainder of this paper is organized as follows. In section 2, we review various related work on secure deletion and YAFFS. Section 3 presents the simple encryption scheme that is used as the benchmark in our evaluation, and section 4 describes our scheme in detail. We evaluate our scheme in section 5, and our conclusion is presented in section 6.

2. RELATED WORK 2.1 Secure Deletion There are two types of secure deletion schemes, overwriting and encryption [8]. In overwriting-based secure deletion schemes, predetermined or random sequences of data overwrite the file that must be securely deleted. It is known that even after the data on magnetic media is overwritten it can potentially be recovered via Magnetic Force Microscopes (MFM) [9]. Therefore, many overwriting-based secure deletion schemes overwrite data many times. The National Institute of Standards and Technology (NIST) recommends that magnetic media should be overwritten at least three times [10]. 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), viz., DoD 5220.22-M [11]. Guttmann’s secure deletion scheme is more stringent than the previous ones [4]. It requires 35 passes of the data to securely delete files. Bauer suggests an asynchronous secure deletion scheme and implements it for the Linux kernel [3]. In encryption-based secure deletion schemes, data is securely deleted by erasing the key that was used to encrypt the data [12, 13]. However, there remains the potential for recovering data without the key; we can test all possible keys in order to recover the data. The all-or-nothing transform [14] can be used to eliminate this possibility by overwriting

AN EFFICIENT SECURE DELETION SCHEME FOR FLASH FILE SYSTEMS

29

only a small subset of the data [13]. In order to use these schemes, each file must be encrypted with a unique key. There are many file systems that ensure confidentiality of files by encrypting the file data with unique file or directory keys [15-19]. When used with these cryptographic file systems, the encryption-based secure deletion scheme can be adapted at only a small additional cost. In a flash memory environment, encryption-based schemes are preferable, because encryption/decryption operations are much less expensive than block erase operations [20]. 2.2 YAFFS YAFFS is an acronym; Yet Another Flash File System [6]. YAFFS was designed specifically for NAND flash memory. Flash memory must be erased before it is overwritten or programmed. In flash memory, data is erased at the block level, while programming is performed on a page-by-page basis. Typically, pages are 512 or 2,048 bytes in size, and each block consists of 32 or 64 pages. Due to this inconsistency, most flash file systems are log-structured file systems [7]. In YAFFS, each page includes a file ID and chunk number. Each file in YAFFS has a unique file ID. The chunk number is determined by dividing the file position by the page size. Each file’s metadata is stored in a page with the chunk number 0, while file data is stored in a page with the chunk number {1, 2, 3, …}. When a file is overwritten, previous pages are not erased. Instead, pages with new data and the same file IDs and chunk numbers are newly written at another location in flash memory. In YAFFS1, the previous pages are marked as discarded and a block containing only discarded pages is erased by the garbage collector. In YAFFS2, discarded flags are not used. Instead, all pages in YAFFS2 include a sequence number. A sequence number is introduced to meet the “write once” requirement of modern NAND flash memory. Sequence numbers increase monotonically, and are contained in every newly written block. If multiple pages have identical file IDs and chunk numbers, YAFFS2 can choose which to use based on the largest sequence number. Each page’s file ID, chunk number and sequence number is stored in the “spare data” region of flash memory. YAFFS uses the sequential allocation scheme. Pages are sequentially allocated from the current block, and when all pages in the current block have been used, another clean block is selected for allocation.

3. SIMPLE ENCRYPTION SCHEME Due to the lack of previous work on secure deletion for flash file systems, we first present the simple encryption scheme that is used as the benchmark in our evaluation. The simple encryption scheme encrypts file data via a randomly-generated key, and stores the key in the file header that stores the file’s metadata; therefore, all files are encrypted with unique keys. In the simple encryption scheme, file modification renders the current file header invalid, and the key that is used to encrypt the modified file data is stored in the newly created file header. Since the simple encryption scheme uses the same page allocation method as YAFFS, many of a file’s file headers are distributed over flash memory and these file headers are contained in either the same or different blocks.

30

JAEHEUNG LEE, SANGHO YI, JUNYOUNG HEO, HYUNGBAE PARK, SUNG Y. SHIN AND YOOKUN CHO

When a file is deleted in the simple encryption scheme, all blocks that contain a file’s file headers are erased. In the case of frequently modified files, a large number of blocks may need to be erased. When the blocks are erased, all other valid pages in the blocks must be copied to other free blocks. This can incur considerable performance overhead. To easily trace all of a file’s file headers, various tracing information is included in a file header. Each file header contains the number of a file’s previous file headers. Each file header also contains an array of three page addresses, which points to the previous file headers. The first two are direct addresses. If the number of previous file headers exceeds two, the 3rd address points to an indirect page, which contains page addresses instead of previous headers. So, if pages are 2,048 bytes in size, and four-byte page addresses are used, 514 pages can be pointed to. If the number of previous file headers exceeds 514, all previous file headers are erased. This idea is based on the UNIX inode structure [21].

4. PROPOSED SCHEME In this section, we describe our secure deletion scheme for flash file systems. As with the simple encryption scheme, our scheme uses encryption to securely delete files. Keys are randomly generated when the corresponding files are created or modified. The key that is used to encrypt the file’s data is stored in the file header that contains the file’s metadata. Thus, if all of a file’s file headers are securely deleted, it is impossible to recover the file’s data. Our scheme ensures that all of a particular file’s file headers are stored in the same block. Thus, only one erase operation is required to securely delete a file. 4.1 Data Structures A flash memory consists of blocks with a fixed size. Our scheme classifies blocks into two categories: header blocks and data blocks. Only file headers are stored in a header block. In a data block, only file data is stored. These blocks are distinguished by checking whether the chunk number of the pages in a block is zero. If so, the block is a header block, otherwise, the block is a data block. Our scheme uses a binary tree. This tree is maintained in DRAM memory and used for the newly created file header that is stored in the designated header block. In this tree, each node has a unique value. The root node has the value NULL. The left child of a node has the value 0 concatenated to the value of the parent node, while the right child of a node has the value 1 concatenated to the value of the parent node. Each leaf node has a pointer to the header block in flash memory. When the newly created file header is stored in the header block, the d least significant bits of the file ID must equal the value of the leaf node that points to the header block, where d is the node depth. Thus all file headers with the same file ID are stored in the same header block. In order to enable convenient construction of the binary tree when the file system is mounted, we include two fields viz. HB_value and HB_depth in the file header structure. HB_value denotes the value of the node, and HB_depth denotes the length of the node value.

AN EFFICIENT SECURE DELETION SCHEME FOR FLASH FILE SYSTEMS

31

Fig. 1. An example of a binary tree with its associated header blocks.

Fig. 1 shows an example of a binary tree with its associated header blocks. Here, the node with 0001 points to the header block that contains file headers with file IDs ending with 0001 in binary format. Thus, all file headers with file IDs ending with 0001 are contained in the same header block. In YAFFS, each file header uses one page. Since there are 32 or 64 pages in a block, each header block can contain a maximum of 32 or 64 file headers. Thus, our scheme must limit the number of file headers in a header block to the number of pages in a block. In the next subsection, we show the means to limit the number of file headers in a header block; we describe the operations that are performed in our scheme. 4.2 Operations In this subsection, we describe two operations that are performed in our scheme in detail. The FILE_HEADER_ADD operation is used to add a newly created file header to the designated header block, and the FILE_HEADER_DEL operation is used to delete an existing file header from the header block. 4.2.1 FILE_HEADER_ADD operation A FILE_HEADER_ADD operation is performed when a new file is created or an existing file is modified. Algorithm 1 shows the FILE_HEADER_ADD operation in detail.

Algorithm 1. FILE_HEADER_ADD operation 0- when a file “/foo/bar” is modified or created and hID is the file header that must be added, perform the following: -

32

JAEHEUNG LEE, SANGHO YI, JUNYOUNG HEO, HYUNGBAE PARK, SUNG Y. SHIN AND YOOKUN CHO

1: 02: 3: 04: 5: 06: 07:

fID = getFileID("/foo/bar"); nID = getLeafNode(fID); bADDR = findCorrespondingBlock(nID); pADDR = allocPageOnBlock(bADDR); IF

pADDR != NULL THEN writeHeaderToPage(hID ,pADDR);

ELSE

08:

sADDR = saveHeaderBlock(bADDR);

09:

nVALID = countNumberOfValidHeaders(sADDR);

10:

IF nVALID > nPAGES_PER_BLOCK / 2 THEN

11:

createLeafNodes(nID, &n0, &n1);

12:

b0 = allocBlock(n0);

13:

b1 = allocBlock(n1);

14: 15:

divideValidHeadersToBlocks(hID, sADDR, b0, b1); ELSE

16:

nbADDR = allocBlock(nID);

17:

copyValidHeadersToBlock(hID, sADDR, nbADDR);

18:

END IF

19:

eraseHeaderBlock(bADDR);

20: END IF

fID is the file ID of the created or modified file. nID is the leaf node with the value equal to the d least significant bits of fID, where d is the node depth. This can be obtained by starting at the root node and tracing pointers from node-to-node according to the value of the ith least significant bit of fID, where i is the node depth. bADDR is the header block that is pointed to by nID. If there is an empty page for the file header in bADDR, the function allocPageOnBlock() returns the address of the space. Then, we can store the file header hID in the header block and end the operation. If there is no empty page for the file header in bADDR, the header block bADDR is copied to DRAM. sADDR is the address in DRAM to which bADDR is copied. nVALID is the number of valid file headers in sADDR and nPAGES_PER_BLOCK is the number of pages in a block. If nVALID exceeds 50% of nPAGES_PER_BLOCK, two header blocks with the values 0 and 1 concatenated to the value of bADDR are allocated, and hID and all valid file headers in sADDR are copied to the allocated header blocks according to their file IDs. Otherwise, only one header block with the same value of bADDR is allocated, and hID and all valid file headers in sADDR are copied to the allocated header block. The reason for distinguishing these two cases is efficiency. If one header block is allocated when nVALID is almost as large as nPAGES_PER_BLOCK, only a few pages will be available for the newly created file headers, and the allocated block will soon be full. This causes frequent block erase operations. Finally, bADDR is erased. If bADDR is erased before the new header blocks are allocated and copied, file headers in bADDR can be lost in the case of a power failure. Thus, header blocks must be allocated and copied first, before bADDR is erased.

AN EFFICIENT SECURE DELETION SCHEME FOR FLASH FILE SYSTEMS

33

4.2.2 FILE_HEADER_DEL operation A FILE_HEADER_DEL operation is performed when a file is securely deleted. Algorithm 2 shows the FILE_HEADER_DEL operation in detail.

Algorithm 2. FILE_HEADER_DEL operation - when a file “/foo/bar” must be securely deleted, perform the following: 01: fID = getFileID("/foo/bar"); 02: nID = getLeafNode(fID); 03: bADDR = findCorrespondingBlock(nID); 04: sADDR = saveHeaderBlock(bADDR); 05: invalidateHeadersByFileID(fID, sADDR); 06: nbADDR = allocBlock(nID); 07: copyValidHeadersToBlock(NULL, sADDR, nbADDR); 08: eraseHeaderBlock(bADDR);

fID is the file ID of the file that must be securely deleted. nID is the leaf node with the value equal to the d least significant bits of fID, where d is the node depth. This can be obtained by starting at the root node and tracing pointers from node-to-node according to the value of the ith least significant bit of fID, where i is the node depth. bADDR is the header block that is pointed to by nID. The header block bADDR is copied to DRAM. sADDR is the address in DRAM to which bADDR is copied. The file header with the file ID fID is invalidated at line 5. The new header block nbADDR is allocated and pointed to by nID. All valid file headers in sADDR are copied to nbADDR, and finally bADDR is erased.

5. EVALUATION In order to evaluate the overhead incurred by our secure deletion scheme, we constructed a simulation program that counts the number of block erases performed due to file creation or modification in our scheme. Our scheme amortizes (distributes) part of the block erase overhead of file deletion over file creation and modification. Since a single erase operation is required to securely delete a file in our scheme, the amortized number of block erases for secure deletion can be calculated by adding one to the output of the simulation program. The modification ratio, m represents the average number of file modifications performed per file created. For example, if the modification ratio is two, each file is said to have been modified twice on average, since its creation. In the simple encryption scheme, the average number of file headers per file is m + 1. Let n denote the number of blocks in the file system. If we assume that file headers are uniformly, independently distributed over the file system, the amortized number of block erases for secure deletion in the simple encryption scheme is given by Theorem 1.

34

JAEHEUNG LEE, SANGHO YI, JUNYOUNG HEO, HYUNGBAE PARK, SUNG Y. SHIN AND YOOKUN CHO

Theorem 1 The amortized number of block erases E for secure deletion in the simple encryption scheme is given by: 1 E = n(1 − (1 − ) m+1 ) . n

Proof: The probability that a file header is not in a particular block is: Pr[ FHNS ] = 1 −

1. n

Since the average number of a file’s file headers is m + 1 in the simple encryption scheme, the probability that none of a file’s file headers are in a particular block can be calculated as follows: 1 Pr[ FHNM ] = (1 − ) m+1 . n

Thus, the probability that a file’s file headers are in a particular block is: 1 Pr[ FHM ] = 1 − (1 − ) m +1 . n

Since there are n blocks in the file system, we can obtain the amortized number of block erases for secure deletion in the simple encryption scheme by multiplying Pr[FHM] by n. 1 E = n(1 − (1 − ) m+1 ) . n

(1)

Our scheme with c = 100 Our scheme with c = 100000

Our scheme with c = 1000 Our scheme with c = 1000000

Our scheme with c = 10000 The simple encryption scheme

The amortized number of block erase

3.0 2.5 2.0 1.5 1.0 0.5 0.0 0.0

0.1

0.2

0.5

1.0

2.0

The modification ratio

Fig. 2. Amortized number of block erases for secure deletion.

Fig. 2 shows the amortized number of block erases for secure deletion in our scheme and the simple encryption scheme. The results for our scheme were obtained via

AN EFFICIENT SECURE DELETION SCHEME FOR FLASH FILE SYSTEMS

35

simulation, while the results for the simple encryption scheme were obtained via Eq. (1). We assume the number of pages in the block is 32 and n is 256. We executed the simulation program ten times per parameter set, and averaged the result. The x-axis represents the modification ratio. The y-axis represents the amortized number of block erases per file created. In our scheme, c represents the number of files created. Except for the case where the modification ratio is 0.0, it is clear that our scheme is more efficient than the simple encryption scheme. It is also clear that the number of files created does not significantly affect the results. The difference between the secure deletion overhead in our scheme and that of the simple encryption scheme increases as the modification ratio increases. Since the block erase operation is the most time-consuming operation, our scheme shows better performance for secure deletion than the simple encryption scheme.

6. CONCLUSION We designed an efficient secure deletion scheme for flash file systems. Our scheme stores all the file data in encrypted form, and deletes all keys that were used to encrypt the file’s data, to securely delete the file. Due to flash memory characteristics, logstructured file systems are generally used for flash file systems. There can be many keys for a particular file in a log-structured file system. To delete all keys of a particular file with a single erase operation, we designed data structures and algorithms that ensure that all keys of a particular file are stored in the same block. Since the key that was used to encrypt a file’s data is contained in the file header that stores the file’s metadata, our scheme securely deletes both the keys and all the metadata of the file. Experimental results show that our scheme significantly reduces secure deletion overhead compared with the simple encryption scheme. Even though our scheme is only adapted to YAFFS in this paper, our scheme can easily be adapted to other types of flash file systems.

REFERENCES 1. N. Joukov and E. Zadok, “Adding secure deletion to your favorite file system,” in Proceedings of the 3rd International IEEE Security in Storage Workshop, 2005, pp. 63-70. 2. I. Mayergoyz, C. Seprico, C. Krafft, and C. Tse, “Magnetic imaging on a spinstand,” Journal of Applied Physics, Vol. 87, 2000, pp. 6824-6826. 3. S. Bauer and N. B. Priyantha, “Secure data deletion for Linux file systems,” in Proceedings of the 10th USENIX Security Symposium, 2001, pp. 153-164. 4. P. Gutmann, “Secure deletion of data from magnetic and solid-state memory,” in Proceedings of the 6th USENIX UNIX Security Symposium, 1996, pp. 77-90. 5. 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, 1994, pp. 25-37. 6. Aleph One Ltd, Embedded Debian, “Yaffs: A NAND-flash filesystem,” http://www. aleph1.co.uk/yaffs/. 7. M. Rosenblum and J. K. Ousterhout, “The design and implementation of a log-structured file system,” ACM Transactions on Computer Systems, Vol. 10, 1992, pp. 26-52.

36

JAEHEUNG LEE, SANGHO YI, JUNYOUNG HEO, HYUNGBAE PARK, SUNG Y. SHIN AND YOOKUN CHO

8. N. Joukov, H. Papaxenopoulos, and E. Zadok, “Secure deletion myths, issues, and solutions,” in Proceedings of the 2nd ACM Workshop on Storage Security and Survivability, 2006, pp. 61-66. 9. R. Gomez, A. Adly, I. Mayergoyz, and E. Burke, “Magnetic force scanning tunnelling microscope imaging of overwritten data,” IEEE Transactions on Magnetics, Vol. 28, 1992, pp. 3141-3143. 10. 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), 2003. 11. Defense Security Service, “National industrial security program operating manual (NISPOM), chapter 8: automated information system security,” U.S. Government Printing Office, 1995. 12. D. Boneh and R. Lipton, “A revocable backup system,” in Proceedings of the 6th USENIX UNIX Security Symposium, 1996, pp. 91-96. 13. 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 USENIX Conference on File and Storage Technologies, 2005, pp. 143-154. 14. R. L. Rivest, “All-or-nothing encryption and the package transform,” in Proceedings of the Fast Software Encryption Conference, 1997, pp. 210-218. 15. M. Blaze, “A cryptographic file system for UNIX,” in Proceedings of the 1st ACM Conference on Computer and Communications Security, 1993, pp. 9-16. 16. 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, 2001, pp. 199-212. 17. Microsoft Corporation, Encrypting File System for Windows 2000, 1999. 18. C. Wright, M. Martino, and E. Zadok, “Ncryptfs: A secure and convenient cryptographic file system,” in Proceedings of the Annual USENIX Technical Conference, 2003, pp. 197-210. 19. E. Zadok, I. Badulescu, and A. Shender, “Cryptfs: A stackable vnode level encryption file system,” Technical Report No. CUCS-021-98, Computer Science Department, Columbia University, 1998. 20. Samsung Electronics Co., NAND Flash Memory & SmartMedia Data Book, 2002, http://www.samsung.com/. 21. D. M. Ritchie and K. Thompson, “The UNIX time-sharing system,” Communications of the ACM, Vol. 17, 1974, pp. 365-375. Jaeheung Lee received the B.E. degree in Computer Science and Engineering from Seoul National University, Seoul, Korea, in 2001, the M.S. degree in Computer Science and Engineering from Seoul National University, Seoul, Korea, in 2003. He has been with School of Computer Science and Engineering, Seoul National University since 2007, where currently he is a Ph.D. candidate student. From January 2003 to February 2007, he worked as an engineer for Samsung Electronics in Korea. His research interests include cryptography, system security, network security, operating systems and sensor networks.

AN EFFICIENT SECURE DELETION SCHEME FOR FLASH FILE SYSTEMS

37

Sangho Yi received the B.E. degree in Electrical Engineering from Korea University, Seoul, Korea in 2003 and the Ph.D. degree in School of Computer Science and Engineering, Seoul National University, Seoul, Korea in 2008. He has been with Institute of Computer Technology, Seoul National University since 2008, where currently he is a postdoctoral researcher. His research interests include embedded operating systems, real-time systems, fault tolerance computing systems, and sensor networks.

Junyoung Heo received the B.E. and Ph.D. degrees in computer engineering from Seoul National University, Seoul, Korea, in 1998 and 2009 respectively. He has been with the Department of Computer Engineering, Hansung University, Seoul, Korea, since 2009, where he is currently an Assistant Professor. From 1998 to 2002, he worked as a Software Engineer for Nadatel and SPSoft/Inzen in Korea. His research interests include operating systems, wireless sensor networks, embedded systems, and fault tolerance.

Hyungbae Park received the B.S. degree in the Department of Computer Engineering from Kwangwoon University, Seoul, Korea in 2005 and the M.S. degree in Computer Science from South Dakota State University, Brookings, South Dakota, USA in 2007. He is a Ph.D. student in Computer Science at University of Missouri at Kansas City since 2008. His research interests include fault tolerance computing systems and sensor network systems.

Sung Y. Shin received his Ph.D. in Computer Science from University of Wyoming in 1991. Dr. Shin is a professor and graduate coordinator of EE & Computer Science department at South Dakota State University. He is currently working as an invited professor of Computer Science and Engineering at Seoul National University, Seoul, Korea. He worked as a visiting scientist in Space and Life Science Division at NASA, Johnson Space Center in Houston, Texas in 1999 and 2001. He organized numerous international conferences, and he currently served as ACM SAC 2009 Conference Chair. His research interests are GIS, Telemedicine and Software Fault Tolerance has been funded by NASA and NSF, and he has published over 100 technical papers.

38

JAEHEUNG LEE, SANGHO YI, JUNYOUNG HEO, HYUNGBAE PARK, SUNG Y. SHIN AND YOOKUN CHO

Yookun Cho received the B.E. degree from Seoul National University, Korea, in 1971 and the Ph.D. degree in Computer Science from the University of Minnesota at Minneapolis in 1978. He has been with the School of Computer Science and Engineering, Seoul National University since 1979, where he is currently a professor. He was a visiting assistant professor at the University of Minnesota during 1985 and a director of the Educational and Research Computing Center at Seoul National University from 1993 to 1995. He was president of the Korea Information Science Society during 2001. He was a member of the program committee of the IPPS/SPDP’98 in 1997 and the International Conference on High Performance Computing from 1995 to 1997. His research interests include operating systems, algorithms, system security, and fault-tolerant computing systems. He is a member of the IEEE.