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 28, 2017 21:04 UTC (Tue) by tytso (✭ supporter ✭, #9993)
In reply to: wait... how do other systems such as APFS and ZFS do acceleration ? by ortalo
Parent article: Inline encryption support for block devices

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

to post comments

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.