[SOLVED] SSD Hardware encryption

guagno333 · 2016-06-23 14:07:22

Hello.

I have a Samsung 850 EVO, that as many of you may know, supports hardware encryption. I'd like to know how to take advantage of this, since I have really no idea. I searched online for info, but all I had is more confusion on my head. If it can help, my motherboards supports TMP 2.0. Any help?

Thanks in advance

Last edited by guagno333 (2016-09-15 08:29:19)

Durden · 2016-06-23 14:38:19

Try this:
https://askubuntu.com/questions/506556/ … ng-840-evo

guagno333 · 2016-06-23 14:49:29

I do not have a HD password option in BIOS. However I found https://wiki.archlinux.org/index.php/Se … ing_Drives shortly after writing the post but it doesn't compile. Does anyone have any experience with it?

frostschutz · 2016-06-23 14:49:31

Don't lock yourself out... (don't use hdparm to set the password)

If your CPU has AES-NI, you can use LUKS/AES encryption without penalty too (or at least it's not noticable in any way).

guagno333 · 2016-06-23 18:10:35

To use LUKS/AES I have to reinstall, right? Can I ask the reason of "don't lock yourself out"? I see that your comment is 2 seconds after mine, and I didn't read that... And now I managed to set it up with sedutils....

frostschutz · 2016-06-23 18:34:53

guagno333 wrote:

Can I ask the reason of "don't lock yourself out"?

People have set ATA passwords with hdparm before, only to realize after reboot that the BIOS did not actually permit them to type it (due to keyboard layout, or different password length restrictions). As a result the disk is "bricked" (until you find a way to hotplug it to get things going again).

guagno333 · 2016-06-24 14:45:34

frostschutz wrote:

guagno333 wrote:
Can I ask the reason of "don't lock yourself out"?
People have set ATA passwords with hdparm before, only to realize after reboot that the BIOS did not actually permit them to type it (due to keyboard layout, or different password length restrictions). As a result the disk is "bricked" (until you find a way to hotplug it to get things going again).

That's almost what I di with sedutils! Fortunately I realized it (thanks also to the article I was reading) and I used a simpler password

GSF1200S · 2016-06-24 20:31:49

guagno333 wrote:

To use LUKS/AES I have to reinstall, right? Can I ask the reason of "don't lock yourself out"? I see that your comment is 2 seconds after mine, and I didn't read that... And now I managed to set it up with sedutils....

Well, yes and no. Ideally on an SSD youre going to want to do a secure erase of the drive using Samsungs Magician software (I just did that recently on an 840 Pro). Erasing the data even using wipe or shred will simply cause the SSD to spread the writes around for wear-leveling and could leave data recoverable by forensics.

You could fairly easily rsync the data/install off the SSD, perform a secure erase, setup your partitions (including creating the Luks partition), then rsync the data back onto the encrypted luks container/filesystem on that container. You will need to edit /etc/mkinitcpio.conf, /etc/crypttab, /etc/fstab, /etc/default/grub (if you use grub), and regenerate the initramfs image. Its not too hard- I did it a few weeks ago and the biggest pain for me was grub. See the dm-crypt Arch wiki for instructions on this.

I used AES-xts plain64 512bit, which actually turns out to 256bit AES encryption, along with sha256 and an iter time of 2000. I can discern zero difference compared to when I ran without encryption. I have an intel i7 3820QM quad-core and 16GB of RAM (though I dont think RAM matters much).

If youre really brave you could prolly install libreboot or coreboot firmware in place of your factory firmware to gain harddrive encryption, but that can be pretty involved. Fortunately for me my UEFI/bios offers a password for the hard drive, so I have hardware and software encryption with no discernible difference in performance. Both our SSD drives are SEDs (self-encrypting drive), so basically they are always encrypting- it costs you zero performance to enable the hardware encryption when your UEFI/bios supports it.

guagno333 · 2016-06-25 09:08:24

GSF1200S wrote:

guagno333 wrote:
To use LUKS/AES I have to reinstall, right? Can I ask the reason of "don't lock yourself out"? I see that your comment is 2 seconds after mine, and I didn't read that... And now I managed to set it up with sedutils....
Well, yes and no. Ideally on an SSD youre going to want to do a secure erase of the drive using Samsungs Magician software (I just did that recently on an 840 Pro). Erasing the data even using wipe or shred will simply cause the SSD to spread the writes around for wear-leveling and could leave data recoverable by forensics.
You could fairly easily rsync the data/install off the SSD, perform a secure erase, setup your partitions (including creating the Luks partition), then rsync the data back onto the encrypted luks container/filesystem on that container. You will need to edit /etc/mkinitcpio.conf, /etc/crypttab, /etc/fstab, /etc/default/grub (if you use grub), and regenerate the initramfs image. Its not too hard- I did it a few weeks ago and the biggest pain for me was grub. See the dm-crypt Arch wiki for instructions on this.
I used AES-xts plain64 512bit, which actually turns out to 256bit AES encryption, along with sha256 and an iter time of 2000. I can discern zero difference compared to when I ran without encryption. I have an intel i7 3820QM quad-core and 16GB of RAM (though I dont think RAM matters much).
If youre really brave you could prolly install libreboot or coreboot firmware in place of your factory firmware to gain harddrive encryption, but that can be pretty involved. Fortunately for me my UEFI/bios offers a password for the hard drive, so I have hardware and software encryption with no discernible difference in performance. Both our SSD drives are SEDs (self-encrypting drive), so basically they are always encrypting- it costs you zero performance to enable the hardware encryption when your UEFI/bios supports it.

Thank you, the explanation was great However I think I managed to enable the SSD encryption by using sedutil here: https://wiki.archlinux.org/index.php/Se … ing_Drives.

There's a couple of drwaback thou, I can't put on sleep the system (it is not suppoerted by sedutil) and the system needs to but twice, since the first time the Pre Boot Authentication environment is shown to allow to enter the password, but everything is working pretty fine and the SSD in encrypting evertyhing, since with a live CD the drives are not accessible.

I'll bookmark this post in case I decide to turn off sedutil and to go on with the LUKS method

Arch Linux

#1 2016-06-23 14:07:22

[SOLVED] SSD Hardware encryption

#2 2016-06-23 14:38:19

Re: [SOLVED] SSD Hardware encryption

#3 2016-06-23 14:49:29

Re: [SOLVED] SSD Hardware encryption

#4 2016-06-23 14:49:31

Re: [SOLVED] SSD Hardware encryption

#5 2016-06-23 18:10:35

Re: [SOLVED] SSD Hardware encryption

#6 2016-06-23 18:34:53

Re: [SOLVED] SSD Hardware encryption

#7 2016-06-24 14:45:34

Re: [SOLVED] SSD Hardware encryption

#8 2016-06-24 20:31:49

Re: [SOLVED] SSD Hardware encryption

#9 2016-06-25 09:08:24

Re: [SOLVED] SSD Hardware encryption

Board footer