Scaleway: Incident SSD was stolen during a secure transport between datacenters

Re:Scaleway: Incident SSD was stolen during a secure transpo... by quietbritishjim on Monday July 26, 2021 @08:49AM (#27958719)

SSDs work in an odd way: they have more capacity than they claim, and when you overwrite some data you're really just writing to some of that spare space while the old version is just marked as free [1, 2]. Admittedly, at that point it's going to be very hard to retrieve the old data (you'd need to bypass the remapping logic presented by the controller circuitry), but it's theoretically possible. If you're paranoid, it's best to rewrite the whole thing even if it's encrypted, ideally several times (at that point a little original data could technically be left over but it's unlikely and it's not going to be feasible to get any of it if it was encrypted).

[1] https://databasearchitects.blogspot.com/2021/06/what-every-p...

[2] https://news.ycombinator.com/item?id=27572218

[ Parent | on HN ]

Re:Scaleway: Incident SSD was stolen during a secure transpo... by tpetry on Wednesday July 28, 2021 @08:47AM (#27983086)

If you only ever write encrypted data to the disk you don‘t care about spare ssd cells. The data was always encrypted you wouldn‘t even need to format before giving away.

[ Parent | on HN ]

Re:Scaleway: Incident SSD was stolen during a secure transpo... by quietbritishjim on Friday July 30, 2021 @07:44AM (#28006909)

In general I'd agree, but the parent comment mentioned "wiping the key part" so I guess they had the assumption that the password is weak enough that its vulnerable while that data is accessible, so I was assuming the same thing. (As you're no doubt aware, the encryption key for full-disk encrypted disks are encrypted by the decryption password and stored on the disk itself, at least when not using a TPM.)

[ Parent | on HN ]