[Cryptography] hardware vs software FDE (was Re: Shredding a file on a flash-based file system?)

[Darren Lasko]

Hi Perry,

Sorry for the very slow reply; I was away on vacation.

On Fri, Jun 20, 2014 at 9:04 AM, Perry E. Metzger <perry at piermont.com>
 wrote:

> On Thu, 19 Jun 2014 23:37:04 -0400 Darren Lasko <dlasko at ieee.org>
> wrote:
> > On Thu, Jun 19, 2014 at 5:06 PM, Perry E. Metzger
> > <perry at piermont.com> wrote:
> >
> > > It is different in a vital respect -- in the software
> > > implementation, you can more or less check that everything is
> > > working as expected, and you don't have to trust that the drive
> > > isn't sabotaging you. That's quite different -- vitally so, I
> > > think.
> [...]
> > However, to your point that "in the software implementation, you
> > can more or less check that everything is working as expected,"
> > this only holds true if it's open-source (and as we have found
> > recently, this is still no guarantee against nasty security
> > "flaws"), or if you're willing to reverse-engineer a closed-source
> > product (which you could also do with a hardware-based product,
> > though likely at a greater expense).
>
> No. You are missing a very vital point.
>
>
I really don't think I missed your point.  I even acknowledged that point
in my previous post.  My counter-point is merely that the actual media
encryption part, while vitally important, is only a small part of the
overall FDE solution.  The other parts of the solution are equally
important, much harder to get right, and not readily verifiable in *either*
a hardware solution or a closed-source software solution.  I would argue
that if you don't trust hard drives with built-in encryption, then you also
shouldn't trust closed-source software drive encryption products (and maybe
you don't).

In fact, even the actual media encryption part is probably much harder to
verify in a closed-source software implementation than you might be
thinking...

If the sectors on the drive are encrypted with some particular
> algorithm using some particular key, I can check, in a software only
> solution, that the sectors are indeed encrypted in that key using
> that algorithm.


Getting "that key" out of a closed-source software FDE product will require
reverse-engineering the product or employing something like the techniques
used in the Princeton "cold boot attack".  And once you have the key, you
also need to know the encryption algorithm and cipher mode being used
(which is usually specified in the product documentation) *plus* the
product's algorithm for generating IVs/tweaks for the cipher mode (probably
only discoverable by reverse-engineering, since I've never seen a
closed-source implementation give this level of detail in its
documentation).  This is why I said in my previous post, "you can take a
look at the ciphertext and verify that you see random-looking bits, and
maybe verify through experimentation that it's not using a poor choice of
cipher mode like ECB."  Anything more than that will require you to dive
deep into the inner workings of the product.

[...]

> It is actually much worse than that since the hardware implementation
> could be doing things like stashing keys in hidden sectors, but one
> need not go so far as to worry about that because even the most basic
> audit is impossible.
>
>
Software-only products are capable of implementing equivalent levels of
malfeasance, for example by obfuscating the plaintext media encryption key
and stashing it in the area of the drive they reserve for their pre-boot
code and metadata.  They could even encrypt the media key using a public
key to which the developers (or their "partners") hold the private key.


> > While it's true that even with a closed-source product you can take
> > a look at the ciphertext and verify that you see random-looking
> > bits,
>
> No, if they say "this is using AES-256 GCM" I can do more than that.
>
>
Again, not without the key.


> If your closed source vendor is not telling you what algorithm and
> mode they are using, they are of course also doing something
> unacceptable and should be excluded from your purchases. It is
> acceptable (though not even remotely optimal) if the encryption
> implementation is closed source, but it is utterly unacceptable if
> its method of operation is not fully disclosed.
>
>
Your original comment was about "checking/verifying", not "disclosure".  If
you look at the datasheets for self-encrypting drives from just about any
respectable manufacturer, they disclose the encryption algorithm/mode:
http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-pro-1500-series-sata-specification.pdf
(XTS-AES-256,
FIPS 197 certified)
http://www.micron.com/-/media/documents/products/data%20sheet/ssd/m550_2_5_ssd.pdf
(AES-256
CBC)
Seagate has FIPS 140-2 certification on various models, so even more
information can be gleaned from their public security policies (e.g.
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2119.pdf)
and CAVP certifications (e.g. AES cert #1974 for XTS, CBC, and EBC)

Just to reiterate, checking that the actual media encryption is implemented
correctly in a closed-source software product is not a straightforward task
(even though you can easily "see" the ciphertext).  We haven't even
discussed how you would verify the other (and trickier, IMO) bits of the
product, such as entropy source & RNG for generating media keys, how
passwords are "strengthened", how the media key(s) are cryptographically
protected with the "strengthened" authentication credentials, how the "key
blobs" are sanitized from the drive (especially on flash-based storage
devices), etc.

I think it's fair to say that hardware-based FDE solutions aren't any more
"untrustworthy" than their closed-source software counterparts, and I think
one could even argue that open-sourced isn't a silver bullet (
http://underhanded.xcott.com/).  Even in software implementations, there
are a variety of components that are just as difficult to verify everything
is working as expected; and as such a high level of faith is required that
the software isn't sabotaging you.

Regards,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140626/9110d318/attachment.html>