Catalina 10.15.7
Drive: Samsung Portable T7 2TB SSD external drive used for backup
Hello,
The drive is defective (intermittent drive access problems unable to resolve) but I can still access the content. The problem is intermittent. At this point I am no longer interested in troubleshooting the problem. It is not worth the risk of not being able to access the data in the future.
It is still under warranty. I can exchange it for a new one, but is contains sensitive client account information. What would be the most secure way of erasing the drive ?. Or is it best to be on the safe side, and just accept the loss and buy a new one.
I am open to installing an app for that purpose if necessary.
I suspect that this is a common issue.
thanks very much in advance for your time and help !
If the drive was formatted encrypted, throwing away the encryption key (the password you set when formatting) is good enough to securely erase the data. This is the “cryptographic erase”.
If you did not format it as encrypted, you could try adding that encryption now. Once the entire disk is encrypted, that will allow you to “securely erase” it by again throwing away the encryption key. To encrypt an APFS drive that was not formatted as encrypted, attach the drive to your Mac, in the Finder right-click its icon, and chose Encrypt. A while back I was attempting to confirm if that encrypted the entire drive or just the present contents, but I’m afraid that question is still open. The answer to that question determines if you should be worried about items that you once had on the drive that have been deleted (but not overwritten), from remaining unencrypted on the drive or not. Depends on your level of paranoia how much effort you want to put into this.
Finally, you can always use Disk Utility to perform a multi-pass secure erase by writing zeros or random data to the SSD. On SSDs this is commonly not recommended because SSDs have finite write cycles and because their wear leveling makes it difficult to perform this operation correctly. However, that said, since this is a drive that is likely destined for the garbage, you don’t have to worry about write cycles and instead this is likely more about peace of mind. In that case, all you need is time. A 3-pass (DOE standard) or 7-pass (DOD standard) secure erase of a 2TB drive will likely take all night. Best to just let it do its thing while you sleep. But again, don’t forget the drive’s wear leveling can (and likely will) interfere with what you’re trying to achieve here. So again, best is likely to encrypt and otherwise…
If this is very sensitive data and you can’t rely on throwing away encryption keys, you would probably want to physically destruct the SSD. Not just the disk, but the actual flash chips. There are shredders that will do that and there are companies that have equipment to do this for you. Of course, I suspect if you destroy the drive you won’t be able to get a refund so the question really becomes how paranoid do you want to be or rather, is securely getting rid of this sensitive data worth more or less than what you expect to receive from returning a defective drive.
Me personally, I usually just use the cryptographic erase and live happily ever after. :)
Apologies. I keep forgetting they removed this from Disk Utility’s GUI (likely for the reasons I mentioned above).
In a shell, it’s very simple.
Run
diskutil list
to get the identifier of the disk you want to erase. Typically, something like disk0s2. Then you can do something like
diskutil secureErase 4 disk0s1
where the identifier at the end needs to match what you got from running the first command. The 4 I used in this example is for a DOE-compliant 3 pass. If you run
man diskutil
and scroll down, you’ll see all present secure options. These are showing for me here:
0 - Single-pass zero fill erase.
1 - Single-pass random fill erase.
2 - Seven-pass erase, consisting of zero fills and all-ones fills plus a final random fill.
3 - Gutmann algorithm 35-pass erase.
4 - Three-pass erase, consisting of two random fills plus a final zero fill.
There’s also a caution message to alert you to the wear leveling issue, reminding you that this might not achieve 100% of what you’re setting out to do and that cryptographic erase is nowadays considered the proper way to go.
As others have said, it depends on how sensitive the data is and how likely you think the recipient (in this case, Samsung) is going to go to extraordinary measures to recover data from a drive sent to them for warranty replacement.
If your drive was encrypted (and if you were using it for customer data, hopefully it was - since you should be concerned about the drive getting lost or stolen), then as others have said, just throw away the key and the data will be unrecoverable.
If that is not an option…
If you just write zeros or random data to every block (a simple one-pass erase), your data will be inaccessible over its USB interface. This is probably good enough for most people. The data may not immediately be erased from the flash chips, but you will need to bypass the SSD controller chip to read that “garbage” data.
If you are concerned that someone might bypass the SSD controller chip (e.g. directly accessing the flash chips or by installing custom firmware into the drive), then you want to find a way to make sure the flash chips have actually been erased or overwritten. There’s no guarantee, but here are some possibilities:
If the drive supports TRIM (it may not - this isn’t common for USB drives), then reformatting the drive will cause macOS to use TRIM to mark all the blocks as garbage. This will make the data immediately inaccessible. The chips themselves will get erased at some unspecified time in the future as a part of the SSD controller’s “garbage collection” process.
If the drive doesn’t support TRIM, a one-pass erase will do the same thing, but take longer. After writing zeros or random data to every block, any original data remaining in the flash chips will be marked as garbage and will eventually be collected.
Unfortunately, there’s no way to know how long it will take for garbage collection to take place. Every SSD controller chip has its own algorithm. In general, it takes place during idle time, so if you connect the drive to a computer and unmount it (so it will be completely idle), and leave it this way for a long time (people have suggested a day or two), that will probably do it. But there are no guarantees unless you can find some document from the manufacturer.
SATA drives have a “secure erase” command. I don’t know if there is an equivelent for USB or NVMe drives. This command, if it is implemented correctly, is supposed to explicitly wipe the underlying flash chips. The problem is that not all drives support this command and some that seem to have support don’t implement it properly. So it shouldn’t be considered reliable unless you have solid information about your particular make/model SSD.
If you perform a multi-pass erase, it is more likely that garbage will be collected before the process completes. This is because as blocks are written and free blocks get consumed, the controller will be forced to collect garbage (at least somewhat) in order to allow the writes to complete. But keep in mind:
This will take a long time. When garbage collection is forced as a result of running out of free blocks, it will dramatically slow down drive performance.
If you write regular patterns (e.g. all-ones or all-zeros), the controller may try to outsmart you and just mark the blocks as garbage, or use some kind of deduplication logic to avoid consuming all the free blocks. So you probably want all passes to write random data.
There’s still no guarantee that every block of garbage will be collected during this process. But with enough passes of random data, it will be likely.
Ultimately, it comes down to what others have said - you must decide how sensitive the data is and how unlikely a scenario must be before you decide it’s not important. Depending on your situation, you may conclude that it is better to just physically destroy the drive and forget a warranty replacement.
Something that has been nagging at me too. Encryption can seem too fast for that on a relatively empty drive? Maybe I just don’t understand the mechanism?
I’m not sure that’s the right test though. The SSD controller after all knows these cells have not yet been written to and it doesn’t include them in its list of garbage collection blocks. I’d think to make such a test more meaningful, you’d first have to write random data to all cells of the drive, then delete them all (or format the disk), and then see if encryption is still similarly fast, or if now it takes substantially longer indicating that even cells left to be overwritten are being included in disk encryption.
Because nobody seems to have a solid answer to what should be a fairly straightforward question, I’ve been meaning to carry out that test myself for quite a while already, but I just haven’t found the time. Or the disk in fact. The last three 2GB drives I got my hands on (970 EVO, nice drives), got commandeered by our new postdocs who were filling up their scratch disks with new sim data a whole lot faster than they (and admittedly, I) anticipated.
For the data part of the drive, I greatly appreciate your explanation about cryptogenic erase.
You seem to make a distinction between “data” and “free space” on an SSD.
If we take the example of an accountant with client files on a non encrypted SSD. The SSD appears to contain client files (data) and empty (free) space. In reality, isn’t the free space full of confidential client files which were previously deleted (simple delete ie sent to trash) for one reason or another, and also need to be protected before giving the drive to a 3rd party?.
There is probably something that I don’t understand.
That’s exactly my concern. I would like to confirm that the entire disk gets encrypted, not just the used blocks. And the simple reason is indeed of course that “free space” or “empty space” contains data (eg. stuff you’ve deleted in the past) that at least at the block level in principle could otherwise be read out. This is likely not a concern for most regular users, but if somebody has critical PII and they are required to ensure that data can’t be read out even by forensic analysis (i.e. including things like bypassing the controller), they would need to rely on the entire disk being encrypted, not just the currently used blocks.
Sorry for having misunderstood your previous explanations. I will now re-read your posts with this in mind. thank you VERY much for your patience. You give excellent explanations
When you move a file to the trash, it has not been deleted at all. It has simply been moved to a folder and it can later be moved elsewhere.
When you empty the trash, then it is actually deleted from the underlying file system. What this actually means, however, depends on your storage device and the operating system.
Most operating systems simply delete the file’s directory entry and mark the file’s blocks as free.
The free blocks will eventually be overwritten by data from new files, but that might not happen for a long time, depending on the operating system and its file system device drivers. Until the blocks are overwritten, software with knowledge about the file system can find them and access the data. This is how “undelete” utilities work.
If the device is an SSD, and it supports TRIM and the operating system is also supporting TRIM on the device, then after the file is deleted, the operating system will send TRIM commands to the SSD.
This will immediately mark the file’s blocks as “garbage”. Software trying to read those blocks through any normal means will get back all-zeros, but the data remains stored in the underlying flash chips until the SSD controller performs “garbage collection”, which might not happen for quite some time (see my earlier posts on the subject).
Some operating systems may provide a “secure delete” command. For example, older releases of macOS included an srm command, which will overwrite the file’s data before deleting it. This is what the (no longer part of macOS) “secure erase trash” command did.
This kind of secure erase works great for hard drives where there is (mostly) a direct correspondence between the logical blocks used by software and the physical blocks managed by the media.
It is less useful on SSDs because the SSD controller’s wear-leveling logic will cause the overwrite-data to be stored in different physical locations on the flash chips, leaving the original file’s content marked as garbage, and will remain stored in the chips until garbage collection takes place.
Keeping all this in mind, now it should be easier to understand @Simon’s comment about encrypting free space.
If you have files that were simply deleted (meaning the blocks have not been TRIMmed or overwritten), and the encryption process does not encrypt unused disk blocks, then software can read the free space and undelete the files.
If the files were overwritten or TRIMmed as a part of the deletion process, then it doesn’t matter if the encryption process encrypts free space, because the free space doesn’t have the deleted file data (although it may still remain in an SSD’s flash chips until garbage collection runs).
The encryption process might also explicitly wipe free space. It may do this quickly using TRIM or (if that’s not possible) more slowly by overwriting the blocks. This is functionally equivalent to wiping the space before encryption.
In all three cases, however, if you’re using an SSD, the deleted file data will remain in the flash chips until the garbage collection process erases those locations. Someone able to bypass the SSD controller (direct access to the flash chips or hacked SSD controller firmware) before garbage collection takes place could theoretically access the data.
This is why it is recommended that you enable encryption before you copy the first sensitive file to the device. This way there won’t be a plaintext version of the file anywhere in the flash memory, even in the garbage space.
As always, whether this is important for you depends greatly on how sensitive the data is. For myself and my data, I would probably just erase the device (either with TRIM or a one-pass overwrite) and then leave it connected-but-unmounted for a few days to make sure garbage collection has plenty of time to run. Will it be perfect? Maybe not. But I think it will be good enough for my data.
But I believe these days this is becoming common knowledge. Nevertheless, many people will still have drives (or systems) left from times when it wasn’t common practice to do this. It’s bad enough this depends on drive type and/or OS, in order to better understand what the best course of action is for such drives, it would be most valuable to learn exactly how drive encryption has been implemented on APFS.
