The tpm2_tpm2b_public_from_pem() invocation only makes sense when we
succeed to load the file from disk, hence we might do this together and
safe a conditionalization.
No change in behaviour, let's just move this over so that we can reuse
this in repart later (and don't have to export the ugly `sym_` function
pointer for it)
Let's define the same switches and their backing variables in the same
order, and let's make sure the enums and switches are named the same.
No actual code changes.
Instead of enrolling the local TPM to a luks volume, use the public key from a
TPM to enroll it into the luks volume. This is useful when enrolling a TPM that
is not currently accessible, for example if the TPM is located on a different
system.
If `--tpm2-public-key=` is not specified, but `tpm2-pcr-public-key.pem` exists
in /{etc,run,usr/lib}/systemd/, the default PCR 11 is not being set.
Fixes 9e437994
Let's switch the order in which we process positional arguments and
analyze/tweak detail parameters. Let's look at the positional arguments
first (i.e. the "big picture") and then look at the switches (i.e.
"little details").
THis doesn't matter much, but makes for better error messages I think.
At least I was very confused that a completely borked cmdline I passed
to cryptenrolled complained about some detail and let the major fuckup
pass...
This removes a duplicate condition check by adding a common surrounding
if block.
This also change a confusing if check: "(X && Y) && Z" to simply "X && Y && Z"
This matches the change to tpm2_seal(), which now accepts a Tpm2Context instead
of a device string.
This also allows using the same TPM context for sealing and unsealing, which
will be required by (future) test code when sealing/unsealing using a transient
key.
Because most TPM2 functions here are 'library-like' functions, they should be
at debug level, not error level.
The only functions not reduced to logging at debug are tpm2_list_devices(),
since it is expected to print output, and the tpm2_parse_pcr_argument_*()
functions, since the system-wide parse_*_argument() functions generally log at
error level.
I always found it confusing that most of our TPM related definitions are
in tpm2-util.h, but the PCR names in tpm-pcr.h, without the "2". Let's
fix that and make this systematic, in particular as the definitions in
the file all start with TPM2_ already.
No code flow changes, just some renaming.
We so far maintained two places for symboic names for PCRs. One in
tpm2-util.h and one in tpm-pcr.h.
Let's unify this into one, i.e. move the full list from tpm2-util.h into
tpm-pcr.h, replacing the short list placed so far there.
Systematically prefix the definitions with TPM2_ or tpm2_, to follow how
we do this for all other defines in this context.
No change in behaviour, just unification of tables.
Move the calculation of the sealed object policy hash out of the tpm2_seal()
function. Instead, callers of tpm2_seal() can directly call
tpm2_calculate_sealing_policy() and then provide the policy hash to
tpm2_seal().
In order to allow users to specify expected PCR values, change the
tpm2_parse_pcr_argument() to parse the text argument into an array of
Tpm2PCRValue objects, which provide not only the selected PCR indexes, but also
(optionally) the hash algorithm and hash value for each PCR index.
This reverts commit cefa4a02ab.
Because the first 'break' is inside a nested for loop, this second 'break' is
needed to exit the outer for loop.
Fixes: #28451
quality_check_password() used to return the same value 0 in two
different cases: when pwq_allocate_context() failed with a
ERRNO_IS_NOT_SUPPORTED() code, and when pwquality_check() rejected the
password. As result, users of quality_check_password() used to report
password weakness also in case when the underlying library was not
available.
Fix this by changing quality_check_password() to forward the
ERRNO_IS_NOT_SUPPORTED() code to its callers, and change the callers
to handle this case gracefully.
The systemd-cryptenroll man page states:
Takes a comma separated list of numeric slot indexes, or the special
strings ..., or any combination of these strings or numeric
indexes, in which case all slots matching either are wiped.
but we'd allow only one special string at any given time as the value
was not ORed when assigning. So, for example, --wipe=recovery,password
would actually become --wipe=password, etc.
Passing 0 to log_xxx_errno() leads to an assertion, so let's not do that:
$ NEWPASSWORD="" build-san/systemd-cryptenroll --unlock-key-file=/tmp/password --password "$img"
/tmp/password has 0644 mode that is too permissive, please adjust the ownership and access mode.
Assertion '(_error) != 0' failed at src/cryptenroll/cryptenroll-password.c:164, function enroll_password(). Aborting.
Aborted (core dumped)
Fixes:
- Comment style
- Alignment style
- cleanup macro usage
- incorrect error message[1]
1. Thanks to tempusfugit991@gmail.com for pointing out the error
message mistake.
Signed-off-by: William Roberts <william.c.roberts@intel.com>
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>
If it was not requested to use a tpm2 signature file when enrolling, do
not fallback to the default /run/systemd/tpm2-pcr-signature.json as it
likely will be unrelated if it exists.
Fixes https://github.com/systemd/systemd/issues/25435
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>
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
This allows FIDO2 users to wipe out password slots and still be able to
enroll new key slots via systemd-cryptenroll. Note that when the user
wants to both unlock with a FIDO2 token and enroll a new FIDO2 token,
they cannot be set to automatic discovery. This is to safeguard against
confusion, because there will be multiple tokens connected to the system
when doing so -- and we require users to explicitly confirm which one to
use for unlocking and which one to use for enrollment.
Addresses #20230 for the FIDO2 case.
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.
Lennart Poettering
Dan Streetman
Antonio Alvarez Feijoo
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Yu Watanabe
Egor IgnatovandDmitry V. Levin
Dmitry V. Levin
Frantisek Sumsal
William Roberts
Jan Janssen
Peter Cai