History

fscrypt: add support for IV_INO_LBLK_32 policies

The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV bits), unlike UFS's 64. IV_INO_LBLK_64 is therefore not applicable, but an encryption format which uses one key per policy and permits the moving of encrypted file contents (as f2fs's garbage collector requires) is still desirable. To support such hardware, add a new encryption format IV_INO_LBLK_32 that makes the best use of the 32 bits: the IV is set to 'SipHash-2-4(inode_number) + file_logical_block_number mod 2^32', where the SipHash key is derived from the fscrypt master key. We hash only the inode number and not also the block number, because we need to maintain contiguity of DUNs to merge bios. Unlike with IV_INO_LBLK_64, with this format IV reuse is possible; this is unavoidable given the size of the DUN. This means this format should only be used where the requirements of the first paragraph apply. However, the hash spreads out the IVs in the whole usable range, and the use of a keyed hash makes it difficult for an attacker to determine which files use which IVs. Besides the above differences, this flag works like IV_INO_LBLK_64 in that on ext4 it is only allowed if the stable_inodes feature has been enabled to prevent inode numbers and the filesystem UUID from changing.

Eric Biggers committed 6 years ago

Commit e3b10781 parent 0ca2ddb7 files · +157 −46Browse files

Showing the changes to include/uapi/linux (1 of 7 files). Show all

Unified · Split

include/uapi/linux/fscrypt.h+2−1
@@ -19,7 +19,8 @@ · 18 unmodified lines
1919 #define FSCRYPT_POLICY_FLAGS_PAD_MASK 0x03
2020 #define FSCRYPT_POLICY_FLAG_DIRECT_KEY 0x04
2121 #define FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64 0x08
22−#define FSCRYPT_POLICY_FLAGS_VALID 0x0F
22+#define FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 0x10
23+#define FSCRYPT_POLICY_FLAGS_VALID 0x1F
2324
2425 /* Encryption algorithms */
2526 #define FSCRYPT_MODE_AES_256_XTS 1