Secure file erase

[netmaestro]

Thanks for all the good help. I think I have a pretty fair handle on how safe it is now, which is: probably not $100% foolproof but safe enough for my purposes. "Software safe" is all I really need.

[Rescator]

For general use, probably yeah. Testing against popular recovery software might be worth considering too.


When it comes to specialized hardware recovery it's a different story,
as said in the posts above all they need to do is read the data that is there (i.e all 0's or maybe some other file stored tin that location).

They read that normally, then they read again but filtering out the known data, what they see now is either fragments of older data or the previous data.

Commercial facilities (that rescues burned or damage drives and their content) are able to filter down through the magnetic residue.

Remember old cassette or VHS tapes? Remember how when you had re-recorder over them many times the image gets really bad or the sound really muddy?
That is magnetic residue from previous recordings mixed in with the new recording that you hear/see.

HD's and Floppy's use the same way to store data as tapes.

Rewritable CD's and DVD's are probably less prone to this though, although I suspect that it's possible with proper laser calibration and equipment to retrieve parts of what was overwritten.

Ditto for ram as mentioned, and thus SSD's are probably subject to similar possibilities.

The only solution to truly safely destroy data is to store it on disposable media and destroy that when you are done with it.

But as I said earlier, encryption is a nice advantage.
Even if the data can be retried if it has been overwritten, as long as they can not understand what it is they can't use it. Unless you are forced to disclose how/what encryption/which password was used to encrypt the data you deleted/erased.

so if the data is so sensitive, make sure that you never stored it on disk in plaintext to begin with, make sure it's always stored in encrypted form, only decrypt in memory etc.) There are WinAPI's that ensures that the memory you use is actually in memory and not in the page file etc. Especially for use with encryption.

[thefool]

Be sure to state in the license agreement that you cannot be sued if it CAN be restored

[SFSxOI]

Ditto for ram as mentioned, and thus SSD's are probably subject to similar possibilities.

The only solution to truly safely destroy data is to store it on disposable media and destroy that when you are done with it.

SSD's are worse for security in their current infancy. If the power is removed while an SSD is writing, in some cases, complete latent images can be left in locked areas which you will not be able to access at all to remove. If the SSD contains sensitive material the only hope to ensure the material is destroyed is to destroy the drive. If anyone is considering an SSD for sensitive work that needs to stay sensitive you need to make sure that you have a UPS on the system so that power can remain applied in the event of a power outage to let you shut down properly. I'd wait a few more years before i'd move to SSD's if your doing sensitive work so the technology has a little more time to mature.

[Trond]

If it is sensitive data, why is stored on the disk without encryption anyways?

[Thorium]

I'd wait a few more yesr before i'd move to SSD's if your doing sensitive work so the technology has a little more time to mature.

The problem on SSD's is not the power. It's that the location of a write is not the location of the original data. SSD-Chips are full of old data. And there is no reliable way to delete it. Maybe the internal controller will get a function for save deleting in the future. But overwriting it, does not work, because you are actualy not overwriting the data. It will be written to another chip.

It's called: wear levelling

[SFSxOI]

If it is sensitive data, why is stored on the disk without encryption anyways?

Its a good question, a fair question. One simple answer is encryption doesn't secure sensitive data. WHAT! thats right, encryption alone doesn't secure sensitive data. All encryption does is keep prying eyes away for short periods of time, but the data is no more secure then without encryption. The important elements needed to back up encryption are controlling access to the data in the very first place, ensuring the integrity of the system or transport method used, and ensuring the truthworthiness of the people that acces it, and protecting the data asset.

There are four levels of security, the four D's we un-officially call them in the Information Security field, these are detect - deny - deter - defend. In all of those, encryption is one of the weakest links and can't really help secure sensitive data unless all four are in place. So simply encrypting data on a disk and leaving it at that really doesn't matter.

[Rescator]

Good points both Trond and SFSxOI.

Hmm. where does (hardware) encryption drives fall into all this?
You know, those drives that encrypts at some point during the transmission to the disk.

[SFSxOI]

Good points both Trond and SFSxOI.

Hmm. where does (hardware) encryption drives fall into all this?
You know, those drives that encrypts at some point during the transmission to the disk.

Encryption is encryption is encryption, oh yeah, there is encryption in different flavors...thats about it. If it goes to disk and all thats protecting it is encryption then see my post above yours. Hardware encryption is just another flavor of encryption that falls into the transport category. For us mere mortals, actually, a single point encryption mechanism is more secure then a multipoint mechanism (hardware encryption is multipoint). As the number of points in a transport mechanism increases so does the likelyhood of intercepting the data being transfered along that transport route. The encryption schemes we see mostly used generally fall into what could be called a "casual" category in which the real intention is not for long term but instead for very short term. An example of a single point encryption would be encrypting at the moment of creation, not as its written to disk. This is so its encrypted as it enters the transport (on its way to the disk) system and not after or during transport. In this way it would be less likely to recover un-encrypted data by intercepting along the transport route. This is because there is a weak point between creation and when its encrypted in the hardware or on disk, in that weak point the data is still "in the clear" if you will.

A better method of encryption is to encrypt at the moment of creation so that as it enters the transport mechanism its encrypted with one key and then encrypted again in the transport mechanism with a different key, and then re-encrypted yet again with another different key as its sent to the drive. And so on and so forth. This type of encryption scheme is difficult and expensive to implement and is generally not available to mere mortal humans, being in the rhelm of the likes of the National Security Agency (NSA), or CIA, or FBI, or DoD, or other governments similar functions. Although the number of transport points has increased so has the number of keys which mitigates the weaknesses of the transport points so that at any point in the transport multiple keys are needed and the likley hood of having all the keys needed at any transport point decreases for an adversary. Even this system needs to be backed up by the four D's., which is why in most secure systems the drives are removed at the end of the work day and secured in a vault or safe in a secured area.

All this is still just dealing with the computer its self, wait until you get to the network or internet part as you ain't seen nothing yet and the encryption used at the computer just for the data its self becomes useless. Although the basics still apply, in the network or internet (which is just one big network basically) its a whole new ball game.

[talisman]

Mind you, some "hardware encryption" enabled devices actually don't encrypt a thing. It's what you understand under encryption. Some devices apply binary data obfuscation with a salt and decrypt the obfuscated data with the hardware stored salt key on the fly (very expensive and resource consuming) while others simply use a simple password authentication in hardware level to allow or disallow access to stored data (extremely inexpensive yet not safe enough).

[Rescator]

Yeah! And the fact that keyboard and mouse input is not secured. (can be intercepted/read).

[thanos]

Would this code wipe a file safely? Can I be sure the written bytes are going exactly where the existing bytes are? Help is appreciated.

Code: Select all

If OpenFile(0, filename$)
  For i = 1 To 7
    FileSeek(0,0)
    For j= 1 To Lof(0)
      WriteByte(0,0)
    Next
  Next
  CloseFile(0)
  DeleteFile(filename$)
EndIf

Just a suggestion.
I think that is better to close and reopen the file in every pass, to commit any temporary buffer to disk.
After all passes delete the file and create a new file with the same file name and delete again the new file.

Code: Select all

  For i = 1 To 7
    If OpenFile(0, filename$)
        FileSeek(0,0)
       For j= 1 To Lof(0)
          WriteByte(0,0)
       Next
      CloseFile(0)
    Endif
  Next
  DeleteFile(filename$)
  Createfile(0, filename$)
  WriteByte(0,0)
  CloseFile(0)
  DeleteFile(filename$)

[Thorium]

You also can youse FlushFileBuffers instead of closing and reopening the file.

[utopiomania]

I think this code is a very secure erase. If the HD unlinks a block it is unavailable to the OS so no one can see it. Besides it is fairly unlikely that this happens. If you overwrite each byte nine times, the original data is gone.

[Thorium]

I think this code is a very secure erase. If the HD unlinks a block it is unavailable to the OS so no one can see it. Besides it is fairly unlikely that this happens. If you overwrite each byte nine times, the original data is gone.

Well, not on SSD's. ^^