Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Secure delete files—an alternative?

I'm aware that using secure delete from the command line doesn't work with solid state drives (SSDs), and that an alternative is to use FileVault to encrypt data on the disk. However, that is still flawed as if someone gets hold of the password they can decrypt the data. And given advances in computing power, it may only be a few years before a brute force attack will succeed in a relatively short time even for passwords of 10 or 12 characters.


An alternative is to force the SSD to overwrite the entire free space on the disk by filling it with random data. This might be achieved by starting with a random image (JPEG, TIFF, whatever) with zero useful information (maybe a random image of sky and clouds), then encrypting it (ZIP would do) with a random password. Multiple versions of random different sizes with random different passwords (maybe 20 characters) could be created, so unlocking one file wouldn't give the hacker access to any others. It would take a very, very long time to decrypt all the files to find zero information.


Is this an effective "secure delete" option? Is it possible to read previously written data from an SSD if it's genuinely been written over? Does this leave an obvious trail of deleted data? Would it be better to write all zeros or 1s? Or forget about the whole encryption thing and just fill the disc with 0xff?


PS

The secure delete srm command (which overwrote data up to 32 times) has been removed in the latest versions of Mac OS, but there is rm -P which overwrites data 3 times. But of course it's only effective on HDDs, not SSDs.

Posted on Aug 17, 2018 11:12 PM

Reply
Question marked as Top-ranking reply

Posted on Aug 18, 2018 9:09 PM

If you have truly sensitive data that must never be found after it is erased, then melt down the SSD or the Hard Disk.


With both SSDs and Hard Disks, if a sector goes bad, the device will logically replace the sector with a spare and the replaced sector will contain its original values. Hence the need to totally destroy the device if the data must never be uncovered after deletion.


With respect to SSDs. Think of an SSD organized as a case of egg cartons, where each carton holds a dozen (12) eggs. When you write sector the data is put into an empty egg slot (eg. #22). When you re-write that sector, the data is put into a different egg slot (eg #153), logical sector mapping information is updated but the original data is still sitting in the previous egg slot (#22) which is not accessible via normal disk access tools, but is accessible to the right kind of tools that knows how to take to the SSD at the device interface level.


The SSD can ONLY pre-clear an entire egg carton, so until slots #13-24 are all no longer holding current data, #22 is going to hang around.


SSDs also contains lots of spares. When you decided to zero all free space, the SSD may just use its spares to provide the logical sectors and still leave #22 holding old data.


If the SSD has lots and lots of little holes, like #22, then it may decide to copy out #13-21 and #23-24 to somewhere else, then pre-clear the egg carton holding #22. At that point in time, #22 will be gone. Until the SSD decides that the egg carton holding #22 is going to be pre-cleared, #22 and its old data is going to remain.


So if you do not want anyone to find the old data in #22 you totally destroy the SSD.


Another approach that you are not going to like, as you feel encryption can be cracked, is to create an encrypted disk image, put the sensitive data into the encrypted disk image. Mount the encrypted disk image, enter the decryption password, then use that sensitive data. When you no longer want that sensitive data, throw away the password, and delete the disk image. The disk image will not have the same encryption key as FileVault, and when you destroy the password, it can only be cracked with expensive computing power.


But if you do not trust that, melt down your SSD. Open it up, take a blowtorch to it, and melt it into slag.

Similar questions

3 replies
Sort By: 
Question marked as Top-ranking reply

Aug 18, 2018 9:09 PM in response to ozRob

If you have truly sensitive data that must never be found after it is erased, then melt down the SSD or the Hard Disk.


With both SSDs and Hard Disks, if a sector goes bad, the device will logically replace the sector with a spare and the replaced sector will contain its original values. Hence the need to totally destroy the device if the data must never be uncovered after deletion.


With respect to SSDs. Think of an SSD organized as a case of egg cartons, where each carton holds a dozen (12) eggs. When you write sector the data is put into an empty egg slot (eg. #22). When you re-write that sector, the data is put into a different egg slot (eg #153), logical sector mapping information is updated but the original data is still sitting in the previous egg slot (#22) which is not accessible via normal disk access tools, but is accessible to the right kind of tools that knows how to take to the SSD at the device interface level.


The SSD can ONLY pre-clear an entire egg carton, so until slots #13-24 are all no longer holding current data, #22 is going to hang around.


SSDs also contains lots of spares. When you decided to zero all free space, the SSD may just use its spares to provide the logical sectors and still leave #22 holding old data.


If the SSD has lots and lots of little holes, like #22, then it may decide to copy out #13-21 and #23-24 to somewhere else, then pre-clear the egg carton holding #22. At that point in time, #22 will be gone. Until the SSD decides that the egg carton holding #22 is going to be pre-cleared, #22 and its old data is going to remain.


So if you do not want anyone to find the old data in #22 you totally destroy the SSD.


Another approach that you are not going to like, as you feel encryption can be cracked, is to create an encrypted disk image, put the sensitive data into the encrypted disk image. Mount the encrypted disk image, enter the decryption password, then use that sensitive data. When you no longer want that sensitive data, throw away the password, and delete the disk image. The disk image will not have the same encryption key as FileVault, and when you destroy the password, it can only be cracked with expensive computing power.


But if you do not trust that, melt down your SSD. Open it up, take a blowtorch to it, and melt it into slag.

Reply

Secure delete files—an alternative?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.