LWN: Comments on "Inline encryption for filesystems"

Inline encryption for filesystems

robert_s — Sun, 01 Sep 2019 18:15:09 +0000

It would be many orders of magnitude harder to do this and not "get caught" at any point in the product's lifetime.

Inline encryption for filesystems

ssmith32 — Sat, 31 Aug 2019 06:03:48 +0000

And I just sent a colleague Ken Thompson's trusting trust (to point out you need to trust the writers of software *cough* bitcoin *cough*, there's no magic algo that makes it go away altogether..).

Makes me smile that the paper stays relevant after all the years...!

Final paper

CChittleborough — Thu, 29 Aug 2019 13:28:47 +0000

Here's the final paper, from the 40th IEEE Symposium on
Security and Privacy:
https://www.ieee-security.org/TC/SP2019/papers/310.pdf

Not good news.

Inline encryption for filesystems

LtWorf — Thu, 29 Aug 2019 11:02:13 +0000

Yes but building a CPU that understands what is a key and what isn't is a bit complicated. If you have an instruction "set key" it's all suddenly very very easy.

Inline encryption for filesystems

iabervon — Thu, 29 Aug 2019 05:19:01 +0000

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

Cyberax — Thu, 29 Aug 2019 03:09:21 +0000

It's a bit more difficult with AES-NI. You have to somehow store the keys at a pretty good rate, and there's simply not enough space on the CPU die for this.

But storing a handful of keys supplied for decryption of fairly large blocks of data? Easy.

Inline encryption for filesystems

ebiggers — Thu, 29 Aug 2019 03:02:56 +0000

Sure, and the CPU could do the same when it sees an AES instruction.

Ultimately, you always need some level of trust in the hardware...

Inline encryption for filesystems

ebiggers — Thu, 29 Aug 2019 02:35:46 +0000

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

ebiggers — Thu, 29 Aug 2019 02:14:56 +0000

As noted by another commenter, you need to trust the SoC vendor anyway.

I'll also note that inline encryption is, effectively, already standard practice on mobile devices. All iOS devices use it, and currently the major Android SoC vendors are providing their own inline encryption solutions, including out-of-tree kernel patches, which are already used on most new mid to high end Android devices.

It will be much better to have vendor-independent, well-reviewed, and well-tested upstream Linux kernel code to support inline encryption, and common tests that everyone has to pass, rather than continue the status quo of everyone using their own out-of-tree patches.

Usual vendor-firmware levels of quality and trustworthiness

ebiggers — Thu, 29 Aug 2019 01:38:27 +0000

Self-encrypting drives normally take a password, which can be changed later; they don't take the encryption key directly. Therefore, they have to implement key generation and wrapping themselves --- which is where the vulnerabilities actually are. It also means that software can't test the encryption for correctness.

Inline encryption hardware is different, since for standards complaint (e.g. UFSHCI 2.1) inline encryption hardware, software provides the encryption key(s) directly. Thus, the hardware doesn't do any key generation or wrapping, and the results can be compared with a software implementation.

So it's simply not possible to screw up the UFSHCI 2.1 crypto in the same ways that ATA Security and TCG OPAL self-encrypting drives have been screwed up. And if someone does nevertheless screw it up somehow, it's easily detectable by some basic comparison tests, unless the vendor *really* went out of their way to very deliberately do something malicious.

Inline encryption for filesystems

ebiggers — Thu, 29 Aug 2019 01:02:48 +0000

Inline encryption has been part of the UFSHCI standard since 2016. See the patchset, which adds support for it to Linux's UFS host controller driver.

Inline encryption for filesystems

mjg59 — Wed, 28 Aug 2019 15:20:27 +0000

Using this for devices where the storage is replaceable is already a bad idea - you've then got unencrypted information going over a bus that's trivial to interpose.

Inline encryption for filesystems

markh — Wed, 28 Aug 2019 15:09:16 +0000

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.

Inline encryption for filesystems

iabervon — Wed, 28 Aug 2019 15:02:26 +0000

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

grove — Wed, 28 Aug 2019 13:14:13 +0000

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.

Usual vendor-firmware levels of quality and trustworthiness

hmh — Wed, 28 Aug 2019 12:03:03 +0000

