Arch Linux

amr962

Member

Registered: 2021-02-11

Posts: 52

Enable self encryption on an existing installation

I have Arch installed on a MX500 SSD and I wish to encrypt it. I've read on the wiki that the drive needs to be securely wiped prior to software-encrypting it, to avoid deleted and unencrypted files from being recovered. I am wondering if this is also the case with hardware encryption, as SSDs are stubborn targets for secure wiping this would be a much easier option than doing software encryption.

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,491

Re: Enable self encryption on an existing installation

It's not the same. Wiping via the SSD hardware encryption basically does the same as the cryptsetup erase command for LUKS devices. However, if you really need to securely wipe your whole drive, depends on your own requirements for data safety.
I'd approach it as follows: if you want to do a fresh install for the encrypted drive, wiping it prior does take a little time to run (~2 hours) but then the drive is set forever. If you plan to encrypt the existing install in place, you can still securely wipe the free space once the encryption is done.

amr962

Member

Registered: 2021-02-11

Posts: 52

Re: Enable self encryption on an existing installation

The wiki suggests clearing memory cells and then securely wiping when dealing with SSDs. Which is only done on a fresh install. But what I'm wondering is, if one is still able to use file recovery software on hardware encrypted drive, as the wiki doesn't say that specifically for hardware encryption. If not hardware encryption could be the better option, as it would take much less time and offer almost the same protection except for the firmware backdooring.

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,491

Re: Enable self encryption on an existing installation

The dm-crypt article you quote deals with software encryption. But I misunderstood your intention a bit, yes. Fair enough reasoning.
Please see the first link I posted for the article dealing with SSD hardware encryption (OPAL). In it you will find links to articles which researched different SSD vendors hw encryption. Your drive manufacturer did not fare bad, if I remember them right. Nonetheless, don't forget to consider some practical points too: e.g. will your hw decyption work, if you have to move the drive to another machine? What is the hw implementation state for suspend (S3) - if you need it?

frostschutz

Member

Registered: 2013-11-15

Posts: 1,648

Re: Enable self encryption on an existing installation

https://www.crucial.com/support/article … encryption

the encryption is always on, meaning when data is written to the SED it is encrypted by the controller and then it is decrypted when read

but if you don't set a password, then it just decrypts for everyone

so if you want to use the hardware encryption, you're already using it, you just need to enable the password security part of it

for software encryption (LUKS) you might have to backup all files, clear old data from the SSD (blkdiscard should be sufficient, otherwise secure erase), then set up LUKS and restore from backup

if you are going to be allowing discards, you don't need to fill the SSD with random data - it would turn back into zero with the next trim anyway

amr962

Member

Registered: 2021-02-11

Posts: 52

Re: Enable self encryption on an existing installation

So, after some time I've decided to do software encryption on just the root partition: Erased my SSD with hdparm, wiped and then reinstalled.

As for the compatibility of hardware encryption on other devices I couldn't find much info except here.
Wikipedia says SEDs are vulnerable to vendor lock ins, which is no surprise.
All of this combined with the firmware backdooring I mentioned before made me choose software over hardware encryption.

And finally as for my original question, whether is it possible to recover deleted and unencrypted data (prior to setting up an encryption password) from a SED, I still don't the answer to. But if I understood correctly SEDs are supposed to always encrypt and decrypt using their built in master password even if you haven't set a user passphrase yet, so data recovery after setting a user passphrase shouldn't be possible as the old data was also encrypted.

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,491

Re: Enable self encryption on an existing installation

And finally as for my original question, whether is it possible to recover deleted and unencrypted data (prior to setting up an encryption password) from a SED, I still don't the answer to. But if I understood correctly SEDs are supposed to always encrypt and decrypt using their built in master password even if you haven't set a user passphrase yet,

Correct.

so data recovery after setting a user passphrase shouldn't be possible as the old data was also encrypted.

Not Correct.
The user passphrase (talking about SED OPAL standard here; which your MX supports) authenticates the user to unlock the master key for the de/encryption. If there is no user passphrase, there is simply no authentication (from the SSD). Please see again the SED wipe link I posted above. To render decryption impossible, you need to wipe the master key with the respective sedutil command. - This principle is the same with LUKS by the way, i.e. changing the unlock passphrase/key does not invalidate other keys, which can still be used to decrypt the data. The difference with dm-crypt/LUKS is, you have the option to re-encrypt the device with a new master-key, thereby invalidating all old keys (which you cannot do with the SED).

But if you followed the dm-crypt wiping for the whole disc prior to creating the new blockdevices, all is good. (If not, you can still wipe the free space of the installed system, as mentioned before).

amr962

Member

Registered: 2021-02-11

Posts: 52

Re: Enable self encryption on an existing installation

I am clear on the wiping part, I didn't have any type of encryption at first so I just wiped the entire device with dm-crypt after issuing a secure erase command with sedutil.

On the wiki:

These self-encrypting drives can be thought of as having a zero-length password by default that always transparently encrypts the data (similar to how passwordless SSH keys can provide somewhat secure access without user intervention).

If a user wishes to "enable" encryption at a later stage, they are able to configure an authentication key (such as a passphrase) which encrypts the existing data encryption key. The user will then be prompted for their passphrase when decrypting the data encryption key in the future. Crucially, because the existing data encryption key is not regenerated, setting a passphrase allows for the drive to be locked while preserving existing encrypted data on the disk, avoiding the need for the drive to be re-encrypted

Seems to suggest that data is already encrypted using the master key, its just that because there is no user password, it just decrypts and encrypts everything on the fly. So data wouldn't be written in the clear even before setting the password, rendering data recovery software after setting the passphrase useless (without having the pass of course).
I may have simply misunderstood something though

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,491

Re: Enable self encryption on an existing installation

Seems to suggest that data is already encrypted using the master key, its just that because there is no user password, it just decrypts and encrypts everything on the fly. So data wouldn't be written in the clear even before setting the password, rendering data recovery software after setting the passphrase useless (without having the pass of course).
I may have simply misunderstood something though

I was answering your case and assumed that you removed the sed passphrase again, after deciding to use software-encryption.
If you kept your sed passphrase too and know noone accessed the SSD before you set it...ok.