6 ms·

> Alowing Trim passthrough on SSDs without impacting vulnerability. Unfortunately I don’t think that’s possible. If I scan your encrypted disk and see that 10%

> Alowing Trim passthrough on SSDs without impacting vulnerability. Unfortunately I don’t think that’s possible. If I scan your encrypted disk and see that 10% of blocks are zeroed out, I can assume that your disk is 90% full. So information has been leaked, which is arguably a vulnerability.

saghm 9y ago
Couldn't this be an opt-in feature? For some people, this might be a reasonable trade-off given their threat model
- Denvercoder9 9y ago
  Yes, it can be, and it's already present.
  - saghm 9y ago
    Oops, probably should have checked before asking
- kakarot 9y ago
  Fedora decided with release 27 to enable trim by default on newly created encrypted devices. I was not happy about this decision and try to make some noise but nobody really seem to care. There is a reason that it is disabled by default in the Linux kernel, and making this kind of decision on behalf of the users without any input from the community is pretty fucked up. Personally, I would like to explore the idea of a secure enclave that keeps a map of which blocks are in use that gets referred to during write operations. This seems like a problem that is going to need to be solved with hardware.
sprash 9y ago
This is an engineering problem where tradeoffs have to be made. E.g. You could make it appear that the disk is about 90% full all the time if you queue up the trim commands in some deterministic way. This way you only could determine if the disk is more or less than about 90% full at any time. I think good engineers would come up with something even better. This would be on a level of a nice CS Bachelors/Masters thesis.
sslalready 9y ago
I think TRIM is dangerous not because of information leaks, but because of the risk of IV/nonce reuse when SSD data blocks are unmapped but not cleared. This would pose a risk if someone dumps the raw content of the NAND chips and find two or more data blocks encrypted with the same IV/nonce.
- viraptor 9y ago
  Why does trim make a difference though? You're not going to scan the whole disk on each write for duplicates, so you need to guarantee statistically-unique nonces either way, or make sure reuse doesn't matter. Trim doesn't make this any worse/better.
  - viraptor 9y ago
    After some time, I think I get it. If the key/iv is location-specific, trim may result in an abandoned block which will then be recreated somewhere else. This results in two blocks from the same logical location in two different flash locations. Unless I misunderstand something, the xts mode encryption uses location-based keys.

saghm 9y ago

Couldn't this be an opt-in feature? For some people, this might be a reasonable trade-off given their threat model

Denvercoder9 9y ago
Yes, it can be, and it's already present.
- saghm 9y ago
  Oops, probably should have checked before asking
kakarot 9y ago
Fedora decided with release 27 to enable trim by default on newly created encrypted devices. I was not happy about this decision and try to make some noise but nobody really seem to care. There is a reason that it is disabled by default in the Linux kernel, and making this kind of decision on behalf of the users without any input from the community is pretty fucked up. Personally, I would like to explore the idea of a secure enclave that keeps a map of which blocks are in use that gets referred to during write operations. This seems like a problem that is going to need to be solved with hardware.

sprash 9y ago

This is an engineering problem where tradeoffs have to be made. E.g. You could make it appear that the disk is about 90% full all the time if you queue up the trim commands in some deterministic way. This way you only could determine if the disk is more or less than about 90% full at any time. I think good engineers would come up with something even better. This would be on a level of a nice CS Bachelors/Masters thesis.

sslalready 9y ago

I think TRIM is dangerous not because of information leaks, but because of the risk of IV/nonce reuse when SSD data blocks are unmapped but not cleared. This would pose a risk if someone dumps the raw content of the NAND chips and find two or more data blocks encrypted with the same IV/nonce.

viraptor 9y ago
Why does trim make a difference though? You're not going to scan the whole disk on each write for duplicates, so you need to guarantee statistically-unique nonces either way, or make sure reuse doesn't matter. Trim doesn't make this any worse/better.
- viraptor 9y ago
  After some time, I think I get it. If the key/iv is location-specific, trim may result in an abandoned block which will then be recreated somewhere else. This results in two blocks from the same logical location in two different flash locations. Unless I misunderstand something, the xts mode encryption uses location-based keys.