On my hobby machines the HDDs are 100% encrypted. Using MBR Legacy BIOS, not UEFI/GPT. As I consider migrating from mechanical drives to SATA SSDs I am finding combative reading about the lack of any available space to provision extra space for the SSD to use. Some contend that performance of the drive, as well as longevity, are negatively impacted without provisioning. Wondering if anyone reading this is using SATA SSD with 100% FDE? I don't expect you to benchmark your performance just describe IF your SSD is still running and with plenty of spunk? I keep reliable backups so a drive that goes bad in 5 years is no big deal. My HDDs seem to last for at least a decade, but the speeds are slowwwwwww.
Consumer SSDs in high-end price range have some space reserved (Over-Provisioning) that user can't access, so when you see 512 GB on brand-new SSD in reality there is more available space. On lower-end probably it is better to manually reserve some (recommended value range 5%-20%) space by creating partition, trim it once using blkdiscard (if it was used before) and not write any filesystem to it. Just don't use this space for any filesystem, any LVM volume.
Understood. BUT - that presents a security issue to consider. Any SSD/data writes that happen outside of FDE controlled space could be observed by an adversary with physical possession. I need to visualize the "on the fly" encryption that LUKS provides. Any items I type during a session are LUKS encrypted so if an SSD were to enter something in provision space that item should be entered using the hardened encryption key - and not actually be PLAIN TEXT. But is that the case? I imagine it wouldn't matter whether or not the partition (file less) was in the LUKS partition or free standing elsewhere on the disk. ??
My M.2 NVMe SSD, a GPT disk, doesn't have encryption. So my situation doesn't apply to you. There are multiple OS partitions and a data partition on the 1TB SSD. About one third is Free Space (in the partitions) so that is my "over provisioning". At my current rate of writing data, the SSD should last 300 years before it reaches Samsung's write limit.
I have used multiple SSDs with FDE over the years, no issues at all. Note than VeraCrypt on Windows does impact random read performance a lot.(Not sure about VeraCrypt on other OSes.) I have never manually set overprovisioning, but the used SSDs(Crucial) do include some overprovisioning from factory afaik. Yeah I am under the impression the data is always written to disk encrypted, as it is encrypted by the software before the SSD decides where to write it.
The point of this manually reserved space is to not write any data to it. There is no data so what adversary is going to see? Nothing. You have like 80% to 95% of disk encrypted. The rest is just reserved for some internal block reallocation. You do not create any filesystem, LVM volume nor LUKS container. Nothing. You just not write to that space, so SSD controller see these part as free, unused blocks.
Thank you all for continuing this discussion with me. All comments are helpful while I study to see if I like this project. I STILL NEED SOME DIRECTION Brian K ---- I am jealous! I wish my motherboard supported M.2 NVME but its a few years too old. Gen 4 is around 3-4 GPS. I don't need that but I would pay the extra for the drive in a blink if my board handled it. Back to the issue, LOL. Backup and restore: I am scratching my head on SSD and provisioning/wear leveling. Lets look at my current usage. The LVM on LUKS is 100% full on every sector. Of course the OS is only using about 35-40% of the actual space, BUT the drive was "noise filled" before I created the system. If I write my forensic HDD backup to the SSD I assume that means the space usage would obviously include my "noise filled" smoke screen. Lets say I am willing to write this to the SSD and let an open partition elsewhere on the disk remain unused by any filesystem. I may be able to live with that, still thinking about this. Now ---- > how would I backup this new system from the SSD? Since the hardware wear levels, bytes would move around within the space. If I did a forensic backup of the SSD when I came back later to restore using this backup, it would now be OFF ------- No? Any clone software captures a snapshot where the subject is now. Later that snapshot may not work if the SSD has determined some of the space/sectors are no longer being used. So how does that work? Another angle just for consideration: What if I take my current OS (mounted) and spin out an image to an external, which is NOT encrypted. Lets call it a hot image. Then I decide to use SED on the hardware drive. Next I restore the OS from the hot image. I know how to pre-partition and all the other user 101 stuff of course. I'ld have to take a look at how the encryption is actually preformed. I assume this would make backups and restores a piece of cake because they would be "hot image" types, meaning the exact sectors used are not in play, so to speak. Would this move give me better performance too?
I saw that some above are using Crucial SSD. I am fond of them because a few years ago they took the time to fix the firmware vulnerabilities discovered on most SSD's - Samsung, Crucial, and others by the researchers. They took the time to fix their firmware while Samsung's answer was use software encryption - really? What is Crucial's process to use SED if you are using Debian? I am trying to make certain that the hardware drive contains all it needs to create the SED without needing something from the OS such as an encrypting algo, etc..
Quoting myself -LOL This is a great read and helped me alot: https://www.electronicdesign.com/technologies/memory/article/21801488/securing-ssds-with-aes-disk-encryption I especially like the OS-Agnostic aspect of SED!
Afaik the paper on vulnerabilities in SED drives discovered that setting an ATA password is not secure. You will need to use some software to use OPAL 2.0. Afaik there is only one open-source alternative and it does work but hasn't been updated in a long time: https://github.com/Drive-Trust-Alliance/sedutil
I assume you are mentioning/quoting the issues referred to in the article (hundreds across the internet) linked below: https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-let-attackers-bypass-disk-encryption/ That weakness is/was discussed by tons of security websites back in 2017-2019 mostly. BTW - the weakness discussed also included OPAL 2.0. Micron (and others) issued new firmware fixing that blunder/weakness. Micron's new MX500 drives no longer hold this weakness. I haven't researched other vendors because Crucial ended up being my decision in the end. One alarming item in the report from that article was that SSD vendors left the hidden "master password" blank. Very few users were even aware that such a thing existed. Having a blank master password (different than the user password 99% of users see) allowed the drive to be opened with a null entering of the master password. How stupid was that oversight? I can find ZERO research citing any weakness in SED on a current SSD from Micron. Again, not saying they are the best, simply saying I am studying them because they are going to be my storage tool. Of course I will likely employ software encryption for my important stuff. But on a family machine for my users not using banks and such, I am going to simply use SED unless I find something out during my study. One area of weakness that exists/ed is Windows Bitlocker. I only use Linux so this doesn't apply to my application. I didn't spend much time studying it because it doesn't apply to me. If readers are Bitlocker users you may want to spend some time having a look at this. My .02 All of my new parts, drives, trays, etc.. are about 10 days from my mailbox. Until then just reading and studying. I have always been "addicted" to looking under the hood on items I use. My spouse simply shrugs, LOL!
Ah yes I remember nowL the issue was discovered before your linked research, but I see that issue is also discussed there. SEDs, or at least Crucial/Microns are always encrypted but the key is stored in the controller, and automatically decrypts/encrypts everything, so there is no access security. If you enable the SED feature, this would generate a new key linked to the password, so you can only have access with the proper password. The thing was that an ATA password may not actually trigger a new key generation with some manufacterers. So access is blocked by the password and data is still encrypted so directly accessing the flash chips won't work either, however since the encryption key is not linked to the ATA password and bypassing ATA passwords is not that hard, one can access the data on the drive. There was a discussion about this on the Crucial forums and I have also asked Crucial a few times to clarify whether or not that was the case there but they never replied. I see the forums are gone now unfortunately, so I can't find it anymore. But as the linked research shows, I was right, but with the firmware updates, it should now be fixed. One other thing about ATA passwords was that back then, the length of the password was often very limited, to about 8-10 characters I think and also the support for special characters was very limited, if you were lucky enough that your BIOS even supported ATA passwords. If more recent systems allow you to set a long, complex password, that shouldn't be an issue anymore either. EDIT: If someone wants to use hardware encryption on Windows, and doesn't trust Bitlocker, the most common alternative is to use some expensive 3rd party program like WinMagic. If you don't want to buy it or don't trust them either, the opensource sedutil I linked to earlier also works with Windows installations.
I won't use Windows unless I have a requirement that I can't fill with Linux. Hasn't happened in years now as I get better at my linux prowess, LOL. I ordered a stack of Crucial drives so I will experiment on a simple machine when they come. Test: install my LVM on LUKS using Macrium. Piece of cake. Then install a basic Debian where I rely on the SED (again its a family machine with no major stuff on another Crucial). It will be interesting to compare the performance between SED only encryption and my hardened Serpent LUKS running the exact same OS otherwise. If I don't notice a significant difference I'll stick with LUKS. Should be an interesting test and easy as can be since I'll have two SATA SSD's on the same computer running the same OS. I don't care about exacting benchmarks, just a "feel" from driving the two systems. I am certain nobody is going to crack my LUKS (30-40+ characters) so it'll probably stay. Test will determine.
Yes, I also only use the SED on a machine with no important stuff. One advantage of SED is that because the encryption is done by the SSD itself, a malware infection of the PC cannot extract the key from RAM. So ideally, you can use both SED and software encryption, but I have not tried that yet
I am totally loving the incredible speed my SSD's are providing on several different machines. I should have gotten rid of the "spinners" years ago, LOL! I stuck with LUKS encryption 100%. My headers are incredibly hardened from generic. Regarding having my RAM "pawn'd", not too concerned. ALL of my workspace happens in VM's so it would take a breakout to even get a glance at my host. My change of heart from posts above on this thread is because the page loads and system mount takes a "blink of the eye". Why surrender software encryption if the mounts/loads appear virtually instant, LOL! The longest part of the mount is because it takes the CPU 5-10 seconds to "crack" my LUKS container with Serpent and the iterations set so high. That is my thing and not the SSD's fault at all. Once I see the LUKS container opened it is full up and going in about 3 seconds every time. Love it.
