On Friday, February 16, 2018 at 2:31:38 PM UTC-5, Chris Laprise wrote: > On 02/16/2018 01:44 PM, ron w wrote: > > Qubes should investigate if it is not secure to > > use a ssd because the software which runs > > the ssd may nullify any piece of encrypted > > data on the ssd. > > > > https://www.qubes-os.org/doc/system-requirements/#recommended > > > > http://www.deutschlandfunk.de/verschluesselungssoftware-veracrypt-unabhaengige.684.de.html?dram:article_id=369309 > > Its been discussed in the past... The risk behind this appears to be > more theoretical than a current threat. But this isn't a Qubes-specific > issue; every OS is (potentially) affected more or less the same. When > provisioning hardware, an extremely careful person would use HDDs only.
Dang, sorry folks, my pet area...skip to point 4.5 for some fun paranoid procedures. In my opinion, using either HDDs or SSDs converge to the same risk: that the firmware could be compromised* and that some unused portion of the drive can be used to hide data for exfiltration. I have seen evidence of SSD manufacturers digitally signing and encrypting their firmware images (for governmental security certifications? protecting trade secrets? etc.?), which perhaps makes them more secure against tampering than traditional HDDs were. While much is made of SSD's lack of direct mapping of logical blocks to physical blocks (in a well-structured ordered array of cells across chips), compared to HDDs...HDDs really aren't as perfect in that regard as people assume. Even non-compromised HDD firmware is designed to take advantage of a cache of reserved replacement blocks spread across the disk surface which are designed to be used for drive-managed bad/weak-block remapping. The end user has no access or control over these via the ATA interface. HD recovery companies have designed some tools to work over the debug interfaces, but your computer is generally not wired up to those pins (usually taken advantage of via the jumper pins next to the ATA/SATA connectors). Presumably the HDDs' pseudo-over-provisioning of blocks is at least an order of magnitude smaller than what is used in contemporary flash-based SSDs...but it leads to a similar issue: modified firmware can hide stolen data in the slack area. My recommendation: 1. Embrace contemporary SSDs. 2. Only utilize SSDs with firmware that supports the following features: a. always-on SED below their own FFS layer (this is implied by c). b. ATA Password (this is made useful by a and is also implied by c, ATA Password is considered "Level 0" Opal support) c. TCG Opal v2.x (this supports drive-managed encrypted zones with different keys, etc.). d. Support for ATA SANITIZE CRYPTO SCRAMBLE 3. Re-flash the SSD with the (hopefully signed) manufacturer firmware image when you receive it to reduce the chance of pre-delivery tampering impacting you. 4. Re-key the drive using ATA SANITIZE CRYPTO SCRAMBLE. I have a bootable Lenovo Thinkpad disc image that performs this transaction in a few seconds. It re-keys the entire user data layer. Fun note: some drive models will show all 00s after executing this function, which makes it hard to verify - is it doing more or less than a ATA SECURITY ERASE** or full trim of the drive? Other drives will show what appears to be random data across the disk. With these drives, every time you run the command, the random data changes, which is awesome. It's not random data exactly, it's the original SED encrypted data, but with a different key randomly generated by the drive firmware and used going forward. [[4.5 When you really want to kill all the data with fire: a) TRIM the entire user area you have access to (can be limited if OPAL is active, otherwise should be full drive) b) clear the ATA password if ATA password is set, c) peform OPAL PSID revert if OPAL was set up, d) reflash the firmware, e) TRIM the entire drive again, f) perform ATA SANITIZE CRYPTO SCRAMBLE (and verify different data read if possible), g) perform ATA ENHANCE SECURITY ERASE, h) perform ATA SECURITY ERASE. i) finally, TRIM the entire drive again.***]] 5. HW encrypt the drive before production use: either take advantage of BIOS ATA password support for simplicity (Level 0 OPAL requires that your password be used to encrypt the key(s) for the entire user area) or, alternately, implement DTA's sedutil to set up a read-only linux-based PBA image (pre-boot authorization image) that performs the necessary TCG Opal authorization steps to unlock your read/write volume(s) with your password(s). And finally...also utilize --software-- disk encryption (either supplied with your OS or as an add-on to your OS). Intel AES instructions make even software encryption nearly transparent performance-wise. -brendan * a technique implied in various leaks here and there but also...this great example of installing linux onto the on-board *controller* of a HDD - the HDD contains a multi-cpu based computer itself, just like SSDs, even if the percentage of slack space is smaller...and it too can run Linux or whatever implant your adversary wants unless there is a very strong digital signature infrastructure deployed by the manufacturer... http://spritesmods.com/?art=hddhack ** more fun: at least one models of SSD that I have encountered helpfully mapped ATA -ENHANCED- SECURITY ERASE UNIT to be the equivalent of ATA SANITIZE CRYPTO SCRAMBLE, which makes that function much more accessible in that existing linux tools such as hdparm support it and you also know that the user area key was changed all in one step. *** tool list - each can handle some needs: hdparm (linux), sedutil (win/linux), txbench (win, very useful for working with ATA SECURITY ERASE using UASP via USB in newer versions of Windows that normally lock out the capability), "ThinkPad Drive Erase Utility for Resetting the Cryptographic Key and Erasing the Solid State Drive" (that's really the name of the software - and there were a few older models of Thinkpad that included it directly in the BIOS!!!), parted magic (linux bootable) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/86b42567-cd74-4e51-bf0d-47e7737fb130%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
