"scrubbing" below the FTL

I thought your question related to PCs, sorry.

Well, I might be using the wrong terminology, but as presented to the OS, most ATA drives, SD cards etc. pretend to have a fixed number of sectors, which I could overwrite all of. It certainly doesn't mean that the underlying flash chips have had all of the data overwritten, but if you don't alter/crack the firmware or hardware of the drive, it can't give back the original data, it has to give back the overwriting data, otherwise it wouldn't work in normal use. Remember I qualified all of this with the proviso that I am only talking about the case where the attacker doesn't probe/desolder the flash chips or find bugs in the controller. If this isn't a standard SSD but rather something integrated with the OS like a phone, then of course the contents of the flash chips might be accessible. Perhaps you would be better off not storing the data on there unencrypted in the first place.

Yes. Depending on the determination of the attacker and the difficulty of altering the drive firmware, this might matter or not.

True.

On a magnetic drive, if the relocated sectors were only due to genuine errors then again I am not so worried about this because only a small proportion of what is on my drives is at all private, and that is statistically unlikely to be on a sector that is genuinely bad enough to get relocated but still good enough to readable. On the other hand, if the drive makers were encouraged to deliberately relocate sectors with certain text strings in them, and other sectors accessed around the same time... pass me my tinfoil hat.

Sure, but (again I mentioned that this is for the case where the attacker doesn't probe chips nor alter drive firmware) when the casual attacker reads sector logial sector 123, they get the new data, so no problem in this casual snooping case.

Ok, I didn't think we were talking about embedded devices but rather PCs with SSD modules in them.

Sure, and I wouldn't do that.

Yes, firmware updates to the SSD would likely expose old data. Probably this could happen with magetic disks too.

I type it in each time it boots, so burglars wouldn't get my data. If you don't care about that, perhaps you can put the key on a USB stick that stays plugged in, with a big label on it for your heirs. For safety you can also print out another copy of the key and put that in your safe.

Exactly. And it might be deliberately not strong.

It is all a compromise. I haven't noticed much CPU load from software drive encryption though.

The trouble is, it is very hard to make operating systems keep personal stuff separate. It tends to hang around in page files and stuff.

Well, different people have different priorities. I like to know that if my laptop got stolen my personal data would be hard to get at. There's nothing to stop you making an unencrypted backup copy of your data onto a DVD and putting it in your safe, (and/or putting a copy of the key in your safe so you have access to the latest data on your hard drive, even if you don't update the DVDs often).

Sure, you still need backups.

I think I basically agree with your technical understanding of all of this, it is just that I thought you were asking a different question from the one you thought you were asking, and your priorities are somewhat different from mine.

Chris

The key assumption is that the firmware can't be altered or cracked. Historically, expecting things NOT to be cracked is a losing battle. Whether the crackers are motivated by curiosity, prestige or monetary gain, there's no way to prevent folks from doing this. ESPECIALLY if they can get their grubby little mitts on the gear AND get it "behind closed doors"!

How many "jail-broken" phones are out there? For a small fee (lunch at a burger joint for a family of three) you can have your phone jail-broken. Ditto gaming consoles, "secure" MCUs, etc. I.e., products where the vendors have a significant interest in PREVENTING SUCH ACTIVITIES and DEEP POCKETS to do so!

The use of Flash for firmware store in these devices actually makes this easier -- as it encourages manufacturers to design for upgradable software (which lowers the bar for hackers to gain entry to the device's hardware -- without even having a soldering iron or 'scope!)

It's only a matter of (low) quantity and *variety*, I think, that has kept SSDs "saf" from this sort of attention. Too many vendors with too many models and too many firmware versions to provide a worthwile (ahem) "market" for attacks. Not like game consoles or phones that exist in huge numbers and in very *visible* ways (can you tell which SSD is in a machine just by "looking" at it? :> OTOH, you can probably tell which of your associates are using which version(s) of the iPhone, etc!)

And, the firmware in SSDs is complex. And, probably will get even moreso. So, you can expect some update(s) to "miss the obvious". Perhaps reseting flags to some default state *in* the flash array's data structures instead of leaving them "as is". And, potentially making "dirty" blocks waiting for erasure available for use (*if* the code fails to verify they are, in fact, completely erased!)

Few people have the option/ability of encrypting data *before* introducing it to such a device. "OK, my bank account number is

1234334333 so I'll encrypt that and store it on my phone as 7464893490599 where it is convenient for me to access it (WTF?!) but not accessible to others who may steal my phone!" :>

I.e., you have to rely on the features made available by the device -- AND hope that the folks implementing them didn't make any mistakes!

Well, to be fair, I deliberately didn't explicitly exclude SSDs! IME, they represent the only real devices that users can even *consider* "scrubbing" -- hard as that may be. I doubt many folks give a second thought to the files they've stored on their thumb drives, PDAs, "media" cards, personal media players, etc. The devices are essentially considered disposable and folks probably don't consider if the current (or PREVIOUS!) contents were of any value!

Look at WEP... Oops! I mean WPA... Ooops! I mean WPA2... Ooops

40 bit encryption, 128 bit encryption, etc.

Many disk drives implement the encryption inside the drive. So, there's either hardware for that purpose, some software cost (though it would appear as drive latency) *or* an algorithm that isn't particularly robust!

You'd be surprised how much of a trail "personal stuff" leaves in a machine! TEMP files, registry entries, swap files, etc. So, if you want a user to be able to remove his "personal information", you need to give him control over lots of little bits of data that may exist in many different places in the device and in many different forms.

I don't keep any "personally precious" data on my machines (other than "current email" -- which is low value). Partly because I don't want to have to figure out which machine has it (and, which is the most current version!) but, also, because I don't want to risk losing it if a machine goes down (even if the disk is unaffected). E.g., SWMBO had a crash on the machine she uses for email.

