Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed
On Sun, 14 Jan 2024 at 19:30, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
> On 11/01/2024 at 12:56, Luca Boccassi wrote:
> >
> > Yes it is a firmware feature, so it depends on the hardware, and in all
> > drives I know of that will be the case, yes. From that point of view,
> > to me it doesn't seem that far away from dm-crypt using the CPU's AES-
> > NI to actually encrypt/decrypt data, or anything else implemented in
> > hardware/firmware that the installer now supports out of the box with
> > non-free-firmware being enabled by default. If I am trusting Intel to
> > handle my data in their wifi firmware, and in their CPU microcode, and
> > memory controllers, and whatever else is on my hardware, it seems
> > strange to start worrying once the line is crossed into the NVME
> > firmware...
>
> Correct me if I'm wrong, but aren't CPUs and wifi controllers
> pass-through devices which do not persistently store encryption keys or
> data and whose encrypted output can be inspected to check if they are
> doing the right thing so that you do not have to blindly trust them ?
>
> Self-encrypted drives persistently store encryption keys and data. Can
> their encrypted output reliably be inspected ? Can they be trusted if
> the manufacturer implemented some hidden mechanism allowing to recover
> the data when customers lost their password (like BIOS manufacturers do)
> which will be leaked sooner or later ?
Most definitely wrong. If your threat model is "hardware vendor will
spend hundreds of millions of dollars to get at me" then your cpu
vendor, memory controller vendor, etc etc can do that too, so you
better not use this nor any other type of hardware acceleration, ever.
The good news is, if you are writing on a Debian bug tracker then you
are not even remotely interesting enough for any hardware manufacturer
to spend even a tiny fraction of that, so it's all good.
Reply to: