On Sat, Aug 25, 2018 at 3:41 PM, taii...@gmx.com <taii...@gmx.com> wrote:
> On 08/24/2018 11:44 AM, brendan.h...@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.

Sorry but no, that's not true. Do not conflate encryption with
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+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@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.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_DahSiniswOXH_ASEvzBitMxMktQ9vhq7KzNjksN%3DzEdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to