Lines Matching refs: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
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 AES-256-XTS is used for
181 contents encryption, the master key must be 64 bytes (512 bits). Note
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
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
267 The Adiantum encryption mode (see `Encryption modes and usage`_) is
268 suitable for both contents and filenames encryption, and it accepts
280 - For v1 encryption policies, the encryption is done directly with the
284 - For v2 encryption policies, the encryption is done with a per-mode
286 other v2 encryption policies.
291 For master keys used for v2 encryption policies, a unique 16-byte "key
298 fscrypt allows one encryption mode to be specified for file contents
299 and one encryption mode to be specified for filenames. Different
300 directory trees are permitted to use different encryption modes.
301 Currently, the following pairs of encryption modes are supported:
319 "Adiantum: length-preserving encryption for entry-level processors"
325 New encryption modes can be added relatively easily, without changes
326 to individual filesystems. However, authenticated encryption (AE)
330 Contents encryption
340 - With CBC mode encryption, ESSIV is also used. Specifically, each IV
342 of the file's data encryption key.
346 IV. Currently this is only allowed with the Adiantum encryption
349 Filenames encryption
366 weakness, as it is a wide-block encryption mode.
368 All supported filenames encryption modes accept any plaintext length
386 Setting an encryption policy
392 The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an
394 has the specified encryption policy. It takes in a pointer to a
430 encryption modes to use. If unsure, use FSCRYPT_MODE_AES_256_XTS
437 Additionally, if the encryption modes are both
441 - For v2 encryption policies, ``__reserved`` must be zeroed.
443 - For v1 encryption policies, ``master_key_descriptor`` specifies how
452 For v2 encryption policies, ``master_key_descriptor`` has been
462 encryption policy is assigned to the directory, turning it into an
466 directory will be encrypted, inheriting the same encryption policy.
470 FS_IOC_SET_ENCRYPTION_POLICY validates that the specified encryption
475 When a v2 encryption policy is assigned to a directory, it is also
493 - ``EEXIST``: the file is already encrypted with an encryption policy
495 - ``EINVAL``: an invalid encryption policy was specified (invalid
497 - ``ENOKEY``: a v2 encryption policy was specified, but the key with
504 - ``ENOTTY``: this type of filesystem does not implement encryption
505 - ``EOPNOTSUPP``: the kernel was not configured with encryption
507 had encryption enabled on it. (For example, to use encryption on an
516 Getting an encryption policy
519 Two ioctls are available to get a file's encryption policy:
533 The FS_IOC_GET_ENCRYPTION_POLICY_EX ioctl retrieves the encryption
559 encryption policy version
561 - ``ENOTTY``: this type of filesystem does not implement encryption,
564 - ``EOPNOTSUPP``: the kernel was not configured with encryption
566 had encryption enabled on it
568 encryption policy version, but the policy struct does not fit into
580 encryption policy, if any, for a directory or regular file. However,
590 encrypted using a newer encryption policy version.
598 value is intended to used as a salt when deriving an encryption key
610 The FS_IOC_ADD_ENCRYPTION_KEY ioctl adds a master encryption key to
641 - If the key is being added for use by v1 encryption policies, then
650 Alternatively, if the key is being added for use by v2 encryption
689 - ``ENOTTY``: this type of filesystem does not implement encryption
690 - ``EOPNOTSUPP``: the kernel was not configured with encryption
692 had encryption enabled on it
697 For v1 encryption policies, a master encryption key can also be
702 This method is deprecated (and not supported for v2 encryption
720 ``master_key_descriptor`` that was set in the encryption policy. The
763 encryption key from the filesystem, and possibly removes the key
781 - To remove a key used by v1 encryption policies, set
787 - To remove a key used by v2 encryption policies, set
834 - ``ENOTTY``: this type of filesystem does not implement encryption
835 - ``EOPNOTSUPP``: the kernel was not configured with encryption
837 had encryption enabled on it
860 master encryption key. It can be executed on any file or directory on
883 - To get the status of a key for v1 encryption policies, set
887 - To get the status of a key for v2 encryption policies, set
912 - ``ENOTTY``: this type of filesystem does not implement encryption
913 - ``EOPNOTSUPP``: the kernel was not configured with encryption
915 had encryption enabled on it
926 encryption policies using the legacy mechanism involving
935 With the encryption key, encrypted regular files, directories, and
937 after all, the encryption is intended to be transparent. However,
940 - Unencrypted files, or files encrypted with a different encryption
989 files, directories, and symlinks even before their encryption key has
990 been added, or after their encryption key has been removed:
1026 without the encryption key. This would require special APIs which
1032 After an encryption policy has been set on a directory, all regular
1034 (recursively) will inherit that encryption policy. Special files ---
1039 files, or files encrypted with a different encryption policy, in an
1043 attacks that try to disable or downgrade encryption in known locations
1046 this by validating all top-level encryption policies prior to access.
1054 An encryption policy is represented on-disk by a :c:type:`struct
1059 setxattr() because of the special semantics of the encryption xattr.
1060 (In particular, there would be much confusion if an encryption policy
1088 policy structs (see `Setting an encryption policy`_), except that the
1107 buffers regardless of encryption. Other filesystems, such as ext4 and
1108 F2FS, have to allocate bounce pages specially for encryption.
1119 With encryption, lookups must be supported and efficient both with and
1120 without the encryption key. Clearly, it would not work to hash the
1157 f2fs encryption using `kvm-xfstests
1162 UBIFS encryption can also be tested this way, but it should be done in
1168 No tests should fail. However, tests that use non-default encryption