Inline encryption for filesystems

Posted Aug 28, 2019 13:14 UTC (Wed) by grove (guest, #1721)
In reply to: Inline encryption for filesystems by markh
Parent article: Inline encryption for filesystems

I don't see a need to be "horrified by this". It's a way to make a feature available in some modern hardware available to the end user. If you don't trust all the hardware your information will have to pass through to use this, you should abstain from using that feature of your hardware.

For that reason (and probably a couple more) I don't expect the pure software encryption options will go away (we are too many who can see the problems in giving secret information to our hardware), but allowing others to use this feature of their hardware seems fine.

Inline encryption for filesystems

Posted Aug 28, 2019 15:02 UTC (Wed) by iabervon (subscriber, #722) [Link] (2 responses)

Even so, the API shown has a surprising number of methods that take key data and seems to be using the key data itself as the identifier of the key, rather than something less secret. Will keyslot_find be implemented in a way that doesn't leak bits of other keys via timing attacks or leave key bits beyond the end of the stack or in memory that could be reused uninitialized?

Inline encryption for filesystems

Posted Aug 29, 2019 2:35 UTC (Thu) by ebiggers (subscriber, #130760) [Link] (1 responses)

Yes, the code always uses constant-time comparisons when comparing keys, and always zeroizes keys when they're no longer needed.

We could try to implement something fancy where the keyslot manager only remembers a cryptographic hash of each programmed key. But that would add extra overhead, and for now wouldn't truly buy us anything since the key still needs to be in kernel memory anyway, in case it needs to be programmed into a keyslot again.

Inline encryption for filesystems

Posted Aug 29, 2019 5:19 UTC (Thu) by iabervon (subscriber, #722) [Link]

Is there a single keyslot manager? I thought that was going to be up to each driver to implement, with the risk that some drivers wouldn't do as good a job of it as the implementation in the original patch set.

Why not remember a struct key * instead of the data directly? It'd still be a pointer to the secret in kernel memory, but my impression is that they're not generally duplicated, so you could do all your management based on pointer equality, and leaking the values that have to be in your data structures to userspace would be less immediately bad.

Inline encryption for filesystems

Posted Aug 28, 2019 15:09 UTC (Wed) by markh (subscriber, #33984) [Link]

Trust is important but not the only concern; it is also about greatly increasing the attack surface. It's a lot easier to find a vulnerability if there are several possible software and hardware layers to choose from, many of which were not even designed with security in mind. It is only necessary to find a single weak spot to exploit.