WO2016085532A1

WO2016085532A1 - Secure file deletion

Info

Publication number: WO2016085532A1
Application number: PCT/US2015/012057
Authority: WO
Inventors: Chaitanya NARRA; Amarish S V
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2014-11-26
Filing date: 2015-01-20
Publication date: 2016-06-02

Abstract

Some examples relate to secure file deletion. In an example, request may be received for deleting a file. A hard link of the file to be deleted may be added to special directory. A block assigned to the file overwritten with randomly generated data equal to size of the block. A reference count of the block may be decremented by a single unit, the reference count of the block was previously incremented with a value corresponding to a value assigned to an attribute of the file. A determination may be made whether the reference count of the block is zero. If reference count of the block is zero, the block may be released for further use. A determination may be made whether file size of the file is zero. If file size of file is zero, the hard link of the file may be deleted from the special directory.

Description

SECURE FILE DELETION

Background

[001] Increased adoption of computing devices such as desktops, laptops, mobile phones, smart phones, Personal Digital Assistants (PDAs), and the like, has led to a digital world where users, both enterprise and individuals, prefer to store their data whether it is a document, a spreadsheet, a photograph, etc. in a data file. Needless to say, this has led to millions of files being created and stored each day on millions of devices. However, there may be many reasons such as personal, business, regulatory, etc. when a user may wish to permanently delete or erase a file from a computing or storage device.

Brief Description of the Drawings

[002] For a better understanding of the solution, embodiments will now be described, purely by way of example, with reference to the accompanying drawings, in which:

[003] FIG. 1 is a block diagram of an example computing device for secure file deletion;

[004] FIG. 2 is a flow chart of an example method of secure file deletion; and [005] FIG. 3 is a block diagram of an example system for secure file deletion. Detailed Description

[006] A large amount of data stored these days is in the form of data files or "files", which are typically organized by a file system. A file system is an integral part of an operating system. It provides the underlying structure that a computing device uses to organize data on a storage medium. A computer file or "file" is the basic component of a file system. Each piece of data on a storage device may be called a "file". A file may contain data, such as text files, image files, video files, and the like, or it may be an executable file or program.

