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
150 v1 encryption policies have some weaknesses with respect to online
164 - Non-root users cannot securely remove encryption keys.
166 All the above problems are fixed with v2 encryption policies. For
167 this reason among others, it is recommended to use v2 encryption
179 encryption modes being used. For example, if any AES-256 mode is
181 stricter requirement applies if the key is used by a v1 encryption
207 encryption directly. Instead, they are only used as input to a KDF
211 the key is used for v1 encryption policies or for v2 encryption
213 encryption policies. (No real-world attack is currently known on this
217 For v1 encryption policies, the KDF only supports deriving per-file
218 encryption keys. It works by encrypting the master key with
223 For v2 encryption policies, the KDF is HKDF-SHA512. The master key is
226 key to be derived. For example, when a per-file encryption key is
236 Per-file encryption keys
240 "tweak" the encryption of each file so that the same plaintext in two
245 inode's encryption xattr. Then, it uses a KDF (as described in `Key
261 The Adiantum encryption mode (see `Encryption modes and usage`_) is
262 suitable for both contents and filenames encryption, and it accepts
270 per-file encryption keys are not used. Instead, whenever any data
274 - For v1 encryption policies, the encryption is done directly with the
278 - For v2 encryption policies, the encryption is done with a per-mode
280 other v2 encryption policies.
286 the encryption keys are derived from the master key, encryption mode
288 protected by the same master key sharing a single contents encryption
289 key and a single filenames encryption key. To still encrypt different
293 This format is optimized for use with inline encryption hardware
305 This format is optimized for use with inline encryption hardware
314 For master keys used for v2 encryption policies, a unique 16-byte "key
324 just like deriving a per-file encryption key, except that a different
328 Encryption modes and usage
331 fscrypt allows one encryption mode to be specified for file contents
332 and one encryption mode to be specified for filenames. Different
333 directory trees are permitted to use different encryption modes.
338 Currently, the following pairs of encryption modes are supported:
349 Authenticated encryption modes are not currently supported because of
351 contents encryption uses a block cipher in `XTS mode
355 or a wide-block cipher. Filenames encryption uses a
365 upgrades the filenames encryption to use a wide-block cipher. (A
368 entire result.) As described in `Filenames encryption`_, a wide-block
401 and AES-256-CBC-CTS encryption. For optimal performance, it is
404 wish to use. Support for any "non-default" encryption modes typically
407 Below, some relevant options are listed by encryption mode. Note,
409 platform; refer to the kconfig menus. File contents encryption can
410 also be configured to use inline encryption hardware instead of the
411 kernel crypto API (see `Inline encryption support`_); in that case,
456 Contents encryption
459 For contents encryption, each file's contents is divided into "data
465 Note: the encryption depending on the offset into the file means that
476 the encryption policy; see `FS_IOC_SET_ENCRYPTION_POLICY`_.
483 In the case of compression + encryption, the compressed data is
490 As mentioned in `Key hierarchy`_, the default encryption setting uses
493 encryption setting that does not use per-file keys. For these, some
514 key is the SHA-256 hash of the file's contents encryption key.
516 Filenames encryption
533 wide-block encryption modes.
535 All supported filenames encryption modes accept any plaintext length
553 Setting an encryption policy
559 The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an
561 has the specified encryption policy. It takes in a pointer to
598 encryption modes to use. If unsure, use FSCRYPT_MODE_AES_256_XTS
600 (4) for ``filenames_encryption_mode``. For details, see `Encryption
603 v1 encryption policies only support three combinations of modes:
620 v1 encryption policies only support the PAD_* and DIRECT_KEY flags.
621 The other flags are only supported by v2 encryption policies.
628 the granularity of file contents encryption. For example, setting
630 underlying encryption algorithm (such as AES-256-XTS) in 4096-byte
641 compatibility with inline encryption hardware that only supports
644 particular system's inline encryption hardware.
649 - For v2 encryption policies, ``__reserved`` must be zeroed.
651 - For v1 encryption policies, ``master_key_descriptor`` specifies how
660 For v2 encryption policies, ``master_key_descriptor`` has been
670 encryption policy is assigned to the directory, turning it into an
674 directory will be encrypted, inheriting the same encryption policy.
678 FS_IOC_SET_ENCRYPTION_POLICY validates that the specified encryption
683 When a v2 encryption policy is assigned to a directory, it is also
701 - ``EEXIST``: the file is already encrypted with an encryption policy
703 - ``EINVAL``: an invalid encryption policy was specified (invalid
705 encryption policy was specified but the directory has the casefold
707 - ``ENOKEY``: a v2 encryption policy was specified, but the key with
714 - ``ENOTTY``: this type of filesystem does not implement encryption
715 - ``EOPNOTSUPP``: the kernel was not configured with encryption
717 had encryption enabled on it. (For example, to use encryption on an
726 Getting an encryption policy
729 Two ioctls are available to get a file's encryption policy:
743 The FS_IOC_GET_ENCRYPTION_POLICY_EX ioctl retrieves the encryption
769 encryption policy version
771 - ``ENOTTY``: this type of filesystem does not implement encryption,
774 - ``EOPNOTSUPP``: the kernel was not configured with encryption
776 had encryption enabled on it
778 encryption policy version, but the policy struct does not fit into
790 encryption policy, if any, for a directory or regular file. However,
799 encrypted using a newer encryption policy version.
807 value is intended to used as a salt when deriving an encryption key
813 Getting a file's encryption nonce
821 encryption is being done correctly. It is not needed for normal use
830 The FS_IOC_ADD_ENCRYPTION_KEY ioctl adds a master encryption key to
867 - If the key is being added for use by v1 encryption policies, then
875 Alternatively, if the key is being added for use by v2 encryption
937 - ``ENOTTY``: this type of filesystem does not implement encryption
938 - ``EOPNOTSUPP``: the kernel was not configured with encryption
940 had encryption enabled on it
945 For v1 encryption policies, a master encryption key can also be
950 This method is deprecated (and not supported for v2 encryption
968 ``master_key_descriptor`` that was set in the encryption policy. The
1011 encryption key from the filesystem, and possibly removes the key
1029 - To remove a key used by v1 encryption policies, set
1035 - To remove a key used by v2 encryption policies, set
1082 - ``ENOTTY``: this type of filesystem does not implement encryption
1083 - ``EOPNOTSUPP``: the kernel was not configured with encryption
1085 had encryption enabled on it
1108 master encryption key. It can be executed on any file or directory on
1131 - To get the status of a key for v1 encryption policies, set
1135 - To get the status of a key for v2 encryption policies, set
1160 - ``ENOTTY``: this type of filesystem does not implement encryption
1161 - ``EOPNOTSUPP``: the kernel was not configured with encryption
1163 had encryption enabled on it
1174 encryption policies using the legacy mechanism involving
1183 With the encryption key, encrypted regular files, directories, and
1185 after all, the encryption is intended to be transparent. However,
1188 - Unencrypted files, or files encrypted with a different encryption
1190 linked into an encrypted directory; see `Encryption policy
1232 files, directories, and symlinks even before their encryption key has
1233 been added, or after their encryption key has been removed:
1269 without the encryption key. This would require special APIs which
1272 Encryption policy enforcement
1275 After an encryption policy has been set on a directory, all regular
1277 (recursively) will inherit that encryption policy. Special files ---
1282 files, or files encrypted with a different encryption policy, in an
1286 attacks that try to disable or downgrade encryption in known locations
1289 this by validating all top-level encryption policies prior to access.
1291 Inline encryption support
1294 Many newer systems (especially mobile SoCs) have *inline encryption
1296 the storage device. Linux supports inline encryption through a set of
1298 filesystems to attach encryption contexts to bios (I/O requests) to
1301 :ref:`Documentation/block/inline-encryption.rst <inline_encryption>`.
1310 encryption when possible; it doesn't force its use. fscrypt will
1312 inline encryption hardware doesn't have the needed crypto capabilities
1313 (e.g. support for the needed encryption algorithm and data unit size)
1320 inline encryption hardware that supports that data unit size.
1322 Inline encryption doesn't affect the ciphertext or other aspects of
1333 * The file must be using inline encryption. Usually this means that
1335 encryption hardware must be present. However, a software fallback
1336 is also available. For details, see `Inline encryption support`_.
1350 Encryption context
1353 An encryption policy is represented on-disk by
1358 setxattr() because of the special semantics of the encryption xattr.
1359 (In particular, there would be much confusion if an encryption policy
1388 policy structs (see `Setting an encryption policy`_), except that the
1391 different files to be encrypted differently; see `Per-file encryption
1397 When inline encryption is used, filesystems just need to associate
1398 encryption contexts with bios to specify how the block layer or the
1399 inline encryption hardware will encrypt/decrypt the file contents.
1401 When inline encryption isn't used, filesystems must encrypt/decrypt
1414 buffers regardless of encryption. Other filesystems, such as ext4 and
1415 F2FS, have to allocate bounce pages specially for encryption.
1426 With encryption, lookups must be supported and efficient both with and
1427 without the encryption key. Clearly, it would not work to hash the
1465 inline encryption support. For example, to test ext4 and
1466 f2fs encryption using `kvm-xfstests
1472 UBIFS encryption can also be tested this way, but it should be done in
1478 No tests should fail. However, tests that use non-default encryption