Lines Matching full:encryption
2 Filesystem-level encryption (fscrypt)
9 transparent encryption of files and directories.
15 use encryption, see the documentation for the userspace tool `fscrypt
20 <https://source.android.com/security/encryption/file-based>`_, over
56 Provided that userspace chooses a strong encryption key, fscrypt
72 fscrypt (and storage encryption in general) can only provide limited
80 Cryptographic API algorithms or inline encryption hardware are. If a
89 After an encryption key has been added, fscrypt does not hide the
97 encryption but rather only by the correctness of the kernel.
98 Therefore, any encryption-specific access control checks would merely
107 security vulnerability, can compromise all encryption keys that are
110 However, fscrypt allows encryption keys to be removed from the kernel,
115 encryption key from kernel memory. If it does so, it will also try to
151 v1 encryption policies have some weaknesses with respect to online
165 - Non-root users cannot securely remove encryption keys.
167 All the above problems are fixed with v2 encryption policies. For
168 this reason among others, it is recommended to use v2 encryption
180 encryption modes being used. For example, if any AES-256 mode is
182 stricter requirement applies if the key is used by a v1 encryption
208 encryption directly. Instead, they are only used as input to a KDF
212 the key is used for v1 encryption policies or for v2 encryption
214 encryption policies. (No real-world attack is currently known on this
218 For v1 encryption policies, the KDF only supports deriving per-file
219 encryption keys. It works by encrypting the master key with
224 For v2 encryption policies, the KDF is HKDF-SHA512. The master key is
227 key to be derived. For example, when a per-file encryption key is
237 Per-file encryption keys
241 "tweak" the encryption of each file so that the same plaintext in two
246 inode's encryption xattr. Then, it uses a KDF (as described in `Key
262 The Adiantum encryption mode (see `Encryption modes and usage`_) is
263 suitable for both contents and filenames encryption, and it accepts
271 per-file encryption keys are not used. Instead, whenever any data
275 - For v1 encryption policies, the encryption is done directly with the
279 - For v2 encryption policies, the encryption is done with a per-mode
281 other v2 encryption policies.
287 the encryption keys are derived from the master key, encryption mode
289 protected by the same master key sharing a single contents encryption
290 key and a single filenames encryption key. To still encrypt different
294 This format is optimized for use with inline encryption hardware
306 This format is optimized for use with inline encryption hardware
315 For master keys used for v2 encryption policies, a unique 16-byte "key
325 just like deriving a per-file encryption key, except that a different
329 Encryption modes and usage
332 fscrypt allows one encryption mode to be specified for file contents
333 and one encryption mode to be specified for filenames. Different
334 directory trees are permitted to use different encryption modes.
339 Currently, the following pairs of encryption modes are supported:
347 Authenticated encryption modes are not currently supported because of
349 contents encryption uses a block cipher in `XTS mode
353 or a wide-block cipher. Filenames encryption uses a
363 upgrades the filenames encryption to use a wide-block cipher. (A
366 entire result.) As described in `Filenames encryption`_, a wide-block
396 and AES-256-CTS-CBC encryption. For optimal performance, it is
399 wish to use. Support for any "non-default" encryption modes typically
402 Below, some relevant options are listed by encryption mode. Note,
404 platform; refer to the kconfig menus. File contents encryption can
405 also be configured to use inline encryption hardware instead of the
406 kernel crypto API (see `Inline encryption support`_); in that case,
451 Contents encryption
455 Starting from Linux kernel 5.5, encryption of filesystems with block
461 - With CBC mode encryption, ESSIV is also used. Specifically, each IV
463 of the file's data encryption key.
466 Currently this is only allowed with the Adiantum encryption mode.
480 Filenames encryption
497 wide-block encryption modes.
499 All supported filenames encryption modes accept any plaintext length
517 Setting an encryption policy
523 The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an
525 has the specified encryption policy. It takes in a pointer to
561 encryption modes to use. If unsure, use FSCRYPT_MODE_AES_256_XTS
563 (4) for ``filenames_encryption_mode``. For details, see `Encryption
566 v1 encryption policies only support three combinations of modes:
583 v1 encryption policies only support the PAD_* and DIRECT_KEY flags.
584 The other flags are only supported by v2 encryption policies.
589 - For v2 encryption policies, ``__reserved`` must be zeroed.
591 - For v1 encryption policies, ``master_key_descriptor`` specifies how
600 For v2 encryption policies, ``master_key_descriptor`` has been
610 encryption policy is assigned to the directory, turning it into an
614 directory will be encrypted, inheriting the same encryption policy.
618 FS_IOC_SET_ENCRYPTION_POLICY validates that the specified encryption
623 When a v2 encryption policy is assigned to a directory, it is also
641 - ``EEXIST``: the file is already encrypted with an encryption policy
643 - ``EINVAL``: an invalid encryption policy was specified (invalid
645 encryption policy was specified but the directory has the casefold
647 - ``ENOKEY``: a v2 encryption policy was specified, but the key with
654 - ``ENOTTY``: this type of filesystem does not implement encryption
655 - ``EOPNOTSUPP``: the kernel was not configured with encryption
657 had encryption enabled on it. (For example, to use encryption on an
666 Getting an encryption policy
669 Two ioctls are available to get a file's encryption policy:
683 The FS_IOC_GET_ENCRYPTION_POLICY_EX ioctl retrieves the encryption
709 encryption policy version
711 - ``ENOTTY``: this type of filesystem does not implement encryption,
714 - ``EOPNOTSUPP``: the kernel was not configured with encryption
716 had encryption enabled on it
718 encryption policy version, but the policy struct does not fit into
730 encryption policy, if any, for a directory or regular file. However,
739 encrypted using a newer encryption policy version.
747 value is intended to used as a salt when deriving an encryption key
753 Getting a file's encryption nonce
761 encryption is being done correctly. It is not needed for normal use
770 The FS_IOC_ADD_ENCRYPTION_KEY ioctl adds a master encryption key to
807 - If the key is being added for use by v1 encryption policies, then
815 Alternatively, if the key is being added for use by v2 encryption
877 - ``ENOTTY``: this type of filesystem does not implement encryption
878 - ``EOPNOTSUPP``: the kernel was not configured with encryption
880 had encryption enabled on it
885 For v1 encryption policies, a master encryption key can also be
890 This method is deprecated (and not supported for v2 encryption
908 ``master_key_descriptor`` that was set in the encryption policy. The
951 encryption key from the filesystem, and possibly removes the key
969 - To remove a key used by v1 encryption policies, set
975 - To remove a key used by v2 encryption policies, set
1022 - ``ENOTTY``: this type of filesystem does not implement encryption
1023 - ``EOPNOTSUPP``: the kernel was not configured with encryption
1025 had encryption enabled on it
1048 master encryption key. It can be executed on any file or directory on
1071 - To get the status of a key for v1 encryption policies, set
1075 - To get the status of a key for v2 encryption policies, set
1100 - ``ENOTTY``: this type of filesystem does not implement encryption
1101 - ``EOPNOTSUPP``: the kernel was not configured with encryption
1103 had encryption enabled on it
1114 encryption policies using the legacy mechanism involving
1123 With the encryption key, encrypted regular files, directories, and
1125 after all, the encryption is intended to be transparent. However,
1128 - Unencrypted files, or files encrypted with a different encryption
1130 linked into an encrypted directory; see `Encryption policy
1172 files, directories, and symlinks even before their encryption key has
1173 been added, or after their encryption key has been removed:
1209 without the encryption key. This would require special APIs which
1212 Encryption policy enforcement
1215 After an encryption policy has been set on a directory, all regular
1217 (recursively) will inherit that encryption policy. Special files ---
1222 files, or files encrypted with a different encryption policy, in an
1226 attacks that try to disable or downgrade encryption in known locations
1229 this by validating all top-level encryption policies prior to access.
1231 Inline encryption support
1244 encryption hardware* that can encrypt/decrypt data while it is on its
1245 way to/from the storage device. Linux supports inline encryption
1247 blk-crypto allows filesystems to attach encryption contexts to bios
1250 :ref:`Documentation/block/inline-encryption.rst <inline_encryption>`.
1259 encryption when possible; it doesn't force its use. fscrypt will
1261 inline encryption hardware doesn't have the needed crypto capabilities
1262 (e.g. support for the needed encryption algorithm and data unit size)
1269 inline encryption hardware that supports that data unit size.
1271 Inline encryption doesn't affect the ciphertext or other aspects of
1282 * The file must be using inline encryption. Usually this means that
1284 encryption hardware must be present. However, a software fallback
1285 is also available. For details, see `Inline encryption support`_.
1299 Encryption context
1302 An encryption policy is represented on-disk by
1307 setxattr() because of the special semantics of the encryption xattr.
1308 (In particular, there would be much confusion if an encryption policy
1336 policy structs (see `Setting an encryption policy`_), except that the
1339 different files to be encrypted differently; see `Per-file encryption
1345 When inline encryption is used, filesystems just need to associate
1346 encryption contexts with bios to specify how the block layer or the
1347 inline encryption hardware will encrypt/decrypt the file contents.
1349 When inline encryption isn't used, filesystems must encrypt/decrypt
1362 buffers regardless of encryption. Other filesystems, such as ext4 and
1363 F2FS, have to allocate bounce pages specially for encryption.
1374 With encryption, lookups must be supported and efficient both with and
1375 without the encryption key. Clearly, it would not work to hash the
1413 inline encryption support. For example, to test ext4 and
1414 f2fs encryption using `kvm-xfstests
1420 UBIFS encryption can also be tested this way, but it should be done in
1426 No tests should fail. However, tests that use non-default encryption