Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Forbes recommends tools for journalists

Julian Oliver julian at julianoliver.com
Tue Dec 18 02:13:52 PST 2012


..on Mon, Dec 17, 2012 at 03:28:31PM -0800, Brian Conley wrote:
> Its SSD so its still not a secure wipe, no?

Indeed. From 'Securely Destroying Data' chapter in The CryptoParty Handbook
v1.1:

//----------------------------------------------------------------------------->

An important note on Solid State Hard Drives

The instructions below explain how to use file deletion tools to securely delete
files from your hard drives. These tools rely on the Operating System you are
using being able to directly address every byte on the hard drive in order to
tell the drive "set byte number X to 0". Unfortunately, due to a number of
advanced technologies used by Solid State Drives (SSDs) such as TRIM, it is not
always possible to ensure with 100% certainty that every part of a file on an
SSD has been erased using the tools below.

//<-----------------------------------------------------------------------------

Us Linux users with our lovely journaled file systems need to take care:

//----------------------------------------------------------------------------->

An important note on Journaled File Systems

Data Journaling is a feature of several modern file systems and presents a risk
to secure data deletion. File-systems of this type include Ext3 and Ext4
(Linux), compressed file systems and RAID-based file systems.

The manual page for the deletion program Wipe says:

No secure deletion program that does filesystem-level calls can sanitize
files on such filesystems, because sensitive data and metadata can be written to
the journal, which cannot be readily accessed. Per-file secure deletion is
better implemented in the operating system.

The manual page for the deletion program Shred says:

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.)

        file systems that write redundant data and carry on even if some writes
        fail, such as RAID-based file systems * file systems that make snapshots, such
        as Network Appliance's NFS server

        file systems that cache in temporary locations, such as NFS version 3
        clients
        
        compressed file systems 

In the case of ext3 file systems, the above disclaimer applies (and shred is
thus of limited effectiveness) only in data=journal mode, which journals file
data in addition to just metadata. In both the data=ordered (default) and
data=writeback modes, shred works as usual.  Ext3 journaling modes can be
changed by adding the data=something option to the mount options for a
particular file system in the /etc/fstab file, as documented in the mount man
page (man mount).

If you wish to delete data from a journaled file-system on Linux (mounted in
data=journal mode) you should remount it in another mode. To be sure, remount
your disk in Linux in data=ordered mode. See the manual page for the program
mount on your system. Solaris users or those with RAID systems are outside of
the scope of this manual. Please see the relevant documentation and/or research
your special case in order to be sure you are securely deleting your data.

//<-----------------------------------------------------------------------------

    https://cryptoparty.org/wiki/CryptoPartyHandbook#Version_1.1

Cheers,

Julian

> On Dec 18, 2012 12:26 AM, "Eric S Johnson" <crates at oneotaslopes.org> wrote:
> 
> > > Secure deletion is a problem we could solve in software, by encrypting
> > > the data and then destroying the key to render the data unrecoverable,
> > > *if* we had a few bytes of persistent, erasable storage in which to
> > > store the key. (Storing the key on the SSD itself doesn't work,
> > > because then we can't securely delete the key.)
> > >
> > > I'm not aware of any suitable storage on current smartphones or
> > > personal computers
> >
> > Isn't this exactly how the iOS (v4+) can be remotely "wiped" in a couple
> > seconds? Everything's encrypted, so deleting the key ...
> >
> > Or are we saying the iOS's storage of the key is insecure?
> >
> > Best,
> > Eric
> >
> > --
> > Unsubscribe, change to digest, or change password at:
> > https://mailman.stanford.edu/mailman/listinfo/liberationtech
> >

> --
> Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech


-- 
Julian Oliver
http://julianoliver.com
http://criticalengineering.org



More information about the liberationtech mailing list