[Cryptography] Security on TRIM for full-disk encrypted SSDs

Tom Mitchell mitch at niftyegg.com
Thu Apr 21 21:54:44 EDT 2016


On Thu, Apr 21, 2016 at 3:08 PM, RB <aoz.syn at gmail.com> wrote:

> On Thu, Apr 21, 2016 at 3:19 PM, Peter Fairbrother <peter at m-o-o-t.org>
> wrote:
> > You think that an attacker knowing how much data you send doesn't affect
> > confidentiality?
> >
> > hmmm, how many files on t'internet are 2798954788 bytes long?
>
> You're right - that matters, but only for specific threat models,
> particularly those involving transmission of illicit material.
> Returning to the problem at hand - that of allowing one's opponent to
> know one's net drive allocation by enabling TRIM under encryption -
> the answer remains "it may matter".
>

 There are two parts -- OS must support and Storage device must
support.  Which OS are we discussing and what can an OS do
to allow the hardware TRIM actions to operate safely?  i.e. not
leak hints.

It seems to me that an operating system enhancement could select
which blocks to inform the solid-state drive(SSD) about which blocks
of data are no longer considered in use and can be wiped internally.
Simple garbage collectors have design choices. One is black and white.
Another is black, grey, white.   The three state choice allows improvement
in coherent processing of garbage.
Disk block management is a garbage collection and data reuse challenge that
maps
to all the garbage collection research out there.

An encrypted file or file system strategy could with strong capability
management tags allow (or not) a processes to reuse it's own blocks.
A write queue could see a write demand and have the OS issue TRIM commands
sufficient to accelerate the write queue plus a system cushion.

Metadata  is an obvious byte count leak but could be moderated with
containers like a tar or zip archive with or without compression.





-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160421/f2511d2f/attachment.html>


More information about the cryptography mailing list