"OK, I'll give you another machine and I'll work on rebuilding that one when I get a chance..."

"But my email addresses are all stored on that machine..."

Then, what else? To me, "98% of all blocks survive for 10 years if you use the right ECC" means I have to assume that I lose 2%. Of course, a Bastard Flash Manufacturer from Hell could also fulfill that specification with a flash that is shipped with just 98% of its specified size, with as many bad bits as the spec allows in each block, and all other bits perfectly reliable. But I guess making flash with largely stochastic failure modes is much cheaper :-) And if it fails stochastically, giving it better environmental parameters makes failure less likely.

At least, the difference in bit error rates for flash written with partial-page writes and full-page writes was significant enough to me to implement some sort of write-combining in my FTL.

Stefan

Now you left out all the crucial qualifiers, and totally change the meaning by doing so. They _guarantee_ that 98% will survive. That means you _may_ lose up to 2%, but it doesn't _guarantee_ it.

You are correct that very many passes are not needed (unless you are paranoid in which case they still aren't needed), but it ISN'T a myth that overwritten harddisk data can be recovered.

Get a copy of SpinRite

and turn it loose on a harddisk you've erased. You may be amazed (or even frightened) at what it can recover simply through raw reads and statistical analysis. Often SpinRite can retrieve significant portions of data that has been just recently overwritten.

If you have access to the platters - such as a forensic tech would have - you can do even better.

The track is not a single row of magnetic crystals, there is a 2 dimensional surface into which the track's magnetic signal can bleed.

By micro-positioning the head at different displacements from the track center, you can read "ghosts" of previous contents of the track. If enough of these ghosts remain, you can statistically converge on what data the track contained previously.

Simply zeroing doesn't cut it ... you need to overwrite at least a couple of times using different data before off-track ghosts are weakened to the point that nothing intelligible can be reconstructed.

For certain you don't need ridiculous numbers of passes, but you ought to at least write all ones and all zeroes. After that, the odds of recovering much are quite small.

A blast furnace works just as well. And no need to dismantle it.

Drills work well. So does a good deer rifle.

George

On Thu, 28 Nov 2013 10:52:40 -0500, snipped-for-privacy@attt.bizz Gave us:

Perpendicular head technology and densely packed lineal write density and a lot less energy overall means there are no "side-of-track' data strings to grab anymore.

You are correct.

In a similar vein, I used to be able to read my 360k floppies in the

1.2MB drives, but a 360k floppy formatted and written to in the thinner headded 1.2 would not yield enough energy for the 360k drive to read them correctly.

You're only partly correct. In modern drives, the crystals are oriented vertically and so there is less bleeding into surrounding crystals. Perpendicular heads help to concentrate the field on the crystals in the center of the track, but the adjacent crystals ARE affected. Moreover, because of the high coercivity of the media, it actually requires MORE energy to flip the magnetic orientation of the crystals.

High coercivity means that side-track ghosts take time to form and don't reflect recently written data. However, data which has been sitting in the same place for a (relatively) long period will have formed ghosts that can be recovered. A recent overwrite will not have affected them.

No. The 1.2MB drive actually wrote at HIGHER power, though it wrote a narrower track. The real reason a 360KB drive could not read a disk written by a 1.2MB drive was due to lower coercivity of the 360KB media. The higher write energies of the 1.2MB drive bled over the disk surface and adjacent bits became corrupted.

This was evident even when exclusively using the 1.2MB drive. Writing to 360KB media with read-back-verify had a high probability of failing immediately. After only a short time the data was all but guaranteed to be unreadable by any drive.

George

On Sat, 30 Nov 2013 15:50:36 -0500, George Neuner Gave us:

But there is LESS peripheral influence. The entire track is extremely thin, and if overwritten, there is no residual of the previous written data as the current is over-riding and dominates any read tech one would use to read it.

Back to there being nothing left if ever overwritten.

On Sat, 30 Nov 2013 15:50:36 -0500, George Neuner Gave us:

The now much closer track to track spacing, however means that said formed ghosts never reflect any real string of data, but the averaged values between the random matchups of two adjacent tracks.

I'd be interested in the figures you have to substantiate that.

I can't see how the tracks will be close enough to not leave ghost records over time between them without corrupting each other.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

On a loosely related (but recent hence warm for me) note. I was using lots of 3.5" disks around 1990 on a system I had designed, the TH9. At the beginning the HD disks were too expensive so I used DD formatted as HD (worked just fine). Less than 10 years ago I retired the th9 machine into the cellar, after having it emulated as a DPS task/window etc. (had lots of PCBs, schematics etc. to keep on accessing). I copied the floppies I had as files (which the dps emulation thinks of as floppies) and that was it. The HD formatted DD disks were readable; so were the HD ones. None of the old ones were writable though (failed immediately, the written sectors were no longer readable at all). A few weeks ago I tried to post online as a historic reference the schematics, sources etc. of the th9 machine; only to discover I had two sheets (two .dw files, that is) missing... the floppy I had archived back then had been corrupted. So I took the th9 out of retirement, plugged its retired companion NEC Multisync monitor and... it worked. Not quite, the colours were a mess, some handshake between the CPU and the terminal board a small FIFO board) had been lost but it was usable to recover files from the nylon bag of retired floppies.

Now this time - 20+ years later - the HD formatted DD floppies were completely unreadable. The HD ones from the same time did read OK, some of them, actually (don't know if the non-working had not been damaged by my write attempts about a decade ago).

I even found 1 (just 1!) disk which gave me back the files I had lost.

I have posted screenshots of these in a Bulgarian language group I created recently, the text will not be readable but the shots and sources should be:

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------