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