[007] Files may be organized by storing related files in a directory or subdirectory. A directory or sub-directory is also a file. The term "directory" (or "file directory), as used herein, may include a file that contains references (for example, names) to other files. Thus, a directory may be considered as a container for files.

[008] A file system may be associated with a volume, which is, generally, a single accessible storage area on a single partition of a storage medium, such as a hard disk, optical disc, NAND flash memory, etc. A volume may be divided into blocks, which is a sequence of bits or bytes. Many file systems use blocks to store file and directories. In an instance, a file or directory may be stored over several blocks that may be located at various places on a volume. In other words, a directory may be spread over different physical areas of a storage medium.

[009] Thus, a file system provides a useful mechanism for a user to organize data. However, there may be times or reasons when a user may wish to delete a file from a computing or storage device. Typically, an option to delete a file or directory is made available to a user as part of a computer or system application. However, many a times a deleted file is not completely erased from a system, and there are tool and utilities available that may help recover a deleted file. Needless to say this is not an ideal scenario from a user's (business or individual) perspective since data (for example, confidential or sensitive data) that may have been deleted by a user may persist in the hardware of the system, which could be recovered and potentially misused by another user for improper gains and benefits. Therefore, it is desirable to have a solution that performs secure deletion i.e. erasure of data after its nominal deletion.

[0010] To address this requirement, the present disclosure describes various examples for securely deleting a file. In an example, a computing or storage device may receive a request for deleting a file. Upon such receipt, a hard link of the file may be added to a special directory. A file deletion module may then overwrite a block assigned to the file with randomly generated data equal to size of the block. After the block is overwritten, a reference count of the block may be decremented by a single unit, wherein the reference count of the block is previously incremented with a value corresponding to a value assigned to an attribute of the file. A determination is then made whether the reference count of the block is zero. If the reference count of the block is zero, the block may be released for further use. A further determination may be made to ascertain whether size of the file (i.e. file size) is zero. If the file size is zero, the hard link of the file may be deleted from the special directory.

[0011] FIG. 1 is a block diagram of an example computing device 100 for secure file deletion. Computing device 100 may generally represent any type of computing system capable of reading machine-executable instructions. Examples of computing device may include, without limitation, a desktop computer, a notebook computer, a tablet computer, a server, a thin client, a mobile device, a personal digital assistant (PDA), a phablet, and the like.

[0012] In an example, computing device 100 may include a processor and a memory. Processor may be any type of Central Processing Unit (CPU), microprocessor, or processing logic that may interpret and executes machine-readable instructions stored in memory. [0013] Memory may be a random access memory (RAM), Synchronous DRAM (SDRAM), Double Data Rate (DDR), Rambus DRAM (RDRAM), Rambus RAM, and the like. In an example, memory may be a non-transitory memory.

[0014] In an example, computing device 100 may be a storage device or system. Computing device 100 may be a primary storage device such as, but not limited to, random access memory (RAM), read only memory (ROM), processor cache, or another type of dynamic storage device that may store information and machine-readable instructions that may be executed by a processor. For example, Synchronous DRAM (SDRAM), Double Data Rate (DDR), Rambus DRAM (RDRAM), Rambus RAM, etc. Computing device 100 may be a secondary storage device such as, but not limited to, a floppy disk, a hard disk, a CD-ROM, a DVD, a pen drive, a flash memory (e.g. USB flash drives or keys), a paper tape, an Iomega Zip drive, and the like. Computing device 100 may be a tertiary storage device such as, but not limited to, a tape library, an optical jukebox, and the like. In another example, computing device 100 may be a Direct Attached Storage (DAS) device, a Network Attached Storage (NAS) device, a tape drive, a magnetic tape drive, a data archival storage system, or a combination of these devices. In an example, computing device 100 may be a file storage system or file archive system.

[0015] In the example of FIG. 1 , computing device 100 may include a recipient module 102, a link module 104, a secure file deletion module 106, and a file system 108. In an example, the aforesaid components of computing device 100 may be implemented as machine-readable instructions stored on a machine-readable storage medium. The machine-readable storage medium storing such instructions may be integrated with the computing device 100, or it may be an external medium that may be accessible to the computing device 100. [0016] The term "module" may refer to a software component (machine readable instructions), a hardware component or a combination thereof. A module may include, by way of example, components, such as software components, processes, tasks, co-routines, functions, attributes, procedures, drivers, firmware, data, databases, data structures, Application Specific Integrated Circuits (ASIC) and other computing devices. A module may reside on a volatile or non-volatile storage medium and configured to interact with a processor of a computing device (e.g. 100).

[0017] In the example of FIG. 1 , recipient module 102 may receive a request to delete a data file from a file system. Such request may be received from a user of computing device (for example, 100) or it may be a system generated request. In an example, recipient module 102 may include a user interface to receive a request from a user to delete a file. Upon receipt of a request to delete a data file, the recipient module 102 may remove the file from its namespace. However, storage space occupied by the file on a storage medium is not deallocated. On the other hand, in an example, a flag may be set on the file to indicate that the file has been deleted, and the operation of erasure is pending. The file system (for example, 108) may be notified that the blocks of the file may not be released for further use unless they are overwritten by a specific number of times. In an example, such number may be specified by a user who initiates the file deletion request. In another example, the number may be system generated.

[0018] A user may specify the number of times a block of file may be overwritten before it is released at the time of providing a file deletion request for the file. In an example, a user may specify such number via a file attribute of the file. For instance, the file system (for example, 108) may be modified to support a new file attribute that may be referred to as "Secure delete". The file attribute may be defined to accept a value that specifies the number of times a block of file may be overwritten before it is released for further use. In an instance, a user may specify the value for a file at the time of providing a file deletion request for the file. In other words, a user may define a value for the "Secure delete" attribute of a file while deleting the file. In order to notify the file system that the block of this file should not be released unless it is overwritten a given number of times i.e. as specified by the "Secure delete" attribute, the reference count of the block may be incremented with a value corresponding to a value assigned to the attribute of the file. In other words,, the reference count of the block may be incremented with a value equal to the value assigned to the "Secure delete" attribute.

[0019] Further to removal of the file from its namespace, link module 104, which may be in communication with recipient module 102, may add a hard link of the file to a special directory. A hard link is the file system representation of a file by which more than one path references a single file in the same volume. In other words, a hard link may be defined as an additional name for an existing file. In other words,, a hard link is another name given to same data.

[0020] Link module 104 may add a hard link of the file for which a file deletion request is received to a special file directory. In an example, the file directory may be a hidden namespace (i.e. a hidden directory) that may be read through a file system utility. A hidden name space for the special directory, which may store the hard links for all those files that are requested to be deleted, prevents users from accidently overwriting files in this directory.

[0021] Once a hard link of the file, for which a file deletion request is received, is added to a special directory, secure file deletion module 106 may generate random data equal to block size of a block assigned to the file. Secure file deletion module 106 may then overwrite the block with randomly generated data. In an instance, secure file deletion module 106 may overwrite the block from the end of the file. After the block is overwritten, secure file deletion module 106 may decrement a reference count of the block by a single unit. As mentioned earlier, the reference count of the block was previously incremented with a value corresponding to a value assigned to the "Secure delete" attribute of the file. After the block is overwritten once, the reference count is decremented by a single unit. Secure file deletion module 106 may now determine whether the reference count of the block is zero. In other words, whether the reference count of the block has become zero after it was decremented. If it is determined that the reference count of the block is zero, secure deletion module 106 may release the block for further use by the file system. Also, in such case, secure file deletion module 106 may truncate the file and decrease the file size depending on the size of the block released. On the other hand, if it is determined that the reference count of the block is not zero, secure deletion module 106 may again generate random data equal to block size of the block, and overwrite the block with randomly generated data, whereafter the reference count of the block is decremented by a single unit. The aforesaid process may be repeated until the reference count of the block is zero.

[0022] In an example, decrementing of the block reference count may be done atomically with the communication of completed data flushing to a log. In an example, if the file system (for example, 108) is a journaling file system, all metadata changes related to a file may be logged in a journal so that they can be redone or undone in case of a system crash. With the feature of data consistency, all journal transactions (i.e. metadata changes) that require flushing of the data may write a special record in the journal indicating the completion of data flushing. In case a system crashes before this special record gets flushed to the disk, the metadata changes for this transaction are undone on system recovery. If the special record is seen in the log during post-crash recovery then that transaction is redone. Thus, in an example, decrementing of the reference count of file blocks is carried out in sync with writing of that special record. This ensures that blocks are released to the file system as and when their erasure gets completed.

[0023] Once the reference count of a block reaches zero, secure file deletion module 106 may determine whether size of the file (i.e. file size) is zero. In other words, a determination may be made whether file size of the file to be deleted has become zero due to truncation performed by the secure file deletion module 106 subsequent to the reference count of the block reaching zero. If it is determined that file size is zero, secure file deletion module 106 may delete the hard link of the file from the hidden directory. In other words, secure file deletion module 106 may erase or permanently delete the file from the computing device.

[0024] On the other hand, if it is determined that file size is not zero, secure file deletion module 106 may again generate random data equal to block size of the block, and overwrite the block with randomly generated data, whereafter the reference count of the block may be decremented by a single unit. The aforesaid process may be repeated until both the reference count of the block and the file size become zero.

[0025] The aforementioned determination of file size of the file to be deleted ensures that the process to securely delete the file continues even in case of a system failure or crash. In an example, since the file system (for example, 108) may be a journaling file system with data consistency, flushing of dirty kernel pages are ordered wherein first the data is flushed to disk, followed by the journal and then the metadata. This ordering ensures that files do not contain garbage data due to unflushed data buffers. In such type of file systems, the size of a file is a true indication of the amount of flushed data. Hence, after recovering from a system crash, secure file deletion module may determine the size of a file that is undergoing deletion and continue overwriting of data from thereon. Secure file deletion module may continue to do this until the value specified under the "Secure delete" attribute is satisfied (i.e. until the erasure cycle is complete), and the file is no longer visible in the special directory.

[0026] In an example, secure file deletion module 208 may be a user daemon process. Also, the user-space design of the secure file deletion module may allow random data generating algorithms to be changed based on user requirements, which does not require any change in the kernel.

[0027] In an example, file system 108 may be a journaling file system. Some non-limiting examples of a journaling file system may include New Technology File System (NTFS), Boot File System (BFS), ReiserFS, and Ext3.

[0028] FIG. 2 is a flow chart of an example method 200 for secure file deletion.

The method 200, which is described below, may be executed on a computing device such as computer system 100 of FIG. 1 . However, other computing systems may be used as well. At block 202, a request may be received for deleting a file. At block 204, a hard link of the file to be deleted may be added to a special directory. At block 206, a block assigned to the file overwritten with randomly generated data equal to size of the block. At block 208, a reference count of the block may be decremented by a single unit, wherein the reference count of the block was previously incremented with a value corresponding to a value assigned to an attribute of the file. At block 210, a determination may be made whether the reference count of the block is zero. At block 212, if the reference count of the block is zero, the block may be released for further use. At block 214, a determination may be made whether file size of the file is zero. At block 216, if the file size of the file is zero, the hard link of the file may be deleted from the special directory. The aforementioned example method allows releasing of data blocks to the file system as and when they get erased, rather than waiting for the whole file to get erased.

[0029] FIG. 3 is a block diagram of an example system 300 for secure file deletion. System 300 includes a processor 302 and a machine-readable storage medium 304 communicatively coupled through a system bus. Processor 302 may be any type of Central Processing Unit (CPU), microprocessor, or processing logic that interprets and executes machine- readable instructions stored in machine-readable storage medium 304. Machine-readable storage medium 304 may be a random access memory (RAM) or another type of dynamic storage device that may store information and machine-readable instructions that may be executed by processor 302. For example, machine-readable storage medium 304 may be Synchronous DRAM (SDRAM), Double Data Rate (DDR), Rambus DRAM (RDRAM), Rambus RAM, etc. or storage memory media such as a floppy disk, a hard disk, a CD-ROM, a DVD, a pen drive, and the like. In an example, machine- readable storage medium 304 may be a non-transitory machine-readable medium. In an example, machine-readable storage medium 304 may be remote but accessible to system 300. 30] Machine-readable storage medium 304 may store instructions 306, 308, 310, 312, 314, 316, 318, 320, 322, and 324. In an example, instructions 306 may be executed by processor 302 to assign a value to an attribute of a file, wherein the value assigned to the attribute of the file defines number of times a block assigned to the file is to be overwritten before it is released for further use. Instructions 308 may be executed by processor 302 to increment a reference count of the block with a value corresponding to the value assigned to the attribute of the file. Instructions 310 may be executed by processor 302 to receive a request for deleting the file. Instructions 312 may be executed by processor 302 to add a hard link of the file to a special directory. Instructions 314 may be executed by processor 302 to overwrite a block assigned to the file with randomly generated data equal to size of the block. Instructions 316 may be executed by processor 302 to decrement the reference count of the block by a unit. Instructions 318 may be executed by processor 302 to determine if the reference count of the block is zero. Instructions 320 may be executed by processor 302 to release the block for further use if the reference count of the block is zero. Instructions 322 may be executed by processor 302 to determine if file size of the file is zero. Instructions 324 may be executed by processor 302 to delete the hard link of the file from the special directory if the file size of the file is zero. [0031] For the purpose of simplicity of explanation, the example method of FIG. 2 is shown as executing serially, however it is to be understood and appreciated that the present and other examples are not limited by the illustrated order. The example systems of FIGS. 1 , and 3, and method of FIG. 2 may be implemented in the form of a computer program product including computer-executable instructions, such as program code, which may be run on any suitable computing device in conjunction with a suitable operating system (for example, Microsoft Windows, Linux, UNIX, and the like). Embodiments within the scope of the present solution may also include program products comprising non-transitory computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, such computer-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM, magnetic disk storage or other storage devices, or any other medium which can be used to carry or store desired program code in the form of computer-executable instructions and which can be accessed by a general purpose or special purpose computer. The computer readable instructions can also be accessed from memory and executed by a processor.

