Hardware based encryption with SSD's, how is this working in relation to Linux?
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hardware-based encryption: Keep personal files and confidential data restricted from hackers and thieves with AES 256-bit encryption that meets all industry standards, including Microsoft® eDrive, IEEE1667, and TCG Opal 2.0.
I'm wondering how does this work? I haven't setup any additional encryption such as LUKS, and wondering how this protects my data from those "hackers and thieves".
If i disconnect the SSD and plug it into another computer, will the contents be readable? There was no password setup or anything like this. I literally plugged it into my SATA-3 cable, formatted as ext4 and installed Slackware.
Based on what I have read, and I don't claim to be an expert on the subject (and I did said reading about HDDs, not SSDs, but I'm assuming that the methodologies are the same), the SSD encrypts the data with a key that is accessible only to it's circuits until you set one. You can change the password to something only you know, but that must be done in the BIOS. Thus the "Evil Maid" attack is prevented, or rather, made more difficult.
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 5,524
Rep:
There are BIOS schemes to set a password on a hdd. That functionality is built into the drive itself as part of the ATA command set. But it only locks the drive. It doesn't encrypt anything. When the laptop is shut down, it locks the drive with the password that is installed by the user.
On self-encrypting drives, there is an encryption code within the drive. On every shutdown the drive is encrypted. On every boot, the drive is decrypted.
Depending on the motherboard and BIOS, such drives can be locked using the ATA security command set, which makes the drive inaccessible and encrypted until the password is entered, at which point the unprotected internal cipher key will decrypt the drive.
But there is also--on self-encrypting drives--an 'activation' or 'access' key that can be set to protect the cipher key. This is done through BIOS extensions named, OPAL 2.0.
The user password decrypts the activation key which decrypts the cipher key which decrypts the data on the drive.
On each shutdown or power loss, the password must be entered again.
OPAL 2.0 permits many options not offered by simple drive locking, such as multiple passwords for different areas of the drive, so manufacturers can reserve portions of storage for recovery utilities, spyware and hypervisor trojans. Just speculating a bit.
The access passwords can be easily reset, rendering the data on the drive destroyed, but the drive still usable.
In the older ATA security lock scheme, it is possible to issue a secure erase command to erase the drive and unlock it so it can be reused.
To also add in, drive encryption at the hardware or OS level only protects the drive contents (data) if the drive or computer are stolen. It won't prevent data from being stolen in a "hack attack" when the system is running.
To also add in, drive encryption at the hardware or OS level only protects the drive contents (data) if the drive or computer are stolen. It won't prevent data from being stolen in a "hack attack" when the system is running.
I'm already aware of that, as with any encryption such as LUKS, whilst things are open in memory and actively being decrypted, yes any local software can access and read the contents. I'm just confused about built-in encryption, as my UEFI/BIOS doesn't give any sort of option for setting a password to the SSD. In essence i'm failing to understand the point of hardware based encryption if you can't actually protect the data on there.
I had a look a my device listing in the BIOS for any options relating to setting a password for the SSD, but haven't seen anything allowing me to do so.
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 5,524
Rep:
To work, self encrypting drives need a compatible BIOS. But there should still be an option to password protect the drive even if the BIOS doesn't have OPAL 2.0 extensions (self-encrypting drive functionality).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.