Hacker News Reader

Comment by sprash | Hacker News Reader

Doesn't solve my most important problem with LUKS: Allowing Trim passthrough on SSDs without impacting vulnerability.

Also, why use json for meta-data instead of simple C Structs? No human is supposed to read this kind of data anyways.

> 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.

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.

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.

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.

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.

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

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.

Yes, it can be, and it's already present.

Oops, probably should have checked before asking

Likely for easier future extensions to the metadata without requiring prior agreement among all implementations about how things are laid out.

Is there a good writeup on why this is such a horrific vulnerability? I see a lot of doom and gloom about this without a lot of explanations.

Plausible deniability. For example, from the trimmed sector you can inference that the disk is being used.

Is there really plausible deniability about use of a hard drive that isn't just all zeros (as, AFAIK, they come from the factory)?

I mean, I guess is depends on what burden of proof is needed in the case, certainly if it were balance of probability I'd be surprised if having the disk in a computer looking like it has been written to is sufficient to not make it plausible to deny.

Reply on news.ycombinator.com