[0032] It should be understood that the above-described examples of the present solution is for the purpose of illustration only. Although the solution has been described in conjunction with a specific embodiment thereof, numerous modifications may be possible without materially departing from the teachings and advantages of the subject matter described herein. Other substitutions, modifications and changes may be made without departing from the spirit of the present solution. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Claims

Claims:

1 . A method of secure file deletion, comprising:

receiving a request for deleting a file;

adding a hard link of the file to a special directory;

overwriting a block assigned to the file with randomly generated data equal to size of the block;

decrementing a reference count of the block by a single unit, wherein the reference count of the block is previously incremented with a value corresponding to a value assigned to an attribute of the file;

determining if the reference count of the block is zero;

if the reference count of the block is zero, releasing the block for further use;

determining if file size of the file is zero; and

if the file size of the file is zero, deleting the hard link of the file from the special directory.

2. The method of claim 1 , wherein the value assigned to the attribute of the file defines number of times a block assigned to the file is to be overwritten before it is released for further use.

3. The method of claim 1 , wherein the block assigned to the file is overwritten from end of the file.

4. The method of claim 1 , further comprising deleting file namespace of the file upon receiving the request for deleting the file.

5. The method of claim 1 , further comprising, if the reference count of the block is not zero, repeating overwriting of the block assigned to the file with randomly generated data equal to size of the block, and decrementing the reference count of the block by a single unit after each overwriting, until the reference count of the block is zero.

