Linux Today - LinuxGazette: Securely Erasing a Hard Drive with Perl
http://linuxtoday.com/news_story.php3?ltsn=2001-02-18-016-20-PS-HW-HL -- The Laws of Serendipity: 1. In order to discover anything, you must be looking for something. 2. If you wish to make an improved product, you must first be engaged in making an inferior one. Tivoli Certification Group, OSCT James Choate jchoate@tivoli.com Senior Engineer 512-436-1062
A much better article on the topic can be found at http://www.cs.auckland.ac.nz/~pgut001/secure_del.html The problem is that data that's been written over once, or even twice or ten times, can often still be read if someone actually takes the platters out and uses electromagnetic microscopy on them. If you "erase" data using the perl script in the article Jim pointed at, it will be safe from J. Random who doesn't have much time, money, or technique to spend on it. But it won't be safe from TLA's, commercial data-recovery shops, or any seriously "hardcore" hackers (or people who, for example, know enough to take it to a commercial data-recovery shop). To actually finish the job, you'd want extremely low-level access to the drive, including the ability to micro-adjust the head alignment so as to write garbage both hubward and rimward of where the track you're trying to erase *ought* to be within its sector, which of course would require you to be able to relocate the info on the sectors physically hubward or rimward of the track you were trying to erase, because writing hubward or rimward with micro-adjustments within a sector could cause errors on those adjacent sectors. I don't know of any OS that provides sufficiently low-level HD access to allow people to create a portable utility that does really secure deletion. Hell, a lot of Hard Drives don't even have drivers that support the needed operations. The moral of the story is, in a really secure system, the plaintext NEVER hits your hard drive. Bear On Mon, 19 Feb 2001, Jim Choate wrote:
http://linuxtoday.com/news_story.php3?ltsn=2001-02-18-016-20-PS-HW-HL -- The Laws of Serendipity:
1. In order to discover anything, you must be looking for something.
2. If you wish to make an improved product, you must first be engaged in making an inferior one.
Tivoli Certification Group, OSCT James Choate jchoate@tivoli.com Senior Engineer 512-436-1062
At 11:38 AM 2/19/01 -0800, Ray Dillinger wrote:
The problem is that data that's been written over once, or even twice or ten times, can often still be read if someone actually takes the platters out and uses electromagnetic microscopy on them.
Really? You think the fed specs on secure wiping are disinfo? ....... "What company did you say you were from, Mr. Hewlett?" ---Walt Disney to Bill Hewlett eetimes 22.01.01 p 32
On Mon, 19 Feb 2001, David Honig wrote:
At 11:38 AM 2/19/01 -0800, Ray Dillinger wrote:
The problem is that data that's been written over once, or even twice or ten times, can often still be read if someone actually takes the platters out and uses electromagnetic microscopy on them.
Really? You think the fed specs on secure wiping are disinfo?
Disinformation is such an ugly word... and the published fed specs on secure wiping apply to not-very-sensitive data. For highly sensitive data, most secure wipe specs are classified, or, as someone else here pointed out, involve physical destruction of the drive. I think this is probably one of the biggest gaps remaining in system security. If you are careful, you can use BSD and GPG etc to build a quite secure box - but if sensitive plaintexts are ever stored on the drive, even if they are overwritten, then when a data thief willing to spend enough bucks gets the drive, you lose. At the very least, we need browsers that don't store their caches, cookies, or history files in cleartext. We need mail programs that never EVER write the cleartext to the disk. We need newsreaders that don't store the articles in cleartext, or for that matter the list of newsgroups that someone is subscribed to. We need editors that don't put cleartext on the disk when you hit the "save" command. This is basic stuff, fundamental. Hardware theft is a threat model that's been far too often ignored in the design of secure systems. Why bother to build a good cipher if you leave the plaintext lying around where it can be stolen? Bear
What we need is encrypted distributed file systems ala Plan 9. http://plan9.bell-labs.com http://www.vitanuova.com ____________________________________________________________________ Before a larger group can see the virtue of an idea, a smaller group must first understand it. "Stranger Suns" George Zebrowski The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- -------------------------------------------------------------------- On Tue, 20 Feb 2001, Ray Dillinger wrote:
On Mon, 19 Feb 2001, David Honig wrote:
At 11:38 AM 2/19/01 -0800, Ray Dillinger wrote:
The problem is that data that's been written over once, or even twice or ten times, can often still be read if someone actually takes the platters out and uses electromagnetic microscopy on them.
Really? You think the fed specs on secure wiping are disinfo?
Disinformation is such an ugly word... and the published fed specs on secure wiping apply to not-very-sensitive data. For highly sensitive data, most secure wipe specs are classified, or, as someone else here pointed out, involve physical destruction of the drive.
I think this is probably one of the biggest gaps remaining in system security. If you are careful, you can use BSD and GPG etc to build a quite secure box - but if sensitive plaintexts are ever stored on the drive, even if they are overwritten, then when a data thief willing to spend enough bucks gets the drive, you lose.
At the very least, we need browsers that don't store their caches, cookies, or history files in cleartext.
We need mail programs that never EVER write the cleartext to the disk.
We need newsreaders that don't store the articles in cleartext, or for that matter the list of newsgroups that someone is subscribed to.
We need editors that don't put cleartext on the disk when you hit the "save" command.
This is basic stuff, fundamental. Hardware theft is a threat model that's been far too often ignored in the design of secure systems. Why bother to build a good cipher if you leave the plaintext lying around where it can be stolen?
Bear
On Tue, 20 Feb 2001, Ray Dillinger wrote:
We need editors that don't put cleartext on the disk when you hit the "save" command.
Why not simply use encrypted hard drives? Make the driver forget key
material in a fixed period of keyboard inactivity? This would be a helluva
lot easier than making secure versions of every existing application out
there...
Sampo Syreeni
On Thu, 22 Feb 2001, Sampo Syreeni wrote:
On Tue, 20 Feb 2001, Ray Dillinger wrote:
We need editors that don't put cleartext on the disk when you hit the "save" command.
Why not simply use encrypted hard drives? Make the driver forget key material in a fixed period of keyboard inactivity? This would be a helluva lot easier than making secure versions of every existing application out there...
The problem with an encrypted drive is that the applications that are able to write it have got to do key management, and all of those existing applications were written with the assumption that they didn't have to do key management. There are various workarounds, but that's what they are - workarounds. If your application can read and write an encrypted drive without specifically providing the keys, then a trojan on your system can read and write an encrypted drive without specifically providing the keys. These workarounds can only work by "hiding" key management from the application, and thus from the user - which means key management gets done badly if at all. Good crypto can't be tacked on - it has to be designed in. Another problem with an encrypted drive is that an encrypted drive is infrastructure that someone is likely to not have in place when they first discover a real need to encrypt. Don't get me wrong -- I believe in encrypted drives. They provide a "mix" so you can't tell which bit was written by what application, and that's a valuable service. But there are limits to what they can do or should be relied on to do. Applications that write to (and more importantly, which read from) the encrypted drive should themselves be crypto-aware and do proper key management. Bear
On Thu, 22 Feb 2001, Ray Dillinger wrote:
If your application can read and write an encrypted drive without specifically providing the keys, then a trojan on your system can read and write an encrypted drive without specifically providing the keys.
I think it is not sensible to include trojans in the threat model, here. After all, it does not matter how deliciously secure your application seems to be if you assume there can be a keyboard sniffer there, somewhere.
These workarounds can only work by "hiding" key management from the application, and thus from the user - which means key management gets done badly if at all. Good crypto can't be tacked on - it has to be designed in.
Why is this? To me it seems that key management at the system level is far more likely to be securely implemented than the personal blend of a given app coder.
Another problem with an encrypted drive is that an encrypted drive is infrastructure that someone is likely to not have in place when they first discover a real need to encrypt.
The same does go for encrypt capable applications as well, only there's considerably more hassle in trying to setup many of those in a row than in simply relying on an encrypted backing store.
Applications that write to (and more importantly, which read from) the encrypted drive should themselves be crypto-aware and do proper key management.
Could you elaborate a bit on why system level key management isn't enough?
I'm afraid I might be missing something here...
Sampo Syreeni
participants (5)
-
David Honig -
Jim Choate -
Jim Choate -
Ray Dillinger -
Sampo Syreeni