Cryptanalysis of AES on SSD with TRIM enabled

Question

Attack scenario:

SSD physically retrieved from a computer that is turned off. The entire disk is encrypted with AES 256-bit (GNU/Linux, LUKS). The SSD has had TRIM enabled for several years and the file system has seen a lot of use, i.e. a lot of files deleted over time (triggering TRIM). Assume that the key used is sufficiently strong to resist any brute force/dictionary attack.

Cryptanalysis:

As far as I understand it, TRIM aids in cryptanalysis in that it will be known which regions of the device are in use and which are not in use.

But exactly how does the cryptanalysis proceed from here? What kind of attack will be performed? Does the attack have a name? Does it have any realistic chance of success? It would be interesting to know if an attack like this ever succeeded, either in an academic setting or known to have succeeded in the field.

Answer 1

A conceivable attack is inspired by this extract of LUKS On-Disk Format Specification Version 1.1.1, section 1:

A partition can have as many user passwords as there are key slots. To access a partition, the user has to supply only one of these passwords. If a password is changed, the old copy of the master key encrypted by the old password must be destroyed. Peter Gutmann has shown in [Gut96], how data destruction shall be done to maximise the chance, that no traces are left on the disk. Usually the master key comprises only 16 or 32 bytes. This small amount of data can easily be remapped as a whole to a reserved area. This action is taken by modern hard disk firmware, when a sector is likely to become unreadable due to mechanical wear. The original sectors become unaccessible and any traces of key data can’t be purged if necessary.

Assume that a weak or compromised password has been used, then the password changed with hope of restoring security. Due to wear-leveling on the SSD, the master key enciphered using the weak or compromised password may remain physically on the drive, although it is no longer logically mapped. In theory, reading the bare flash in the drive (either physically, or using some undocumented commands that may or may not exist in the SSD firmware, perhaps after loading an instrumented version of that) may allow reading the block(s) still containing the master key enciphered using the weak or compromised password, which in turn trivially breaks the whole encryption. It is hard to tell if the " anti-forensic information splitter " of LUKS can prevent that.

This attack is in theory also relevant in the context of blocks that become bad on traditional hard drives (the original data then becomes logically unmapped while potentially physically there, unless the drive physically erases it after remapping, which is not an advertised feature); but the odds that precisely the block(s) enabling the attack becomes bad are minuscule. The odds are less low with a SSD, especially soon after the password is changed.

TRIM likely impact the odds of the attack to succeed, because it modifies the blocks erased by the wear-leveling algorithm, but I can't tell if that will increase or decrease the odds. I can vaguely imagine algorithms in which the periodical erasing of TRIM makes it unnecessary to use backup means to recover unused space, making it more likely that blocks logically rewritten in seldom rewritten areas still have their former values physically there.

I guess that reading logically-rewritten but still-physically-there blocks in SSD has become a forensic trick for high-value target and some SSD. But I have no indication that the LUKS attack I discuss was ever attempted, much less successful. I would fear, much more, a compromise of password or master key by more traditional means (key-logger, camera, paper backup of password, configuration goof, compromized software, DMA memory grabber..)