Re: Secure Delete for Mac

[Tim Doty <tdoty () MST EDU>]

The issue with SSD has been partially explained, but to be clear an SSD 
works entirely differently from a spinning platter and brings entirely 
different issues to the problem of data elimination and data recovery. 
Wear leveling is only part of the picture, it really has to do with the 
specifics of the implementation (such as zeroing applying to a whole 
page while writes are always a pattern of ones and can apply to a single 
sector, and the logical addressing being dynamic instead of static and 
constantly in flux).

Spinning platter/data elimination: a single overwrite is all that is 
needed unless you are using a floppy drive or an MFM/RLL hard drive. It 
doesn't matter what it is overwritten with, zeros works just fine.

Spinning platter/data recovery: files that have been deleted, but not 
wiped, are generally recoverable with, e.g., photorec. "Deleted" data in 
most file systems is just marked as "unused" and overwritten only when 
the space is re-allocated.

SSD/data elimination: this is hard, gets more than a little technical 
and "version" makes no real difference. At its core, the issue is that 
overwritten data becomes inaccessible but is not immediately overwritten 
(logical block addressing is updated). It doesn't really matter if you 
overwrite it once or thirty five* times (you really don't know what 
exactly the drive firmware is going to do). The best solution is to use 
whole disk encryption.

SSD/data recovery: this was always iffy, though in the past a direct 
dump of the chips could be used to get at the raw data, including stale 
data no longer accessible through the SATA interface, and with some 
effort the drive contents reconstructed. However, due to "housekeeping" 
done by the firmware behind the scenes data just kind of silently 
evaporates. And now with a drive and operating system that support TRIM 
simply deleting a file is /likely/ to make any recovery impossible.

In short, with SSD it is more difficult to assure data elimination and 
it is *also* more difficult to perform data recovery.

