Prevent attackers from spoofing the tpmKey portion of the AuthSession by
adding a trusted key to the LUKS header metadata. Also, use a persistent
object rather than a transient object.
This provides the following benifits:
1. No way to MITM the tpmKey portion of the session, see [1] for
details.
2. Strengthens the encrypted sessions, note that the bindKey could be
dropped now.
3. Speed, once it's created we just use it.
4. Owner Auth is needed to call create primary, so using the SRK
creates a scratch space for normal users.
This is a "first to set" model, in where the first person to set the key
in the LUKS header wins. Thus, setup should be done in a known good
state. If an SRK, which is a primary key at a special persistent
address, is found, it will use whatever is there. If not, it creates an
SRK. The SRK follows the convetions used through the tpm2-software
organization code on GitHub [2], however, a split has occured between
Windows and Linux with respect to SRK templates. The Linux SRK is
generated with the unique field size set to 0, in Windows, it properly
sets the size to key size in bytes and the unique data to all 0's of that
size. Note the proper templates for SRKs is covered in spec [3].
However, the most important thing, is that both SRKs are passwordless,
and thus they should be interchangable. If Windows is the first to make
the SRK, systemd will gladly accept it and vice-versa.
1. Without the bindKey being utilized, an attacker was able to intercept
this and fake a key, thus being able to decrypt and encrypt traffic as
needed. Introduction of the bindKey strengthened this, but allows for
the attacker to brute force AES128CFB using pin guesses. Introduction of
the salt increases the difficulty of this attack as well as DA attacks
on the TPM objects itself.
2. https://github.com/tpm2-software
3. https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdfFixes: #20668Fixes: #22637
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Salt was added in v253. We are not checking whether it was actually found
(non-zero size), so when an old tpm+pin enrollment is opened things go boom.
For good measure, check both the buffer and the size in both places.
Assertion 'saltlen > 0' failed at src/shared/tpm2-util.c:2490, function tpm2_util_pbkdf2_hmac_sha256(). Aborting.
This will be used by Tpm2Handle instances, which is added in later patches.
The refcounting allows the context to be retained until all Tpm2Handles have
been cleaned up, and the initial ref is released, before cleaning the context.
The 'pcr_bank' functions operate on hash algs, and are not specific to the PCR
banks, while the 'primary_alg' functions operate on asymmetric algs, and are
not specific to primary keys.
When compiled without ENABLE_EFI, efi_stub_measured() was not defined, so
compilation would fail. But it's not enough to add a stub that returns
-EOPNOTSUPP. We call this function in various places and usually print the error
at warning or error level, so we'd print a confusing message. We also can't add
a stub that always returns 0, because then we'd print a message like "Kernel
stub did not measure", which would be confusing too. Adding special handling for
-EOPNOTSUPP in every caller is also unattractive. So instead efi_stub_measured()
is reworked to log the warning or error internally, and such logging is removed
from the callers, and a stub is added that logs a custom message.
Add a salt to the pin and store it in the TPM2 LUKS header for future
this. This adds entropy to user supplied pins and helps brute forcing
the passphrase on the key residing in the TPM or brute forcing bind key
encrypted sessions with low entropy passphrases.
Signed-off-by: malikabhi05 <abhishek.malik@intel.com>
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Let's introduce a common implementation of a function that checks
whether we are booted on a kernel with systemd-stub that has TPM PCR
measurements enabled. Do our own userspace measurements only if we
detect that.
PCRs are scarce and most likely there are projects which already make
use of them in other ways. Hence, instead of blindly stepping into their
territory let's conditionalize things so that people have to explicitly
buy into our PCR assignments before we start measuring things into them.
Specifically bind everything to an UKI that reported measurements.
This was previously already implemented in systemd-pcrphase, but with
this change we expand this to all tools that process PCR measurement
settings.
The env var to override the check is renamed to SYSTEMD_FORCE_MEASURE,
to make it more generic (since we'll use it at multiple places now).
This is not a compat break, since the original env var for that was not
included in any stable release yet.
These options allow measuring the volume key used for unlocking the
volume to a TPM2 PCR. This is ideally used for the volume key of the
root file system and can then be used to bind other resources to the
root file system volume in a secure way.
See: #24503
This returns an ssize_t, not an int. On populare archs that's the
difference between 64bit and 32bit. hence, let's be more careful here,
and not silently drop half the bits on the ground by assigning the
return value to "int".
As noticed by @malikabhi05:
https://github.com/systemd/systemd/pull/24754#discussion_r1062903159
`acquire_fido2_key_auto()` will not be used in PLAIN mode, and
parameters such as the salt will be acquired from the LUKS header.
Parameters intended for PLAIN mode are useless in
`acquire_fido2_key_auto()`.
After #25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.
Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.
Fixes#19208.
This works becuase TPM2_FLAGS_USE_PIN is 1 and bool is a 1 so the bits
line up as expected, however if for some reason flags change values and
for clarity check if the boolean indicates this flag and pass the flag
value.
Signed-off-by: William Roberts <william.c.roberts@intel.com>
This splits out the JSON parser used by the systemd-cryptsetup code.
This is preparation for later work to reuse it in the tpm2 cryptsetup
token module, which currently uses a separate but very similar parser
for the same data.
No change in behaviour.
Traditionally, TPM2 PCR policies are bound against literal PCR values,
which makes them hard to work with when updating software that is
measured into PCRs: each update will change the PCR values, and thus
break TPM2 policies of existing objects.
Let's improve the situation: let's allow signed PCR policies. Secrets
and other TPM2 objects can be associated with a public key that signs a
PCR policy. Thus, if the signed policy and the public key is presented,
access to the TPM2 object can be granted. This allows a less brittle
handling of updates: for example, whenever a kernel image is updated a
new signed PCR policy can be shipped along with it, signed by a private
key owned by the kernel vendor (ideally: same private key that is used
to sign the kernel image itself). TPM2 objects can then be bound to the
associated public key, thus allowing objects that can only be unlocked
by kernels of the same vendor. This makes it very easy to update kernels
without affecting locked secrets.
This does not hook up any of the consuming code (just passes NULL/0
everywhere). This is for later commits.
Add a new tpm2_parse_pcr_argument() helper that unifies how we merge PCR
masks in a single function, we can use all over the place. Previously we
had basically the same code for this at 4 places.
Previously the env var was only checked when conditionalizing use of our
own libcryptsetup loadable token modules. But let's also use it for any
other kind of token module, including possible internal ones by
libcryptsetup.
Instead of always asking for passphrase, if the device has LUKS2 header check:
- If only regular passphrases are registered, ask for passphrase.
- If only recovery keys are registered, ask for recovery key.
- If both regular passphrases and recovery keys are registered, ask for
passphrase or recovery key.
crypt_activate_by_token() fails with ENOANO if the token is protected with a
PIN, in this case we need to call crypt_activate_by_token_pin() with a PIN.
This logic is already implemented in
crypt_activate_by_token_pin_ask_password().
This code path is relevant when using systemd-gpt-auto-generator because there
is no a priory information about the type of the used security device, so
systemd-cryptsetup tries to unlock the volume using the corresponding
cryptsetup plugin.
Use the helper function introduced in the previous commit ("cryptsetup:
implement cryptsetup_token_open_pin for systemd-tpm2 LUKS2 token") for
cryptsetup-token-systemd-tpm2.
This finishes the implementation started in commit
1f895adac2 ("cryptsetup: add libcryptsetup TPM2
PIN support").
Note that the previous implementation took a shortcut by returning EOPNOTSUPP
instead of the correct ENOANO as per the cryptsetup documentation. This meant
that systemd-cryptsetup fell back to the non-plugin implementation in order to
ask for the PIN. Since this does not happen any more when returning ENOANO, we
need to ask for the PIN in attach_luks2_by_tpm2_via_plugin() instead like
attach_luks2_by_fido2_via_plugin() does.
```
...
../src/cryptsetup/cryptsetup-tokens/cryptsetup-token-systemd-fido2.c:33:13: error: variable 'r' set but not used [-Werror,-Wunused-but-set-variable]
int r;
^
1 error generated.
...
../src/cryptsetup/cryptsetup-tokens/cryptsetup-token-systemd-pkcs11.c:34:13: error: variable 'r' set but not used [-Werror,-Wunused-but-set-variable]
int r;
^
1 error generated.
ninja: build stopped: subcommand failed.
+ fatal ''\''meson compile'\'' failed with -Db_ndebug=true'
```
