My understanding is that flash based devices such as SSDs are over-provisioned and do not advertise the additional blocks of storage available to the operating system. The over-provisioned blocks of storage is to support effective distribution of data via wear leveling.

Assuming my understanding is correct, how does full disk encryption cater for over-provisioned of storage if the additional block of storage isn't advertised or accessible by the operating system?

If the distribution of data is limited to the drive's controller, is there a risk of data flowing from encrypted blocks to unencrypted blocks e.g. over-provisioned storage?


If you encrypt the disk from the start, when you first start using it, then this isn't a problem. All data you write is encrypted and remapped sectors just lead to encrypted data being remanent on the over-provisioned area. Since the data is encrypted, you can't do anything with it even if you recover it using direct flash reads on a disassembled SSD.

Furthermore, identifying where that data came from in the encrypted stream is particularly difficult, and since most FDE block cipher modes (e.g. XTS) include the sector number (or some other position value) as part of the initialisation vector it becomes exceedingly difficult to recover plaintext from those remanent sectors even if you are in possession of the FDE master key.

On top of that, most SSDs implement the ATA Secure Erase feature. This feature allows you to send a single command to safely erase the disk without needing to write over every sector. Overwriting sectors is costly as flash cells have limited write cycles. This feature works by transparently encrypting all sectors using a randomly generated key which is stored in the disk controller's nonvolatile memory. When you run the ATA Secure Erase command, the disk controller discards the old key and generates a new one. This instantly makes all data on the disk unreadable. As a side-effect, all over-provisioned areas are also encrypted this way, meaning that even without using your own FDE on the SSD the over-provisioned areas are still encrypted and difficult to recover even if you extract the Secure Erase master key from the controller's nonvolatile memory. If you later do a Secure Erase command, the overprovisioned areas become unreadable too.

  • Can you further elaborate on "difficult to recover plaintext from those remanent sectors even if you are in possession of the FDE master key."? What do you mean by the inability to recover plaintext if someone is in the possession of the master key? I would have thought that if someone possess the master key, all bets are off. – Motivated Jan 11 at 17:18
  • @Motivated SSD remapping works by maintaining a table of logical sectors (i.e. the sectors that the OS sees) to physical flash cells. Think of it like a pagetable. This table is constantly changing in order to distribute writes to different sectors in order to do proper wear-levelling. It also allows cells to be blacklisted when they go bad, so that the disk can continue working. When a sector is remapped to new cells, there's no left over metadata to say which sector the old cell was mapped to. So you don't know where in the (hundreds of GB!) encrypted data stream the data in that cell was. – Polynomial Jan 11 at 17:22
  • @Motivated FDE block encryption modes use the logical sector number (or other similar stream position information) to ensure unique initialisation vectors (IVs) for each chunk of encrypted data. This number is required to be known during encryption in order to properly decrypt the data. If you don't know where the data came from, you can't properly decrypt it. Some weaker FDE block modes may allow you to recover one block (128 bits) of data per sector without knowing the IV, but better block modes (e.g. XTS) do not allow for this to happen. – Polynomial Jan 11 at 17:26
  • Do you mean that since the operating system is maintaining a logical map of the mappings of data written to physical flash cells that when data is remapped it is impossible to determine the encrypted previous data stream? – Motivated Jan 11 at 17:26
  • 1
    @Motivated The disk controller does it, not the operating system. The OS has no overview or control over the cell mapping process (aside from advising a total amount of over-provision space to be reserved, on some disks), nor does it take part in the transparent disk encryption that occurs as part of the ATA Secure Erase feature. – Polynomial Jan 11 at 17:27

FDE does not need to know anything about overprovisioning. If the partition is encrypted, no plain-text will ever be written anywhere. Blocks reserved for wear leveling will either have un-initialized random data, or encrypted blocks.

If you are using the encryption provided by the controller, encryption/decryption occurs inside the controller, so no plain text data is written on the blocks. If the encryption is done by the OS, the controller already receives encrypted data.

  • Do you mean to say that unencrypted data can never be written to overprovisioned blocks of storage if using full disk encryption and/or encryption offered by the drive controller? – Motivated Jan 11 at 17:10
  • Yes. If you have FDE or use the encryption, no plain-text will go to the disk. – ThoriumBR Jan 11 at 17:17
  • My understanding is that TRIM can result in data leakage and this can be written in plain text to disk which may end up in over-provisioned blocks of storage. – Motivated Jan 11 at 17:21
  • No, TRIM will not write plain text on the disk. Check askubuntu.com/a/457642/800622. – ThoriumBR Jan 11 at 17:28
  • "Encryption offered by the drive controller" is not FDE in any meaningful sense of the term. There are no verifiable security properties without reverse engineering hardware, and those who have done such RE'ing have found all the devices they tested laughably broken. For practical purposes, a system can only be called FDE if plaintext is never exposed to the drive controller or bus over which it's connected. – R.. Jan 12 at 1:16

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.