wait... how do other systems such as APFS and ZFS do acceleration ? [LWN.net]

wait... how do other systems such as APFS and ZFS do acceleration ?

Posted Mar 27, 2017 8:15 UTC (Mon) by ortalo (guest, #4654)
In reply to: wait... how do other systems such as APFS and ZFS do acceleration ? by tytso
Parent article: Inline encryption support for block devices

I agree this seems fine for spreading usage of crypto. acceleration.
However, it seems to me we are seeing the problem of sharing these devices between multiple users appear now ; especially in the use cases where different users expect to use different keys.
Admittedly, it is already very nice to have host encryption, if only to have host-level protection againts "outsiders".
However, I wonder if simple additions to these hardware would not allow association of different sets of keys to different users contexts (similarly to the way pagetables are associated to specific adress spaces in the classical MMU case)?

Another question: all these new hardware are targetting encryption only? Nothing with respect to signing (or hashing) only?

to post comments

wait... how do other systems such as APFS and ZFS do acceleration ?

Posted Mar 28, 2017 21:04 UTC (Tue) by tytso (✭ supporter ✭, #9993) [Link] (1 responses)

How you associate keys to different user contexts is a key management problem, which is somewhat orthogonal to crypto acceleration. If the keys are provided by the host CPU to the crypto engine, then supporting keys for different users is trivial. We do this today with the Pixel and Pixel XL. Separate keys are actually used for each user profile. This means that if you leave your company, and your company is using G Suite (e.g., Gmail, Google Drive, etc.) with enterprise domain management, your company can arrange to have the key associated with the corporate identity be erased from your Android device, while allowing you to keep your personal profile on your phone. (Previously the Android Device Policy Manager would have to wipe the entire device when you left the company.) And if you have multiple users on your phone, each user also has a separate key.

Right now, all of in-line crypto acceleration hardware which I am familiar with is targetting encryption only, unfortunately.

The challenge with doing authenticated encryption (e.g., AES GCM) is that you need to store the per-block authentication tag somewhere. The challenge is that doing this would mean we would need flash chips with page sizes that are 4k plus 32 bytes for the IV and AES GCM authentication tag. But there aren't any eMMC flash devices with 4128 byte pages. And a non-standard, custom eMMC storage device would be extremely pricey. So it would probably be not commercially viable. :-(

wait... how do other systems such as APFS and ZFS do acceleration ?

Posted Mar 28, 2017 22:56 UTC (Tue) by tytso (✭ supporter ✭, #9993) [Link]

I should add there is one hardware crypto devices that you can find in most laptops that will do signing, and that's the TPM. A few months ago, James Bottomley blogged[1] about interesting ways to use the TPM, including as a way of securing your SSH keys. (That's actually an encryption function, not a signing function, but the TPM can also do signature operations. Still, it's a good introduction to the TPM technology, so it's worth a read.)

[1] https://blog.hansenpartnership.com/using-your-tpm-as-a-se...

But a TPM is really not a crypto *accelerator*; in fact, pretty much all TPM's are incredibly S-L-O-W at doing crypto operations. So why does a TPM exist? Because it will only encrypt, decrypt, or sign messages on your behalf if you give it the correct password or PIN. And if you try too many bad passwords, the TPM will lock you out. So this is useful if you want to protect someone from stealing your password, since the password by itself won't be enough; they will also need to be able to get your laptop. It's also really good at making Jim Comey, head of the FBI, really angry. Oh, well. :-)

You can certainly use a TPM, or some other secure element, in conjunction with an in-line crypto engine. The two technologies are very complementary. This is why I want to make sure that whatever inline crypto encryption support gets landed in the upstream kernel can be easily extended to support device designs where the host CPU does not have access to the encryption keys, and where the keys are provisioned via some kind of secure element directly to the inline crypto engine.