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

[grarpamp]

Links regarding fde implementations, relevant re geli / gbde.


---------- Forwarded message ----------
From: Darren Lasko <dlasko at ieee.org>
Date: Thu, Jun 26, 2014 at 6:03 PM
Subject: Re: [Cryptography] hardware vs software FDE (was Re:
Shredding a file on a flash-based file system?)
To: "Perry E. Metzger" <perry at piermont.com>
Cc: cryptography at metzdowd.com


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


_______________________________________________
The cryptography mailing list
cryptography at metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography