5

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?

Motivated
  • 1,493
  • 1
  • 14
  • 25

2 Answers2

7

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.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 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 '19 at 17:10
  • Yes. If you have FDE or use the encryption, no plain-text will go to the disk. – ThoriumBR Jan 11 '19 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 '19 at 17:21
  • No, TRIM will not write plain text on the disk. Check https://askubuntu.com/a/457642/800622. – ThoriumBR Jan 11 '19 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.. GitHub STOP HELPING ICE Jan 12 '19 at 01:16
7

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.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 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 '19 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 '19 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 '19 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 '19 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 '19 at 17:27
  • If a block of storage was not previously encrypted i.e over-provisioned storage and if data is remapped to an over-provisioned sector, do you mean to say that the block of storage is encrypted before data is written to it? – Motivated Jan 11 '19 at 17:28
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/88147/discussion-between-motivated-and-polynomial). – Motivated Jan 11 '19 at 17:30
  • @Motivated It depends what you mean by "encrypted". All data written to a modern SSD is encrypted regardless of which flash cell it ends up being written to, because of the transparent FDE performed by the disk controller (a chip on the SSD) in order to support ATA Secure Erase. You just never notice it happening because it's transparent to the OS. – Polynomial Jan 11 '19 at 17:31
  • "Secure erase" almost certainly offers no cryptographic security. There is no way to know, without reverse engineering the device firmware, how the key is generated or what RNG is used, and unless the engineers designing it knew their stuff in regards to security, it's unlikely they hooked up any reasonable entropy source to it. I would go so far as to guess that many/most devices perform secure-erase by stepping a LCG with fixed initial-value and using the new output as the key. – R.. GitHub STOP HELPING ICE Jan 12 '19 at 01:12
  • @R.. While that may be true in edge cases, you can look at the datasheets for the ICs in modern Opal drives and see if they contain an integrated HWRNG. I imagine most SED drives use it. – forest Jan 12 '19 at 03:30
  • @forest: Even if they do, there's no guarantee that it's any good or that they're using it properly. Improper usage is endemic **even in software that's relatively easy to review**. There is absolutely no reason, ever, to trust hardware companies and their firmware engineers to get it right. They have proven again and again they won't, and the necessary research to refute that default assumption for a particular piece of hardware is way beyond what's reasonable to perform. – R.. GitHub STOP HELPING ICE Jan 12 '19 at 03:51
  • @R.. That's true. I just think saying that _most_ get it so wrong as to use an LCG is going a bit far. – forest Jan 12 '19 at 03:52
  • @forest: It's not. You have no idea how incompetent the implementors are. Read for example https://www.howtogeek.com/fyi/you-cant-trust-bitlocker-to-encrypt-your-ssd-on-windows-10/ – R.. GitHub STOP HELPING ICE Jan 12 '19 at 04:22
  • @R.. Oh I absolutely know how incompetent they are. I imagine a good chunk of them use ECB. But using an LCG for a random seed is something that's trivially avoidable even without crypto knowledge. If there's a HWRNG present, they'll use that simply because it's _easier_ and _faster_ than implementing a random number generator on their own, even one as trivial as an LCG or LSFR. – forest Jan 12 '19 at 04:24