Proxmox Full Disk Encryption with ZFS Raid1 on LUKS | A couple last questions

[esi_y]

From my limited knowledge on the topic and a bit of ignorant digging, SED is generally considered insecure. SED is not standardised between manufacturers and not implemented with all security standards' requirements so easily broken. Basically it's something to avoid.

If you need a "certified" security, some of the SED drives has offered that for a while too:
https://www.seagate.com/files/www-c...on/en-us/docs/faq-fips-sed-mb605-2-1302us.pdf

SED is (from what I have encountered always) an implementation of AES, which is not unlike your typical LUKS deployment would provide, if you need it to comply with e.g. FIPS, a manufacturer would give you an idea what you are procuring, especially for that "datacentre" feel:
https://apac.kioxia.com/en-apac/business/ssd/solution/security.html

If there's been any instances of a major manufacturer's non-FIPS SED having been compromised, feel free to link it through here.

 

[Stereoscope]

This was the most compelling argument against them that I found:

https://www.reddit.com/r/sysadmin/comments/zg2wza/sed_drives/

 

[esi_y]

This was the most compelling argument against them that I found:

https://www.reddit.com/r/sysadmin/comments/zg2wza/sed_drives/

They are probably valid points, but some come from misunderstanding of the SED implementation (e.g. the data is encrypted and that provides cryptographic erase capability (so one can do nvme format /dev/xxx–-ses=2 before discarding or repurposing them (e.g. to a different customer).

Of course if you want it to be secure against e.g. (offline) theft, you would need to involve boot time password or better yet, TPM. I agree on the points with AES-NI, etc. but if you have lots of drives, you do not really want your CPU be used for assisting that data encryption at all.

Referencing reddit warriors, you might want to have a look at this thread as well:
https://www.reddit.com/r/Proxmox/comments/16q4ctk/selfencrypting_drives_auto_unlock_and_tpm/

With ZFS dataset encryption, are you unlocking it manually remotely every time after boot (on each node)? What happens (not only) in HA scenario when such node wants to e.g. watchdog reboot?

 

[Stereoscope]

How does TPM protect against offline theft? If you steal the whole box, the TPM comes with the box, doesn’t it?

 

[esi_y]

How does TPM protect against offline theft? If you steal the whole box, the TPM comes with the box, doesn’t it?

I took the liberty to make an assumption that offline theft means of the drive (or drives) itself. If you steal the whole box (imagine walking out of a datacentre with 2U like that) then you have entirely different problem. Does everyone concerned about this have dropbear on their boxes today?

 

[Dunuin]

Does everyone concerned about this have dropbear on their boxes today?

Here, yes. All you have to do to steal my server is to break a window. No tools or ladder are required. You don't even have to enter the building, you could grab it from outside and pull it through the window. You just need some muscles because those servers are fully populated 4U chassis.
Luckily they never broke into my apartment yet but 7 times at the neighbour next door.

And for auto unlocking, you could hide a Raspberry Pi Zero somewhere and let that unlock all the PVE nodes. Autounlocking via dropbear works great via a simple expect script: https://forum.proxmox.com/threads/a...ypted-pve-server-over-lan.125067/#post-546466
Ideally the machine doing the autounlocking is encrypted too and requires a passphrase for unlocking it. But not a big problem in case of theft. If you unplug in from the UPS to steal it it will be locked again. Just make sure to set up NUT to shutdown all nodes after running some seconds on battery so they will be shut down in case they try to steal the whole rack including the UPS

 

[Stereoscope]

Like Dunuin said, not all servers are locked away in secure data centres.
Yes, I've heard of the Raspberry Pi Zero trick.

 

[justinclift]

If there's been any instances of a major manufacturer's non-FIPS SED having been compromised, feel free to link it through here.

From rough memory, there have been a few instances of security researchers looking into self encrypting drives and finding critical flaws in their implementation.

Some quick searching turns up these:

• https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-let-attackers-bypass-disk-encryption/
• https://threatpost.com/academics-find-critical-flaws-in-self-encrypting-hardware-drives/115103/

The easily findable stuff by me just now seems to be dated 2015, 2018, and 2019. Not seeing anything obvious from 2022, 2023, nor 2024.

---

The general thought pattern though much of the discussion about this stuff that I'm seeing (and I suspect is true) is that the manufacturers issued patches for the specific implementation flaws found above, but probably didn't change anything about their development practises to ensure future flaws don't happen.

---

Oh wow. Samsungs consumer website is super ironic in regards to this for their self encrypting drives:

Consumer Notice regarding Samsung SSDs​

https://semiconductor.samsung.com/consumer-storage/support/notice/

In light of recent reporting for potential breach of self-encrypting SSDs ... [We] recommend installing encryption software (freeware available online) that is compatible with your system.

That quote only applies to "non-portable SSDs" though, but those are pretty common in entry level homelabs.

 

[esi_y]

All you have to do to steal my server is to break a window

This would be true for most home uses, but physical security and data at rest do not exactly offset each other.

Autounlocking via dropbear works great via a simple expect script: https://forum.proxmox.com/threads/a...ypted-pve-server-over-lan.125067/#post-546466

I appreciate the ingenuity, I remember e.g. some cryptsetup versions allowed for a shell script to be referenced from a line of crypttab, others only keyfile (which could be perhaps fetched into ramdisk prior), so that would allow for less hacky approach even. I would discount the locally "hidden" SBC because if it's cable-connected then it's not really secure against attacker that targets the data and if it was e.g. WiFi it is just a bit more obscure and unreliable. I can still imagine the keys to be located outside over e.g. VPN. Even in that case (as in all previous), you are however inherently open to attacks over the network (which are more likely to target the data than resale equipment value) that have all the keys at their disposal.

Ideally the machine doing the autounlocking is encrypted too and requires a passphrase for unlocking it.

Or if it's remote it can simply deny key access at any point later as it is more likely under your control.

But not a big problem in case of theft.

The whole issue with the elaborate setup above I have is that it fails to address real threat scenario. Namely, if you have such kind of material stored on the nodes that would require this, then it's most certainly insufficient for the very reason that they are plaintext accessible even when not absolutely necessary. That is then the actual issue.

If you unplug in from the UPS to steal it it will be locked again. Just make sure to set up NUT to shutdown all nodes after running some seconds on battery so they will be shut down in case they try to steal the whole rack including the UPS

And that issue will not be inherently solved by adding this kind of complexity which is, let's admit it, at the expense of availability, e.g. the whole point of UPS setup is to be able run even hours off-grid.