The kind of inline encryption hardware we see on Android devices tends to have these limitations: - as you indicate, loading keys can incur latency, so if many keys are in use at once it can slow things down - it's limited to using AES-XTS - on UFS devices, the IV (transmitted in the DUN) must be zero in the 64 high bits - consecutive blocks in the same operation use consecutive IVs - there's no easy way to gather a checksum or MAC over the on-disk ciphertext short of re-reading after writing Android works around this with IV_INO_LBLK_64 policies, but these only work well on the relatively small storage devices we use on Android. In particular the IV limitation is very serious: - inode numbers must be four bytes - they must never change (so ext4 filesystem resizing is disabled) - files cannot be more than 2^32 blocks Things are worse on eMMC devices. Even without this IV limitation, the security proofs for most AES modes of operation start to look shaky as you approach the "birthday bound" of encrypting 2^68 bytes with the same key. If your attack model always assumes a point-in-time attack then you only have to worry if you use a single key to encrypt a multi-exabyte storage device; btrfs is designed to scale to such devices and more. If your attack model includes an attacker who repeatedly gets access to the storage device across time, then writing multiple exabytes with the same key can be a problem even if some of those are overwritten. This leads us to prefer per-extent AES keys (derived from a root key) if possible. It's a shame AES doesn't have a 256-bit blocksize. The way btrfs works also gives us some opportunities to do things a little better. In general disk encryption has to make sacrifices to deal with the limitation that IVs must be reused and there's no room for a MAC. But because btrfs writes in whole extents, with fresh metadata and checksum on each write, it becomes possible to use a fresh IV and MAC for every new write. This opens up the possibility of using an AEAD mode like AES-GCM. This combination gives us the strongest proofs of security even against very generous attack models. Our recommendation: btrfs should first build the ideal thing first since it will have reasonable performance for most users, then later design alternatives that make a few compromises for performance where there is demand. On Sun, 27 Nov 2022 at 23:59, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Wed, Nov 23, 2022 at 08:22:30PM -0500, Sweet Tea Dorminy wrote: > > The document has been updated to hopefully reflect the discussion we had; > > further comments are always appreciated. https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing > > How is this going to work with hardware encryption offload? I think > the number of keys for UFS and eMMC inline encryption, but Eric may > correct me.
|