Links regarding fde implementations, relevant re geli / gbde. ---------- Forwarded message ---------- From: Darren Lasko <[email protected]> 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" <[email protected]> Cc: [email protected] 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 <[email protected]> wrote: > > On Thu, 19 Jun 2014 23:37:04 -0400 Darren Lasko <[email protected]> > wrote: > > On Thu, Jun 19, 2014 at 5:06 PM, Perry E. Metzger > > <[email protected]> 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 [email protected] http://www.metzdowd.com/mailman/listinfo/cryptography _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"