Required reading:

https://www.ru.nl/publish/pages/909282/draft-paper.pdf

I am not sure I would trust the SoC vendors would do any better than the SSD vendors named in the paper.

Inline encryption for filesystems

juliank — Wed, 28 Aug 2019 10:47:11 +0000

This does not apply to devices where the storage is replaceable.

Inline encryption for filesystems

mjg59 — Wed, 28 Aug 2019 07:45:54 +0000

The controller is on the SoC. If the SoC vendor can't be trusted, there are any number of ways they can extract private data already.

Inline encryption for filesystems

markh — Wed, 28 Aug 2019 07:38:56 +0000

Am I the only one that is horrified by this?

I thought it would be common sense to expect that encryption keys and plaintext would be restricted to the minimum number of layers possible, and that certainly under no circumstances would encryption keys be sent through several software and hardware layers to another possibly external device with its own proprietary firmware. This seems like the perfect architecture, if your goal is to enlarge the attack surface well beyond the ability of any one entity to manage, and maximize the number of potential interception points where keys or plaintext can be stolen.

I really hope that I'm missing something and this is not as bad as it sounds.

Inline encryption for filesystems

sbates — Wed, 28 Aug 2019 02:13:10 +0000

AFAIK there is no vendor-neutral interface into the engines (compression, encryption etc) that some of these SSDs provide. There is some activity within SNIA to try and remedy this situation and define said interfaces for at least some of the most common engines. The expectation is that this would feed into standards like T10 and NVM Express. However that's going to take time and then the vendors will need to produce product that aligns to those standard interfaces.

https://www.snia.org/computational

Inline encryption for filesystems

quotemstr — Wed, 28 Aug 2019 00:24:26 +0000

Yeah, but that approach doesn't help you win on benchmarks.

Inline encryption for filesystems

Cyberax — Wed, 28 Aug 2019 00:22:52 +0000

Even better, store all the keys and give them out if presented with a special NSA_HERE packet.

Inline encryption for filesystems

quotemstr — Tue, 27 Aug 2019 23:58:58 +0000

Oh, wait. Never mind. The controller can lie regardless, can't it? That is, can't it just store the plaintext and encrypt the data on the fly when you read back the "raw" contents?

Inline encryption for filesystems

quotemstr — Tue, 27 Aug 2019 23:58:00 +0000

> read back the encrypted content and verify that the controller is encrypting in the expected manner.

Preferably after a power cycle so the controller can't lie.

Inline encryption for filesystems

theonewolf — Tue, 27 Aug 2019 22:06:29 +0000

Ah, you might be right on that. I haven't explored this deeply (honestly haven't ventured much into Opal).

I don't know about reading the raw data back!

Inline encryption for filesystems

mjg59 — Tue, 27 Aug 2019 22:04:07 +0000

The distinction is (to my understanding) the degree of control that the OS has over the encryption. In the Opal case, all that's exposed to the OS is the session management and authentication for encrypted regions. In the case being discussed here, you have the ability to define the encryption algorithm and even disable it - you still have direct access to the flash, which means you can read back the encrypted content and verify that the controller is encrypting in the expected manner.

Inline encryption for filesystems

theonewolf — Tue, 27 Aug 2019 21:48:17 +0000

SSDs also usually implement it under the TCG OPAL standard. Most SSDs are full self-encrypting drives (SEDs) today.

Inline encryption for filesystems

theonewolf — Tue, 27 Aug 2019 21:47:17 +0000

Technically I think SSDs already have this kind of technology: https://www.micron.com/-/media/documents/products/white-p...

I think most SSDs ship with it now: https://www.samsung.com/semiconductor/insights/news-event...

They are typically based on the TCG OPAL standard for self-encrypting drives (SEDs): https://en.wikipedia.org/wiki/Opal_Storage_Specification

Inline encryption for filesystems

mjg59 — Tue, 27 Aug 2019 20:55:04 +0000

This is already common in phones, where the flash controller in the SoC has support for doing the encryption in hardware.

Inline encryption for filesystems

Spack — Tue, 27 Aug 2019 20:39:05 +0000

What device could specifically benefit from this support? Can we already find such drives on the market?