Note: in the above it was assumed that a specific file is being singled 
out for elimination as that is how the original post read. For data 
elimination of a whole disk the most robust wiping method is ATA secure 
erase, though the success of the operation should be verified. 
Especially with SSDs. The only study I'm aware of found that some SSDs 
failed to do /anything/ when secure erase was evoked. The best solution 
is to use whole disk encryption (and do /not/ trust a self-encrypting 
drive without first validating it -- some of these have been found 
lacking as well -- so the best general advice is to use a 3rd party 
solution such as Apple's vault).

Tim Doty


* 35 is a faux number from MFM/RLL drives, never meant anything, and is 
utterly meaningless on any drive made in the last few decades.

On 10/16/2018 03:11 PM, Frank Barton wrote:
> Zachary, thank you for that additional information.
>
> Chad, What is the end goal of what you are trying to accomplish? what 
> "attack" are you trying to prevent?
>
> If you're trying to prevent someone from pulling the drive and reading 
> deleted data, why not encrypt the drive? If you're trying to prevent the 
> user on the computer from accessing this data any longer, I would think 
> that that falls more into an "HR" type of problem where you don't trust 
> your users.
> If you are decommissioning the computer, and getting it ready to be 
> disposed of, destroy the drive; donated: secure wipe the entire drive 
> (and there are tools for that that are agnostic of the OS installed on 
> the drive), and then either donate with a blank drive, or a fresh 
> "vanilla" image
>
> Frank
>
> On Tue, Oct 16, 2018 at 4:00 PM Zachary Yamada 
> <zachary.yamada () chemeketa edu <mailto:zachary.yamada () chemeketa edu>> wrote:
>
>     I have to second Frank Barton's statement. Not only will using rm
>     -P, srm, or shred increase the wear and tear on an SSD, but it's not
>     as effective on on a modern SSD as it would be on a first-gen SSD or
>     traditional spinning disk. It's my understanding that most modern
>     SSDs use "wear-leveling" which results in writes to consistent files
>     or inodes being written to different locations on-chip. So, even if
>     you are overwriting a file on your system the physical location on
>     the SSD where the new data is being written to will be different
>     from the location of the data which is being overwritten from the OS
>     perspective. The silver lining here is that TRIM-enabled SSDs should
>     automatically clear data that has been "overwritten" by data written
>     to a different section of the SSD's memory.
>
>     On top of this, I would like to caution everyone in this thread on
>     trusting utilities such as rm (with the -P flag), srm, and shred
>     when used on operating systems with a journaled file system (such as
>     those used by default in OSX and most modern Linux distributions).
>     In fact, the documentation for both srm and shred provide warnings
>     in regards to this:
>
>      From shred's man page:
>
>                CAUTION: Note that shred relies on a very important
>         assumption: that
>                 the file system overwrites data in place.  This is  the 
>         traditional
>                 way to do things, but many modern file system designs do
>         not satisfy
>                 this assumption.  The following are  examples  of  file 
>         systems  on
>                 which  shred  is not effective, or is not guaranteed to
>         be effective
>                 in all file system modes:
>
>                 * log-structured or journaled file systems, such as 
>         those  supplied
>                 with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
>
>
>     And from srm's README on SourceForge:
>
>         All users, but especially Linux users, should be aware that srm
>         will only work on file systems that overwrite blocks in place.
>         In particular, it will *NOT* work on reiserfs or the vast
>         majority of journaled file systems. It should work on ext2,
>         FAT-based file systems, and the BSD native file system. On ext3
>         srm will try to disable journaling of data, see the verbose
>         output if this fails.
>
>
>     Unfortunately, I don't have a solution for the original question
>     posted in this thread. While I hate to be a naysayer who doesn't
>     offer any solutions, I would hate for any of us to fall into a false
>     sense of security in believing that shred, srm, or rm is securely
>     deleting data in environments where it might not.
>
>     Best,
>
>     Zachary Yamada, CEH, CHFI
>     Chemeketa Community College
>     Information Security Team Lead
>     503.584.7367
>     zachary.yamada () chemeketa edu <mailto:zachary.yamada () chemeketa edu>
>
>
>     On Tue, Oct 16, 2018 at 12:35 PM Ladwig, John M
>     <John.Ladwig () minnstate edu <mailto:John.Ladwig () minnstate edu>> wrote:
>
>         The now-removed srm(1) did do better than that; pity:____
>
>         __ __
>
>         -m, --medium____
>
>                        overwrite the file with 7 US DoD compliant 
>         passes  (0xF6,____
>
>                        0x00, 0xFF, random, 0x00, 0xFF, random)____
>
>         __ __
>
>         The  -s  option overrides the -m option, if both are present. 
>         If____
>
>                 neither is specified, the 35-pass Gutmann algorithm is
>         used.____
>
>         __ __
>
>         __ __
>
>         *From:* The EDUCAUSE Security Community Group Listserv
>         [mailto:SECURITY () LISTSERV EDUCAUSE EDU
>         <mailto:SECURITY () LISTSERV EDUCAUSE EDU>] *On Behalf Of *Bellot,
>         Clayton H
>         *Sent:* Tuesday, October 16, 2018 2:17 PM
>         *To:* SECURITY () LISTSERV EDUCAUSE EDU
>         <mailto:SECURITY () LISTSERV EDUCAUSE EDU>
>         *Subject:* Re: [SECURITY] Secure Delete for Mac____
>
>         __ __
>
>          From the Terminal on 10.14, you should be able to use the “-P”
>         switch with the rm command:____
>
>         __ __
>
>         “Overwrite regular files before deleting them.  Files are
>         overwritten three times, first with the byte pattern 0xff, then
>         0x00, and then 0xff again, before they are deleted.”____
>
>         __ __
>
>         Hope this helps,____
>
>         Clayton____
>
>         __ __
>
>         __ __
>
>         *From: *The EDUCAUSE Security Community Group Listserv
>         <SECURITY () LISTSERV EDUCAUSE EDU
>         <mailto:SECURITY () LISTSERV EDUCAUSE EDU>> on behalf of Chad Tracy
>         <ctracy () BATES EDU <mailto:ctracy () BATES EDU>>
>         *Reply-To: *The EDUCAUSE Security Community Group Listserv
>         <SECURITY () LISTSERV EDUCAUSE EDU
>         <mailto:SECURITY () LISTSERV EDUCAUSE EDU>>
>         *Date: *Tuesday, October 16, 2018 at 12:56
>         *To: *"SECURITY () LISTSERV EDUCAUSE EDU
>         <mailto:SECURITY () LISTSERV EDUCAUSE EDU>"
>         <SECURITY () LISTSERV EDUCAUSE EDU
>         <mailto:SECURITY () LISTSERV EDUCAUSE EDU>>
>         *Subject: *[SECURITY] Secure Delete for Mac____
>
>         __ __
>
>         Apologies if this was hit in a previous post. ____
>
>         __ __
>
>         I am looking to take the pulse of the group regarding secure
>         delete solution for Mac. I understand that it was removed in a
>         previous version. I am hoping there is something similar to
>         Eraser for Windows?____
>
>         __ __
>
>         Thoughts? ____
>
>         __ __
>
>         Cheers,____
>
>         __ __
>
>         Chad
>         ____
>
>         __ __
>
>         -- ____
>
>         Chad Tracy ____
>
>         Director of Information Security, Policy and Compliance____
>
>         Bates College____
>
>         207 786-6491____
>
>
>
> --
> Frank Barton, MBA
> Security+, ACMT, MCP
> IT Systems Administrator
> Husson University

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature