On Thu, 11 Jan 2024 08:46:53 +0000 Holger Levsen <holger@layer-acht.org> wrote: > On Thu, Jan 11, 2024 at 01:47:59AM +0000, Luca Boccassi wrote: > > cryptsetup 2.7.0, currently in experimental, added support for self > > encrypting drives using the OPAL functionality as the encryption layer > > (managed by the kernel, not by the TCG utilities), both in standalone > [...] > > I have added support for these new options in partman-crypto, MR on > > Salsa is open: > > > > https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/7 > > > > The new options are shown only in the manual partitioning mode, and > > only if the kernel, cryptsetup and the device all support this > > functionality, otherwise they are hidden. A factory reset option for > > the disk is also exposed. A small utility to call the required ioctl to > > check for support on a given disk is added too. > > doesnt OPAL functionality rely on the implementation on the hdd/sdd > and thus on non-free software? If so, I'd suggest to warn that it's > impossible to review the security of this. 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... > also see https://wiki.archlinux.org/title/Self-encrypting_drives#Disadvantages The first point is true, however I'm pretty sure it's irrelevant for the threat model of the vast majority of people. If the threat model does include such expensive and sophisticated attacks, then the nested mode can be used, so there's a double layer of dm-crypt + firmware- backed encryption. That's the most visible option of the two in the installer. Or just dm-crypt of course - that's still the default in both 'guided' and 'manual' mode. The second point is no longer true, as there is native kernel support, and the kernel holds the key just like it does for dm-crypt. It affected older setups that didn't use the kernel interface, but only the TCG userspace utilities that talked directly to the drive via the NVME protocol. The third point is true for any hardware, including CPUs and their microcodes, so it seems to me it doesn't add anything new. > I'm not against adding this functionality per se, I just think it should > come with really big warning labels. How about if I changed the Description from: Self-encrypting disk (opal with LUKS2) to something like: Firmware-backed self-encrypting disk (vendor-implemented OPAL with LUKS2) Would that suffice? If not, do you have an alternative wording in mind? -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part