4

I want to benefit from HW encryption on a Samsung SSD, meaning I want the SSD controller to handle decryption/encryption. I have 2 SSDs that i want to use, one with Windows, one with Debian. Steps I performed to get hw enc on SSD with Debian:

  1. Enable in SAMSUNG Magician Encrypted Drive. State is now Ready to enable.
  2. Created a USB bootable device in SAMSUNG Magician to perform Secure Erase.
  3. Disabled secure boot in BIOS, performed Secure Erase, re-enabled secure boot.
  4. Used Rufus to create a bootable USB drive with Debian 13.
  5. Set up debian installation with LVM and encryption.
  6. During installation, SSD gets written with random data.
  7. Selected separate partitions for /home /var /temp
  8. Partitions are created, OS files are written to SSD, all good, GRUB is installed also, dual boot works.

Problem: when I boot in windows and check in SAMSUNG Magician the drive with Debian installed, it still reports Ready to enable. If encryption was done properly it would've reported Enabled.

If the topic doesn't belong to unix stackexchange, please tell me where I can post it, thank you.

Improve this question
11
  • 1
    is this for a home computer? what is your pc/server make & model? And RAID card model? Commented Nov 12 at 15:27
  • I don't understand how is that relevant, a z690 MB with a 12th gen intel cpu Commented Nov 12 at 18:08
  • 1
    because it is in the BIOS/EFI, and generally at the RAID card, that will appropriately interface the SATA/SAS controller of a SED to allow functionality of it regarding encryption and being "secured" and "locked" or "unlocked". You could use one of my KPM5WVUG3T84 sed's but you'll never get it to be secured and usable in the manner you expect it to. Commented Nov 12 at 19:29
  • you're not aware of the dirty details surrounding SED's and FDE (full disk encryption) Commented Nov 12 at 19:30
  • 1
    the older enterprise RAID cards like LSI do not; most of the consumer stuff does not last time I bothered to look. So you might be able to use sedutil or hdparm in linux to accomplish such a thing, but then how do you unlock the SED to boot linux to then use sedutil to unlock? at best you would boot and run and a SED that never locks and then be able to use sedutil (which i've never done) to manually unlock a locked SED giving its controller the AK to unlock and then you could read the disk and mount as /data for example. Commented Nov 12 at 19:44

1 Answer 1

Reset to default
7

Set up debian installation with LVM and encryption.

That "encryption" there means software-side encryption :)

Which you can at least verify works; hardware encryption is the drive firmware telling "trust me bro, I've encrypted that safely" with no information on how it did that whatsoever. That goes about as well as you'd expect, i.e., not at all.

Oh, and usually these drives remain unlocked until their power is cut. Which practically means you need a diode and a supercapacitor to be put in your SSD's power supply lines (no protections against that on the hardware side), and then I have a couple of hours to days between the point where you think you've turned off your PC and when your drive cannot simply be removed and put in a different PC. This happening might not be within your threat model, but "attacker enters office and removes storage device or thief steals whole PC" is why I am encrypting my desktop SSDs.

So, you got the safe option there. I'm not sure whether you need anything else!

During installation, SSD gets written with random data.

Hm? no.

You could probably have done all this without the Samsung specific tools just by enabling hardware encryption; that stuff's standardized (imagine a datacenter person having to go and do what you do on the shipment of 10000 SSDs they just received. They'd just buy some other SSDs).

Your vendor tool seems to have enabled self-encryption capabilities (I bet it didn't need to do that, that's just really really standard these days, it just wanted you to take a backup, and helps you prepare a bootable stick to do the encryption dance, and didn't want to explain the finer parts of the procedure, but make sure that users follow a reproducible path). Then, it enabled locking (which is dangerous, and hence a separate step: locking and forgetting the key means your drive is toast; which is the point).

Quick check: Install sedutil and run

sudo sedutil-cli --isValidSED /dev/nvme0n1

(replace nvme0n1 with the device name (not partition name!) of your drive, check lsblk's top level entries if in doubt)

This should print the device name.

Improve this answer
4
  • > That "encryption" there means software-side encryption Debian installer actually supports using hardware encryption now: bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060422 But it's a hidden "expert" option, the default is still software encryption only. Commented Nov 12 at 14:40
  • "Hm? no." Ahm this is what the live USB is reporting Commented Nov 12 at 18:05
  • Now I'm very confuzzled. Also it takes around 20-30 minutes aaaand i can see in samsung magician that there were 14 TB of written data, from approx 6 installations, so writing random data is actually very plausible. It cannot be only from writing OS data since that is like what, 20-30 GB per inst? Commented Nov 12 at 18:15
  • 2
    The installer does indeed write random data all over the volumes being encrypted. Commented Nov 12 at 19:34

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.