SSD (Flash Memory) security when data is encrypted in place

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.