On 04/01/2017 07:31 AM, Vít Šesták wrote:
The problem is:
1. The AEM is not perfect. Various vulnerabilities have been published and I am
unsure what level of real protection (i.e., not just obscurity) can it provide.
2. AEM is not for free. When filtering only laptops with TXT+TPM, you have
quite limited options, selection will take more time and it will probably
result in a more expensive laptop. It is really worth the limited protection?
This is the problem I was trying to address when talking about the Opal
drive capabilities. Encryption is not the only thing Opal can do, and if
you have an SSD you likely have this extended capability onboard
already. For instance, all Samsung SSD's have Opal onboard, but you may
never know its there unless you activate it. If you have one its already
encrypting by default but using a default key found on the label.
When a range covering the boot partition is marked read only the drive
will prevent _any_ tampering, even using root system privs. Once booted
and everything is properly measured (TPM or home grown) one can then
choose to unlock that ro partition or just grub/chainload into another
rw partition containing a protected system OS. The way I see it, one can
boot Xen from a read-only (aka Xen isofs) partition and then test,
expose, and then load Qubes proper from the next partition.
All this requires hardware wise is buying an off the shelf SSD drive,
and the Opal capability (usually) comes for free, as well as the
additional boot performance of an SSD you might gain. You don't even
need encryption enabled, just a defined region that write protects the
MBR and first boot partition. Using both a read-only partition and
trusted boot measurements is a belt-and-suspenders kind of protection,
up front, before anything even becomes modifiable. This can be used to
test for any extra hardware attached that might be trying to intercept
the boot process aiming to take control at a later point.
From a cold system, if you can't write to the partition, you can't hack
the bootstrap, even after the system gains root privs. If you can't see
the next chain-loaded partition, you can not reverse it to even know how
to hack it. You also can not physically disassemble the device to
recover a key, because its not stored there, only a portion of the
entropy that is required to re-create the key on the fly is in the
device. You will still need a secret to unlock or make it rw for
patching or for permitting upgrades, and that entropy can be encrypted
by the TPM/SRK/KEK, or the user can provide a password for doing those
required updates.
Some coding will be required to make it idiot-proof and easy-to-use, but
the benefits of being nearly tamper-proof would be raising the bar even
for even nation-states to climb over. I really need to make time to get
back into this project.
Steve
Regards,
Vít Šesták 'v6ak'
--
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/0d20c85b-663a-b047-c9bc-b2decf239a84%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.
