1

The LUKS key which I use to secure my SSD was recently compromised, but I'm questioning how effective it would be to change the key, because the LUKS header might not be overwritten. In fact, I wonder whether the only safe procedure in such situations is just to sanitize the SSD! No firmware-based encryption was active.

From an online forum:

If you have an SSD:

Beware that solid-state devices will most likely NOT overwrite the LUKS header, but rather write the new one into another memory cell (due to wear leveling algorithms designed to prolong SSD life). If you're worried about this and have recent-enough backups (as you always should), perform an ATA secure erase of the whole SSD using a live CD and then reinstall Qubes OS. https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

I do not know if there is some way to force it to be deleted or if this is not relevant for recent SSD drives.

If my reasoning above is correct, then the solution is either to destroy the LUKS header (and it won't matter if the encrypted data stays in place), or to re-encrypt the data (and it won't matter if the previous header is compromised). Because it's difficult on SSD's to overwrite specific sections of the disk, I think that the second option is the feasible one. This answer If an old LUKS header with a compromised key is recovered, can it be used to read data? suggests using cryptsetup reencrypt.

Is my train of thoughts correct, and how to implement this, concretely?

Ramhound
  • 41,734
  • 35
  • 103
  • 130
  • If you re-encrypt with a new key, what do you care about the old key? – harrymc Mar 20 '23 at 12:09
  • Thanks for your comment. Can you please make your sentence more clear? I can't make sense as it stands! –  Mar 20 '23 at 12:12
  • Which key you're worried about, the passphrase or the LUKS master key? The later is much less likely to have been compromised. – harrymc Mar 20 '23 at 13:27
  • The passphrase was compromised. –  Mar 20 '23 at 13:36
  • There are many quirks and possibilities here. If they have your password and could have had access to your machine to copy your drive key *then* you might have an issue. If they do not have physical access to the machine, at least before you change the password, then you may be at risk. In theory the disk key is encrypted using your password and changing the password *should* re-encrypt the disk key and invalidate the old password. The SSD flash might still contain the old key, but it should not be accessible via the "normal" SATA interface, they would have to remove the actual flash devices. – Mokubai Mar 20 '23 at 15:07
  • 1
    Unless you are going against a nation-state actor I don't think you need to worry. If they attempt to read the block which once contained your key they will only receive the new one. They would need to remove the flash chips to read them block by block and hope that the one containing they old key was not already erased, or they would need to know how to put your particular drive into [factory access mode](https://blog.elcomsoft.com/2019/01/life-after-trim-using-factory-access-mode-for-imaging-ssd-drives/) in order to try and find it. Both would need physical or prolonged access I think. – Mokubai Mar 20 '23 at 15:16
  • If you really do not trust this old disk, then the only way to guarantee safety is to copy all the data to a new disk and then shred, incinerate or physically destroy the flash chips themselves. TRIMing the whole disk *might* clear the relevant blocks, but you don't have any easy way to know for sure when the particular block that contained the old key might be erased. Leaving it working in that machine would increase the probability over time, but you'll never reach absolute 100% certainty. Better to remove that drive from the equation if it is no longer trusted to hold your data. – Mokubai Mar 20 '23 at 15:32
  • Mokubai, thanks for your comments. Can you please clarify this? If they attempt to read the block which once contained your key they will only receive the new one. –  Mar 20 '23 at 15:35
  • In short the situation is the following: the password is compromised but nobody ever touched the physical machine. So the only way to decrypt the data is to expose the master key, and the only way to do this with the compromised password which has been changed by using luksChangeKey (correct me if I'm wrong, the "key" in this command is the password and not the master key), is to analyse the disk and find the "old slot" with the master-key encrypted by the compromised password. Correct? As to how feasible this is, your sentence which I can't understand (see comment above) might be useful! –  Mar 20 '23 at 15:38
  • 1
    I mean that in the filesystem that operates above the flash transition layer they have little to no access to "old" blocks of data. They would need to bypass the SSD controllers mapping of blocks in order to see the actual data on the flash chips, otherwise all they see is the logical disk that the controller presents to the operating system. If you write the same block of disk in the operating system then to the OS it is "logically" the same block that was written, only the SSD controller knows where the only physical block is/was. – Mokubai Mar 20 '23 at 15:46

0 Answers0