Qubes 4.0 SSD Encryption
jonbrown...@gmail.com
brenda...@gmail.com
> If you keep wear-leveling in mind, and encrypt the ssd before you fill
> it with sensitive data, id suggest an ssd. Ideally, you should encrypt
> /boot also.
I've posted recommendations on how to add hardware drive encryption on top of Qubes' software encryption on this list before, so I won't repost that.
In summary,
Use an SSD that supports T13 ATA SANITIZE and TCG OPAL, and also remember to enable trim in dom0 ( https://www.qubes-os.org/doc/disk-trim/ ). Enable HW encryption (but also enable QUBES' software encryption).
Bonus: using SSDs with the above features, when you are done with the system you can instantly (< 2s) erase all user data on the SSD by issuing either an ATA SANITIZE - CRYPTO SCRAMBLE EXT command or an OPAL PSID REVERT command (the latter requires the code printed on the drive label).
Brendan
Tai...@gmx.com
palladium "trusted computing" concept and it is not owner controlled.
Do you trust proprietary closed source firmware to protect you? I don't
- those kinds of things have many holes.
There is no reason to use an SED drive.
In terms of encrypting boot that is generally impossible without the use
of coreboot so I suggest to obtain an owner controlled pre-PSP laptop
G505S with owner controlled firmware enforced grub kernel code signing
(you sign your own kernels, initramfs etc) its like MS's "secure" boot
but it is actually secure because it is yours not theirs.
The G505S has open cpu/ram init and people are apparently working on
freeing the video/EC blobs but in the mean time IOMMU protects you.
There is a nice little Qubes 4 G505S community.
jonbrown...@gmail.com
> Anything TCG is bad news - it was spawned by microsofts project
> palladium "trusted computing" concept and it is not owner controlled.
>
> Do you trust proprietary closed source firmware to protect you? I don't
> - those kinds of things have many holes.
>
> There is no reason to use an SED drive.
>
> In terms of encrypting boot that is generally impossible without the use
> of coreboot so I suggest to obtain an owner controlled pre-PSP laptop
> G505S with owner controlled firmware enforced grub kernel code signing
> (you sign your own kernels, initramfs etc) its like MS's "secure" boot
> but it is actually secure because it is yours not theirs.
>
> The G505S has open cpu/ram init and people are apparently working on
> freeing the video/EC blobs but in the mean time IOMMU protects you.
>
> There is a nice little Qubes 4 G505S community.
I just wish it had Heads support :(
http://osresearch.net/
awokd
> On 08/23/2018 01:35 PM, brenda...@gmail.com wrote:
>> Use an SSD that supports T13 ATA SANITIZE and TCG OPAL, and also
>> remember to enable trim in dom0 (
>> https://www.qubes-os.org/doc/disk-trim/ ). Enable HW encryption (but
>> also enable QUBES' software encryption).
>>
>> Bonus: using SSDs with the above features, when you are done with the
>> system you can instantly (< 2s) erase all user data on the SSD by
>> issuing either an ATA SANITIZE - CRYPTO SCRAMBLE EXT command or an OPAL
>> PSID REVERT command (the latter requires the code printed on the drive
>> label).
>>
>
> Anything TCG is bad news - it was spawned by microsofts project
> palladium "trusted computing" concept and it is not owner controlled.
>
> Do you trust proprietary closed source firmware to protect you? I don't
> - those kinds of things have many holes.
>
>
> There is no reason to use an SED drive.
from person to person.
> In terms of encrypting boot that is generally impossible without the use
> of coreboot
required. Will your average evil maid (or some thief who steals your
laptop) have access to tools needed to defeat OPAL, assuming it's
backdoored?
Daniil .Travnikov
Qubes 4.0 encrypts /boot by default or I must do something for that?
awokd
for many people. If you have reason to suspect someone may tamper with it
without your knowledge, options include AEM, SED, Coreboot with GRUB
payload, off-device /boot, and possibly others.
brenda...@gmail.com
> On Thu, August 23, 2018 8:03 pm, Tai...@gmx.com wrote:
> > There is no reason to use an SED drive.
>
> I think that's a bit over-broad. It depends on threat model, which varies
> from person to person.
Agreed.
I'll just add a few bullet points on why it is wise to use the hardware encryption that comes with your OPAL-supporting SED SSD (via ATA Password or OPAL). This only applies to OPAL-supporting SED SSDs (e.g. Samsung 840 EVO/850 PRO and later; Crucial M500 and later):
Read/Write user data denial:
1. ATA Password locked drive cannot be read from or written to until unlocked.
2. OPAL locked drive cannot be written to and on boot only presents a very small volume with generic read-only boot code that loads the tool to authenticate the user to the drive and decrypt the DEK.
Flash firmware denial:
1. The OPAL standard requires that securely-configured drives (having enabling OPAL or ATA Password and importantly, whether currently locked or unlocked) shall block firmware updates or, if they do not fully block, the unlocking credential used to unlock the drive at boot must also be sent to initiate firmware updates.
2. IMPORTANTLY: when not securely-configured (as they come from the factory), firmware updates are not blocked at all. Enabling the locking of the drive at power on is also the way to block firmware changes.
Don't be fooled by past analysis of the flaws of ATA Password, some no longer apply. For example, OPAL supporting drives are required to encrypt the DEK using the ATA Password and not store either the DEK or the Password in cleartext on the drive when ATA Password (or OPAL) is enabled. The old trick of using manufacturer-specific commands (either via the (S)ATA interface or using the jumper pinouts) to disable or rewrite the ATA Password cannot work with OPAL drives to get to the data on them.
Don't like the DEK that was generated by the manufacturer? Change it (and wipe the drive) using ATA Sanitize Crypto Scramble Ext.
> > In terms of encrypting boot that is generally impossible without the use
> > of coreboot
>
> Encrypting boot is one use case for SEDs when only light security is
> required. Will your average evil maid (or some thief who steals your
> laptop) have access to tools needed to defeat OPAL, assuming it's
> backdoored?
And if your OPAL drive is backdoored by the manufacturer for a government, your drive is backdoored whether you're using OPAL or not and depending on what you wanted to keep private, you're already screwed.
No security mechanism exists in a vacuum. Layer them as necessary. I want to prevent both remote firmware tampering and out-of-sight boot tampering. So I utilize the SED hardware security. I also enable software volume encryption, when available, as well.
Brendan
Tai...@gmx.com
>
> And if your OPAL drive is backdoored by the manufacturer for a government, your drive is backdoored whether you're using OPAL or not and depending on what you wanted > to keep private, you're already screwed.
you are absolutely fine and it can't do anything but randomly delete
your data.
In that case you can boot from coreboot-grub to a 100% encrypted ssd or
directly load the kernel from coreboot which then decrypts the drive.
You can also buy an OpenSSD from the OpenSSD project if you want a drive
with libre firmware - what is cool about them too is that you can
upgrade the flash modules without changing the controller.
If one installed an OpenSSD on a TALOS 2 then you could have a system
that is entirely open source and documented.
> No security mechanism exists in a vacuum. Layer them as necessary. I want to prevent both remote firmware tampering and out-of-sight boot tampering. So I utilize the > SED hardware security. I also enable software volume encryption, when available, as well.
have root or physical access and it is game over, additionally anyone
with the capability to re-write drive firmware[1] probably has a bypass
exploit too.
[1] Such a thing is VERY difficult as there is no available
documentation for them and you need documentation+spec sheets to write
device firmware - interesting fact most drives these days have a multi
core ARM processor.
Jean-Philippe Ouellet
> On 08/24/2018 11:44 AM, brenda...@gmail.com wrote:
>>
>> And if your OPAL drive is backdoored by the manufacturer for a government, your drive is backdoored whether you're using OPAL or not and depending on what you wanted > to keep private, you're already screwed.
>
> Wrong - if you have an IOMMU and the drive is software encrypted then
> you are absolutely fine and it can't do anything but randomly delete
> your data.
authentication. I suggest you read more about ciphertext malleability
attacks.
Also, currently disks are owned by dom0, and e.g. a malicious nvme
device could do arbitrary DMA to compromise dom0 and therefore win.
Just because your device has an IOMMU does not mean it is actually in
use to protect you from all DMA-related attacks, and in this specific
case it is not currently in use as such by Qubes.
To really reduce disk-originating attacks to DoS as you suggest (and
as I'm sure many would wish to be the case!) you need something like a
read-only FS protected by dm-verity with the block backend outside
dom0. This is something I have worked on for Qubes, but that work is
not complete yet.
> In that case you can boot from coreboot-grub to a 100% encrypted ssd or
> directly load the kernel from coreboot which then decrypts the drive.
>
> You can also buy an OpenSSD from the OpenSSD project if you want a drive
> with libre firmware - what is cool about them too is that you can
> upgrade the flash modules without changing the controller.
>
> If one installed an OpenSSD on a TALOS 2 then you could have a system
> that is entirely open source and documented.
>
>> No security mechanism exists in a vacuum. Layer them as necessary. I want to prevent both remote firmware tampering and out-of-sight boot tampering. So I utilize the > SED hardware security. I also enable software volume encryption, when available, as well.
>
> If someone has the ability to modify your device firmware they already
> have root or physical access and it is game over, additionally anyone
> with the capability to re-write drive firmware[1] probably has a bypass
> exploit too.
>
> [1] Such a thing is VERY difficult as there is no available
> documentation for them and you need documentation+spec sheets to write
> device firmware - interesting fact most drives these days have a multi
> core ARM processor.
>
> 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 qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/88a11ba1-8181-16d2-9ddd-245a58805839%40gmx.com.
> For more options, visit https://groups.google.com/d/optout.