The Craft of System Security

In this Chapter 16 excerpt from, The Craft of System Security, authors Sean Smith and John Marchesini explain how an adversary can extract data from a device -- even after it has been 'erased.'

The following is an excerpt from the book, The Craft of System Security . In this section of Chapter 16: Hardware-Based Security (.pdf), authors Sean Smith and John Marchesini explain how an adversary can extract data from a device, even after that information has supposedly been 'erased.'

Sean Smith reads from his book

Listen to author Sean Smith, as he reads from Chapter 13: Office Tools and Security.
Historically, nonvolatile magnetic media, such as disks or once ubiquitous tapes, have been notorious for retaining data after deletion. On a physical level, the contents of overwritten cells have been reputed to be readable via magnetic-force microscopy; however, a knowledgeable colleague insists that no documented case exists for any modern disk drive. Nonetheless, researchers (e.g., [Gut96]) and government standards bodies (e.g., [NCS91]) have established guidelines for overwriting cells in order to increase assurance that the previously stored data has been destroyed. (The general idea is to write a binary pattern, then its complement, then repeat many times.)

A complicating factor here is the existence of many layers of abstraction between a high-level request to delete data and what actually happens on the device in question. In between, many things could cause trouble.

  • For example, a traditional filesystem usually breaks a file into a series of chunks, each sized to occupy a disk sector, and distributes these chunks on the disk according to various heuristics intended to improve performance. Some type of index table, perhaps in a sector of its own, indicates where each chunk is. In such a system, when the higher-level software deletes or even shrinks a file, the filesystem may respond by clearing that entry in that file's index table and marking that sector as "free." However, the deleted data may remain on the disk, in this now-free sector. (Issues such as this led to the object reuse worries of the Orange Book world of Chapter 2.)
  • Journaling filesystems, a more advanced technology, make things even worse. Journaling filesystems treat the disk not as a place to store files so much as a place to store a log of changes to files. As with Word's Fast Save option (see Chapter 13), the history of edits that resulted in a file's current state may be available to the adversary inspecting the disk itself.
  • Computing hardware has seen a sort of trickle-down (or perhaps smarting-down) effect, whereby traditionally "dumb" peripherals now feature their own processors and computing ability. Disk controllers are no exception to this trend, leading to yet another level of abstraction between the view the computing system sees and what actually happens with the physical media.

The Craft of System Security

Authors: Sean Smith, John Marchesini

524 pages; $53.99

Addison-Wesley official book page
In recent years, semiconductor FLASH memory (e.g., in USB thumbdrives) has probably become more ubiquitous than magnetic media for removable storage. FLASH is also standard nonvolatile storage in most embedded devices, such as cell phones and PDAs. The internal structure of a FLASH device is a bit more complex than other semiconductor memories (e.g., see [Nii95]). FLASH is organized into sectors, each usually on the order of tens or hundreds of kilobytes. When in "read" mode, the device acts as an ordinary ROM. To write a sector, the system must put the FLASH device into write mode, which requires writing a special sequence of bytes, essentially opcodes, to special addresses in the FLASH device. Typically, the stored bits can be written only one way (e.g., change only from 0 to 1). To erase a sector (e.g., clearing all the bits back to 0), another sequence of magic bytes must be written. Often, FLASH devices include the ability to turn a designated sector into ROM by wiring a pin a certain way at manufacture time.

For more information

Ask the Expert: Can confidential data be accessed once it is deleted for free space?

Before deciding on an enterprise data protection plan, answer these two questions: Where is your data, and how is it being handled?

Visit's Data Protection School.
FLASH gives two additional challenges for system implementers. First, writing and erasing sectors both take nontrivial time; failure, such as power interruption, during such an interval may lead to undetermined sector corruption. Second, each FLASH cell has a relatively small (e.g., 10,000) lifetime of erase-write cycles.

These technical limitations lead to incredible acrobatics when designing a filesystem for FLASH (e.g., [GT05, Nii95]). In order to avoid wearing out the FLASH sectors, designers will use data structures that selectively mark bits to indicate dirty bytes within sectors and rotate usage throughout the sectors on the device. For fault tolerance, designers may try to make writes easy to undo, so that the old version of a file can be recovered if a failure occurs during the nontrivial duration of a write. Even relatively simple concepts, such as a directory or index table, get interesting—if you decide to keep one, then you'll quickly wear out that sector, even if you're clever with the rest of the files.

FLASH architecture has several consequences for security.

  • Because of these log-structured and fault-tolerant contortions, old data may still exist in the device even if the higher levels of the system thought it was erased.
  • Because an error in a product's ROM can be expensive, at least one vendor includes an undocumented feature to rewrite the ROM sector by writing a magic series of bytes to the chip. (The complexity of the legitimate magic-byte interface makes it hard to otherwise discover such back doors.)
  • Because of the large market demand for low-cost thumbdrives and the smarting down of computation into peripherals, much engineering has gone into commercial FLASH drives, leading to a gap between even the API the encapsulated device provides and the internal state.

Read the rest of Chapter 16: Hardware-Based Security.

Reproduced from the book The Craft of System Security Copyright [2007], Addison Wesley Professional. Reproduced by permission of Pearson Education, Inc., 800 East 96th Street, Indianapolis, IN 46240. Written permission from Pearson Education, Inc. is required for all other users.
This was last published in November 2007

Dig Deeper on Data security strategies and governance



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.