6. The method of claim 1 , further comprising assigning the value to the attribute of the file, wherein the value assigned to the attribute of the file defines number of times a block assigned to the file is to be overwritten before it is released for further use.

7. A system for secure file deletion, comprising:

a recipient module to receive a request to delete a file from a file system; a link module to add a hard link of the file to a hidden directory; and a secure file deletion module to:

overwrite a block assigned to the file with randomly generated data equal to size of the block;

decrement a reference count of the block by a single unit, wherein the reference count of the block is previously incremented with a value corresponding to a value assigned to an attribute of the file;

determine if the reference count of the block is zero;

if the reference count of the block is zero, release the block for further use;

determine if file size of the file is zero; and

if the file size of the file is zero, delete the hard link of the file from the hidden directory.

8. The system of claim 7, further comprising a user interface to receive the value assigned to the attribute of the file from a user.

9. The system of claim 7, wherein the secure file deletion module to, if the reference count of the block is not zero, repeat overwrite of the block assigned to the file with randomly generated data equal to size of the block, and decrement the reference count of the block by a single unit after each overwrite, until the reference count of the block is zero.

10. The system of claim 7, wherein the secure file deletion module is a user space daemon.

1 1 . A non-transitory machine-readable storage medium comprising instructions for secure file deletion, the instructions executable by a processor to:

assign a value to an attribute of a file, wherein the value assigned to the attribute of the file defines number of times a block assigned to the file is to be overwritten before it is released for further use;

increment a reference count of the block with a value corresponding to the value assigned to the attribute of the file;

receive a request for deleting the file;

add a hard link of the file to a special directory;

decrement the reference count of the block by a unit;

determine if the reference count of the block is zero;

if the reference count of the block is zero, release the block for further use;

determine if file size of the file is zero; and

if the file size of the file is zero, delete the hard link of the file from the special directory.

12. The storage medium of claim 1 1 , wherein the reference count of the block is decremented by a single unit upon determination that file data of the file is completely flushed to a disk consequent to overwrite of the block assigned to the file with the randomly generated data.

13. The storage medium of claim 1 1 , wherein the determination is made by analyzing a special record created in a journal of the file system consequent to overwrite of the block assigned to the file with the randomly generated data.

14. The storage medium of claim 1 1 , wherein the directory is a hidden namespace.

15. The storage medium of claim 1 1 , wherein the block assigned to the file is overwritten from end of the file.