Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm surveying current techniques on flash memory security. I've learned that the non-in-place update of flash memories prevent us from adapting the same encryption techniques that we used on hard disks — see Do Flash memory (SSD) architecture impacts encryption techniques? — and I was wondering what kind of mechanism is being used to address that.

To put my question in a clear form, let say data "a" is stored in address "x", but after encryption the data "a" can't be stored in the same address "x" (because there is no in-place update in flash memories). So what we do is encrypt the data, say " a' ", and store it in another address " x' ". Since the unencrypted data "a" is still available, we have to delete it (note that in SSDs we can only erase a whole block at a time), which results in erasing and displacing all the data found in the same block as "a". The problem is, this will cause a lots of erase operations, and if it continues this way the memory will wear off after a limited number of erasures.

I would like to know if there are any solutions for this problem.

share|improve this question
add comment

3 Answers

I think this question is asking a bit more about what happens when you encrypt data on a device where that data was previously unencrypted. SSD units and HDD units suffer from different possible compromises related this. This is basically referred to (at least on the venerable Wikipedia) as data remanence. That article offers lots of information about the various ways that data can remain or be leaked on hard drives.

Where the SSD presents a special problem, it also presents a new resolution: the "Secure Erase" command to compensate, just as TRIM helped compensate with deletions.

If your security concerns are sufficiently high that you're worried about the block level activity of unencrypted data, though, I suggest the following: consider any drive that has ever held sensitive data in an unencrypted state to be tainted. Use partition or device-level whole disk encryption.

This applies to HDD systems as well as SSD systems. The particular case would be an over-written file. Advanced recovery techniques have been theorized to read overwritten data (hence secure wipe pattern algorithms: DoD 5220.22-M), though that may be an artifact of lower density drives (http://computer-forensics.sans.org/blog/2009/01/28/spin-stand-microscopy-of-hard-disk-data/ and http://www.securityfocus.com/brief/888). Never the less, advanced filesystems might process an overwrite to another location, or capture snapshots of data when unencrypted.

share|improve this answer
    
Secure Erase is part of the ATA specs and is available for conventional hard drives, not just SSD which your answer suggests. But -1 for perpetuating the myth that "advanced recovery techniques exist". –  DanBeale Aug 16 '11 at 18:29
    
I agree that the myth perpetuation deserved a -1, but I'm +1'ing it back up because "consider any drive that has ever held sensitive data in an unencrypted state to be tainted" is exactly correct. It's not that the physical HDD bits have a memory longer than 1 overwrite, it's that the data can exist in many places you didn't expect. –  user502 Aug 16 '11 at 18:34
    
@DanBeale Looks like that idea of recovery became highly disputed around 2008. Thanks for prompting me to look into it. As for the erasure command, not all devices support it. Some SSD drives do by means of changing crypto keys, others (rare) I believe by clearing each block. Vendors are able to implement commands as they see fit, so you could encounter one that returns a failure that it wasn't implemented, or in the worst case one that says, "OK" without doing anything. Sophos cites a paper that found a 33% success rate (2/3 implemented, 1/2 of those worked): bit.ly/fyeQ3d –  Jeff Ferland Aug 16 '11 at 18:50
    
-1 removed because, really a comment is enough. –  DanBeale Aug 17 '11 at 7:32
add comment

Intentional non-in-place updates are often used for critical software or data like the BIOS. Unintentional non-in-place is usually done by wear-leveling algorithms. For normal file access on certain types of flash controllers, you can write drivers to allow same-address write after erase. The block size is usually 128kB which is not too bad considering the large size of typical flash components and files.

If you require byte-level erasure you could go to serial EEPROM. EEPROM is the ancestor of Flash memory. It has faster read and write times and does not require block-level erasure before writing. The biggest drawback of EEPROM is capacity. The largest EEPROMs are 8 MB compared to Flash at 256GB! EEPROM has a lifetime of about 100,000 write/erase cycles, which is similar to common flash but well behind high-endurance flash which has an order of magnitude more cycles (1,000,000).

FRAM (ferroelectric random access memory) is a less popular option that also has fast read and write speeds as well as byte-level access, but low availability and little support in terms of tools and software. It has a much longer lifetime and lower power usage but it is mostly found on system-on-chip (SoC) components rather than as stand alone memory.

share|improve this answer
add comment

I believe there is a misconception of how data encryption works on current SSDs. Data are written from the host to the device in 8bit/10bit format. On the level of the link layer the data are converted back to 8bit /byte format and then sent to the cache (either DRAM or SRAM). If the controller supports encryption (most of them do) the data are then encrypted on the fly, and the parity information is generated for the encrypted data before the data and the parity information is written to the actual NAND flash pages in a round robin scheme (after multiplexing over the available channels).

In other words, data are not written in a non-encrypted format if encryption is desired, rather, encryption is done in-line. If this wasn't done, one could only write one single page per block, then encrypt the data, write them to the next page and invalidate the previous page, which would still leave the unencrypted data for anybody who can access them by doing a global purge or by downloading the entire contents of the IC. Therefore, it would be necessary, to write one page, encrypt it (and write it to the next page of the same block) and then erase the entire block and only copy the encrypted page to another block. If anybody would do this, the write amplification would be astronomical.

Regards, Michael

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.