The test-tpm2 test multiplexes a bunch of tests from a single
entrypoint test that creates the TPM2 connection. This means we only get
the nice log output which test we are looking for once for the
entrypoint.
Let's add a macro that allows it to nicely generate it for the inner
tests too and use it.
Let's add a new "plymouth-util.c" module with helpers for talking to
plymouth. We so far had three places for this, let's unify the code
doing this a bit.
Those functions take a pointer to a timestamp and return a timestamp pointer,
so the reader would be justified to think that those are just getters. Rename
them to avoid confusion.
We already save it in PEM format, also store it TPM2_PUBLIC format next
to it. This is useful for usage with systemd-cryptenroll's
--tpm2-device-key= switch.
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)
Currently empty epochs are not sealed. This allows an attacker to truncate
a sealed log and continue it without any problems showing when verifying the
log.
This partially addresses CVE-2023-31438. One way to extend this change to
address CVE-2023-31438 completely, would be to verify that there is exactly
one seal per epoch (and not sealing when the epoch has not ended yet).
the change also adds a journal-file flag: HEADER_COMPATIBLE_SEALED_CONTINUOUS
this flag indicates that a journal file is sealed continuously and decides whether
any missing crypto epochs should trigger a warning or an error.
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.
The SRK templates are defined by specification, so move the check for TPM
support to the tpm2_get_best_srk_template() function, and allow anyone to get
the ECC and RSA templates.
Also add test to verify the SRK templates are correct.
Let's be friendly in what we accept: whenever we define a JSON
structure, let's also allow decimal strings where we want an integer.
This patch purely replaces JSON_VARIANT_UNSIGNED by
_JSON_VARIANT_TYPE_INVALID in the various JsonDispatch[] tables, so that
we'll happily accept any type in json_dispatch(), so that
json_dispatch_uint64() and related tools can do their thing.
This does not switch over OCI (as a JSON structure not defined by us).
JSON famously is problematic with integers beyond 53 bits, because
JavaScript stores everything in double precision floating points.
Various implementations in other languages can deal with signed 64 bit
integers, and a few can deal with unsigned 64bit too (like ours).
Typically program that need more then 53 bit of accuracy encode integers
as decimal strings, to make sure that even if consumers can't really
process larger values they at least won't corrupt the data while passing
it along. This is also recommended by JSON-I (RFC 7493)
To maximize compatibility with other implementations let's add 1st class
parsing support for such objects in the json_dispatch() API.
This makes json_dispatch_uint64() and related calls parse such
integers-formatted-as-decimal-strings as uint64_t. This logic will only
be enabled if the "type" field of JsonDispatch is left unspecified (i.e.
set to negative/_JSON_VARIANT_TYPE_INVALID) though, hence alone does not
change anything in effect.
This purely is about consuming such values, whether we should genreate
them also is a discussion for a separate PR.
These helpers tpm2_seal_data()/tpm2_unseal_data() are useful for
sealing/unsealing data without any further semantics around them. This
is different from the existing tpm2_seal()/tpm2_unseal() which seal with
a specific policy and serialize in a specific way, as we use it for disk
encryption.
These new helpers are more generic, they do not serialize in a specific
way or imply policy, they are just the core of the sealing/unsealing.
(We should look into porting tpm2_seal()/tpm2_unseal() onto these new
helpers, but this isn#t trivial, since the classic serialization we use
uses a merged marshalling of private/public key, which we'd have to
change in one way or another)
This is the primary core of what pcrlock is supposed to do eventually:
maintain a TPM2 policy hash inside an NV index which we then can
reference via a PolicyAuthorizeNV expression to lock other objects
against it.
Note: we export these new symbols for now. A later commit in this PR
will make them static again. The only reason they are exported here is
to make sure gcc doesn't complain about unused static symbols, and I
really wanted to commit them in a separate commit.
The pkcs11 cryptsetup token module is a bit different from the tpm2 +
fido2 ones: it asks for the PIN itself, rather than bubbling up a
request to get a PIN. That's because it might need multiple, and because
we don't want to destroy a the pkcs11 session half-way and thus risk
increasing pin counters.
Hence, we sometimes ask for PINs from our code, rather than let the
libcryptsetup caller do that. So far we didn't pass the AskPasswordFlags
field down into the module though. Fix that.
Fixes: #28665
David Tardon
Yu Watanabe
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Luca Boccassi
Felix Dörre
Dan Streetman
Antonio Alvarez Feijoo
Daan De Meyer