disabling support in UFS2 for extended attributes (including ACLs).
Add a new variant of UFS2 called "UFS2ea" that does support extended attributes.
Add new fsck_ffs operations "-c ea" and "-c no-ea" to convert file systems
from UFS2 to UFS2ea and vice-versa (both of which delete all existing extended
attributes in the process).
The first time each key is verified, if verification fails, we chuck
the failed key and try again with passphrase re-entry.
But if a key has already been verified, and verification fails,
assume something is wrong with the disk and fail.
This way you can convert an existing parameters file to one that is
derived from a shared key, and derive other subkeys for other disks
from the same shared key.
cgdconfig -G -S -o /etc/cgd/wd0.shared /etc/cgd/wd0
cgdconfig -G -S -o /etc/cgd/wd1.shared \
-P /etc/cgd/wd0.shared /etc/cgd/wd1
This way, if you enter the same new password both times, wd0.shared
and wd1.shared generate the same keys as wd0 and wd1, but only need
one password entry with `cgdconfig -C'.
Usage model:
- Generate a parameters file that supports sharing its main key:
cgdconfig -g -S -o /etc/cgd/wd0e -V gpt adiantum
- Make another parameters file that uses the same shared main key but
derives an independent subkey from it:
cgdconfig -g -S -P /etc/cgd/wd0e -o /etc/cgd/ld1e \
-V disklabel aes-cbc 256
New clause `shared <id> algorithm <alg> subkey <info>' in a keygen
block enables `cgdconfig -C' to reuse a key between different params
files, so you can, e.g., use a single password for multiple disks.
This is better than simply caching the password itself because:
- Hashing the password is expensive, so it should only be done once.
Suppose your budget is time t before you get bored, and you
calibrate password hash parameters to unlock n disks before you get
bored waiting for `cgdconfig -C'.
. With n password hashings the adversary's cost goes up only by a
factor of t/n.
. With one password hashing and n subkeys the adversary's cost goes
up by a factor of n.
And if you ever add a disk, rehashing it will make `cgdconfig -C'
go over budget, whereas another subkey adds negligible cost to you.
- Subkeys work for other types of keygen blocks, like shell_cmd,
which could be used to get a key from a hardware token that needs a
button press.
The <info> parameter must be different for each params file;
everything else in the keygen block must be the same. With this
clause, the keygen block determines a shared key used only to derive
keys; the actual key used by cgdconfig is derived from the shared key
by the specified algorithm.
The only supported algorithm is hkdf-hmac-sha256, which uses
HKDF-Expand of RFC 5869 instantiated with SHA-256.
Example:
algorithm aes-cbc;
iv-method encblkno1;
keylength 128;
verify_method none;
keygen pkcs5_pbkdf2/sha1 {
iterations 39361;
salt AAAAgMoHiYonye6KogdYJAobCHE=;
shared "pw" algorithm hkdf-hmac-sha256
subkey AAAAgFlw0BMQ5gY+haYkZ6JC+yY=;
};
The key used for this disk will be derived by
HKDF-HMAC-SHA256_k(WXDQExDmBj6FpiRnokL7Jg==),
where k is the outcome of PBKDF2-SHA1 with the given parameters.
Note that <info> encodes a four-byte prefix giving the big-endian
length in bits of the info argument to HKDF, just like all other bit
strings in cgdconfig parameters files.
If you have multiple disks configured using the same keygen block
except for the info parameter, `cgdconfig -C' will only prompt once
for your passphrase, generate a shared key k with PBKDF2 as usual,
and then reuse it for each of the disks.
This provides an extra level of side-channel and cracking resistance
compared to the pre-existing pkcs5_pbkdf2/sha1 method used for
password-based disk encryption.
Several new keygen parameters are supported:
memory (integer, in kilobytes)
parallelism (integer, usually the number of CPU cores)
version (integer, usually 19...)
We do our best to calibrate these automatically when the paramsfile
is initially generated.
lgtm riastradh@
Fix cgdconfig to report verification failures with gpt and mbr
verification methods (and not treat them as silent hard errors).
This also causes the cgd to be unconfigured when one of those
verification methods fails.
Add ATF tests to check that bad verification is reported, and
does not leave the cgd configured.
Patches from the PR applied.
XXX Default paramsfile for NAME=label is /etc/cgd/dkNN (resolved wedge
partition) and /etc/cgd/ROOT.<suffix> for ROOT.<suffix>. This isn't yet
documented. IMO, it should be the other way around: /etc/cgd/label
for the former and /et/cgd/[root-device] for the latter.
This avoids the stupid null deref I added a couple of commits
ago (on bad usage) and also simplifies the rest of the routine
which no longer needs to check the arg count nearly as much.
Thanks to Alexander Nasonov for finding the null deref bug.
christos