Lines Matching refs:encryption
12 Inline encryption hardware sits logically between memory and disk, and can
14 can control exactly how the inline encryption hardware will en/decrypt the data
18 Some inline encryption hardware accepts all encryption parameters including raw
19 keys directly in low-level I/O requests. However, most inline encryption
24 Note that inline encryption hardware is very different from traditional crypto
26 crypto accelerators operate on memory regions, whereas inline encryption
27 hardware operates on I/O requests. Thus, inline encryption hardware needs to be
30 Inline encryption hardware is also very different from "self-encrypting drives",
32 drives don't provide fine-grained control of encryption and provide no way to
33 verify the correctness of the resulting ciphertext. Inline encryption hardware
34 provides fine-grained control of encryption, including the choice of key and
40 We want to support inline encryption in the kernel. To make testing easier, we
42 encryption hardware is absent. We also want inline encryption to work with
44 the inline encryption hardware of the underlying devices if present, or else
50 - We need a way for upper layers (e.g. filesystems) to specify an encryption
52 to be able to use that encryption context when they process the request.
56 - Different inline encryption hardware has different supported algorithms,
61 - Inline encryption hardware usually (but not always) requires that keys be
73 encryption support of their underlying devices. However, it doesn't make
79 We introduce ``struct blk_crypto_key`` to represent an inline encryption key and
85 We introduce ``struct bio_crypt_ctx`` to represent an encryption context. It
88 of the block layer (e.g. filesystems) to provide an encryption context when
90 layer and device drivers. Note that the encryption context doesn't explicitly
95 encryption-related state for a particular inline encryption device. The
96 blk_crypto_profile serves as the way that drivers for inline encryption hardware
99 wants to support inline encryption will construct a blk_crypto_profile, then
104 specify encryption contexts and don't need to know about keyslots at all, nor do
110 ``struct request`` for a bio that has an encryption context, it grabs a keyslot
120 encryption context into account when trying to merge bios and requests. For two
121 bios/requests to be merged, they must have compatible encryption contexts: both
123 numbers. Only the encryption context for the first bio in a request is
127 To make it possible for inline encryption to work with request_queue based
128 layered devices, when a request is cloned, its encryption context is cloned as
135 It is desirable for the inline encryption support of upper layers (e.g.
136 filesystems) to be testable without real inline encryption hardware, and
138 to allow upper layers to just always use inline encryption rather than have to
139 implement encryption in multiple ways.
142 of inline encryption using the kernel crypto API. blk-crypto-fallback is built
144 Essentially, when a bio with an encryption context is submitted to a
145 block_device that doesn't support that encryption context, the block layer will
148 For encryption, the data cannot be encrypted in-place, as callers usually rely
157 bio's encryption context, then submits the bio. If the read completes
164 encryption context. Therefore, lower layers only see standard unencrypted I/O.
169 without actual inline encryption hardware. Second, similar to actual inline
170 encryption hardware, the crypto API doesn't accept keys directly in requests but
176 Note that regardless of whether real inline encryption hardware or
179 encryption hardware's implementation and the kernel crypto API's implementation
189 inline encryption with particular crypto settings will work on a particular
203 Next, to attach an encryption context to a bio, users should call
209 Finally, when done using inline encryption with a blk_crypto_key on a
231 A device driver that wants to support inline encryption must set up a
240 blk_crypto_profile to tell upper layers how to control the inline encryption
246 requests the driver receives via that queue may have an encryption context. All
247 encryption contexts will be compatible with the crypto capabilities declared in
250 blk_crypto_profile, then all I/O requests that have an encryption context will
258 If there are situations where the inline encryption hardware loses the contents
270 encryption need to create their own blk_crypto_profile for their request_queue,
275 Interaction between inline encryption and blk integrity
281 when a WRITE bio wants to use inline encryption on a device that supports both
282 features, the bio will have an encryption context specified, after which
284 the encryption will happen while data is being written), and the data and
292 encryption support is present or the kernel crypto API fallback is used (since
299 kernel will pretend that the device does not support hardware inline encryption
302 encryption context will use the fallback, and IO will complete as usual. When
303 the fallback is disabled, a bio with an encryption context will be failed.
313 Linux storage encryption (dm-crypt, fscrypt, eCryptfs, etc.) traditionally
314 relies on the raw encryption key(s) being present in kernel memory so that the
315 encryption can be performed. This traditionally isn't seen as a problem because
317 attack that storage encryption is intended to protect from.
324 in-use encryption keys, then uses these keys to decrypt user data on-disk.
334 order to completely exfiltrate the data they need to extract the encryption
337 Hardware-wrapped keys are a feature of inline encryption hardware that is
345 protecting the encryption keys, as those instantly give access to **all** user
352 Inline encryption hardware typically has "keyslots" into which software can
361 typically is a small number. In cases where there is only one encryption key
362 system-wide (e.g., a full-disk encryption key), that can be tolerable.
365 storage areas. This is especially true if file-based encryption (e.g.
383 To solve all these problems, some vendors of inline encryption hardware have
386 -- either by the inline encryption hardware itself, or by a dedicated hardware
387 block that can directly provision keys to the inline encryption hardware.
391 such as in file-based encryption. Key wrapping is a commonly used technique.)
400 As inline encryption hardware can only be used to encrypt/decrypt data on-disk,
402 key directly for inline encryption, but rather derives both an inline encryption
404 tasks that can't use the inline encryption hardware, such as filenames
405 encryption. The software secret is not protected from memory compromise.
419 Inline encryption key Software secret
426 strong authenticated encryption algorithm such as AES-256-GCM is recommended.
436 - *Inline encryption key*: a derived key which the hardware directly provisions
437 to a keyslot of the inline encryption hardware, without exposing it to
439 However, in principle other encryption algorithms could be supported too.
440 Hardware must derive distinct subkeys for each supported encryption algorithm.
444 encryption. This value is cryptographically isolated from the inline
445 encryption key, i.e. knowing one doesn't reveal the other. (The KDF ensures
448 Some use cases (e.g. full-disk encryption) won't require the software secret.
452 encryption key is used as the file contents encryption key, while the software
454 (HKDF-SHA512) to derive other subkeys such as filenames encryption keys.
456 Note that currently this design assumes a single inline encryption key per
459 encryption optimized" settings, which use one file contents encryption key per
460 encryption policy rather than one per file. This design could be extended to
468 The inline encryption support of the kernel's block layer ("blk-crypto") has
493 hardware-wrapped keys can only be used with actual inline encryption hardware.
534 Both the hardware KDF and the inline encryption itself are well-defined
538 by the inline encryption hardware.
550 <https://android.googlesource.com/platform/test/vts-testcase/kernel/+/refs/heads/main/encryption/>`…