- Is it possible to recovery data from SSD, that was secure erased (https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase), by IT or professional data recovery company?
- Does this type of erasing reduce liftime of SSD?
Of the 12 drives we tested, [...] Eight of the drives reported that they supported the ATA SECURITY feature set. One of these encrypts data, so we could not verify if the sanitization was successful. Of the remaining seven, only four executed the “ERASE UNIT” command reliably.
So in 2010/2011, out of 12 commercially available SSDs models 8 advertised that they support ATA Secure Erase, and either 4 or 5 models performed a secure erase. The rest didn't, to varying degrees:
Drive B’s behavior is the most disturbing: it reported that sanitization was successful, but all the data remained intact. In fact, the ﬁlesystem was still mountable. Two more drives suffered a bug that prevented the ERASE UNIT command from working unless the drive ﬁrmware was recently reset, otherwise the command would only erase the ﬁrst LBA. However, they accurately reported that the command failed. The wide variance among the drives leads us to conclude that each implementation of the security commands must be individually tested before it can be trusted to properly sanitize the drive
It would be nice to have more recent data, because SSD designs have changed a good deal since 2011. Sadly I haven't found anything newer.
No on both counts, assuming the implementation is within spec.
Secure erase works through encryption, usually AES. Essentially, everything that is written to the SSD is first encrypted with a master key. This happens all the time, is entirely managed by the device's on-board firmware, and is completely transparent. The master key is randomly generated on the production line.
The problem with erasing an SSD through traditional means is that it requires a lot of write operations, and these degrade the device. In order to combat that issue, secure erase simply changes the master key. This means that the old key is lost, and all data on the disk is automatically unreadable. The new key is then used to store new data.
There are only a few ways to "revert" a secure erase operation:
- Get access to the device before the secure erase happens, and capture the master key from the controller's EEPROM. Though at that point, why not just steal the SSD?
- Break AES in a way that allows full recovery of plaintext in a situation where you have a few hundred gigabytes of arbitrary ciphertext, but not the key.
- Find a bug in the implementation of secure erase that causes the old key to be left on the device somewhere.
None of these are particularly feasible attack vectors. The first two aren't very feasible. Jesper's answer shows that the implementation certainly isn't infallible, though.