Secure File Deletion

[Worm87]

I have been trying to find different Linux embedded RT utilities that I can use to securely delete files after they are encrypted.  I prefer to use bleachbit but when I try to install it says there is not python-gtk2 >= 2.14 installed even though I have python 2.7 installed.  Anyone know of how to get bleachbit installed or other programs that will perform a secure delete on files?  I know of the dd command but it is very slow for the size of storage I am using.

[BradM]

Hi Worm87,

A word of caution: both x86_64 and ARM-based NI Linux RT controllers use some sort of wear leveling technology (a storage device with a hardware FTL in the case of x86_64 controllers, UBI + UBIFS in the case of ARM controllers). Under such situations, the traditional secure-erase approaches don't assure actual secure erases anymore, rather you need to securely wipe the entire storage media. External USB flash storage also uses HW FTLs and suffers the same problem.

That said, there is the old standby shred. This utility is part of the coreutils package that is installable through opkg, but be sure that you consider what was stated above (namely that old secure erasing depended on proper block devices serving as the storage media).

Can you explain a bit more as to why you need to securely erase an encrypted file? Is this to prevent offline bruteforce attempts? Or are you wanting to delete the unencrypted copy of a file after you've encrypted it? A bit more details on your use-case may help answer your question appropriately.

[Worm87]

Hey Brad,

I am writing a file that is unencrypted.  Once it is encrypted in a 7zip archive I want to securely delete the unencrypted file.  This is a project requirement that we encrypt the data but the other VIs I have found to encrypt are not truly to Standard.  I have looked at doing a Virtual Hard Drive but there are complications with the commands to remake the file system where it needs superuser status.  With all the steps to do this it is more complicated then I want it to be from the sense of management

[BradM · Accepted solution]

Thanks for the additional details.

With this information, you could take advantage of an already-available ramdisk: /tmp (which is actually symlinked to /var/volatile/tmp).

lvuser (the user account that LVRT runs as) has write access to that area of the filesystem, it's a ramdisk (meaning the contents will disappear on reboot/power off). Depending on the requirements of your application, this may be sufficient. If you need more assurance, you can use the afore-mentioned shred to make sure that the RAM that is being used to store the unencrypted file contents is sufficiently unrecoverable to another process which has/gains root-level privileges on the system (and can then access all of system memory).

Of course, this is all dependent on the unencrypted file being able to fit in the ramdisk. How large are the file(s) that need to be encrypted?