| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After 3b16e9f41983f697bc38c40bb8e7119c1bb4f7c8, even the libraries are
documented in the man page, it is useful to mention which libraries are
checked in the command output.
Of course, the dependencies are kind of implementation detail, and may
be changed in the future version, but that's especially why I think
showing the library deps in the output is useful.
systemd-analyze is a debugging tool, and already shows many internal
states. I think there is nothing to prevent from showing the deps.
Prompted by #34477.
|
|
|
|
|
|
| |
has-tpm2 command is moved to systemd-analyze.
Follow-up for 58e359604ffdca12bb4d2c5807b96e070611c0f6.
|
|
|
|
|
|
|
|
| |
of the libraries
For example, 'bootctl status' only interested in if the efi has TPM2
support and a TPM2 driver is loaded. Hence, not necessary to load
libtss2.
|
| |
|
|
|
|
|
|
| |
The verb s not really specific to credential management, it was always a
bit misplaced. Hence move it to systemd-analyze, where we already have
some general TPM related verbs such as "srk" and "pcrs"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far you had to pick:
1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
dynamic local policy stored in NV index)
It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).
This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.
This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.
This means:
1. we simply double the unlock key in length in case both policies shall
be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
both halves of the LUKS unlock key.
This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).
I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).
This is mostly a giant search/replace patch.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's follow the conventions set by "Registry of Reserved TPM 2.0 Handles
and Localities" and only allocate nvindex currently not assigned to any
vendor.
For details see:
https://trustedcomputinggroup.org/resource/registry/
Section 2.2
|
|
|
|
|
|
|
|
|
|
| |
tpm2_context_new and logs about errors
We so far just print a short log message that is not very useful, let's
add some recognizable error codes, and output better log messages if we
can't get TPM stuff to work.
Fixes: #31925
|
|
|
|
|
|
|
|
| |
authValue anymore for the policy nvindex
We have now switched from PolicyAuthValue to PolicySigned to control
access to the policy nvindex to. This means there's no point in setting
an authValue on the nvindex anymore, hence drop this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PolicyAuthValue to PolicySigned (with an HMAC-SHA256 key)
So far the nvindex to store the pcrlock policy in was protected via a
PolicyAuthValue policy (i.e. with a simple PIN set on the nvindex).
That's a bad idea however, as it means an attacker can simply remove and
re-create the nvindex and the "name" of the nvindex does not change,
thus defeating the logic. (This is because the authValue is *not* part
of the "name" of an nvindex!).
Fix this by switching from PolicyAuthValue to PolicySigned with an
HMAC-SHA256 key. Behaviour is very similar: however, the PIN is now part
of of the access policy hash, which *is* part of the "name" of an
nvindex. Thus, if an attacker removes and recreates the nvindex it has
to provide the same PIN again or the "name" of the nvindex will change.
Mission accomplished.
I'd like to thank Chris Coulson for finding this issue (and helping me
address it). Thank you!
|
|
|
|
|
|
|
| |
Just some renaming. I found the old name a bit confusing since it sounds
as if this would get the pin from somewhere, but it really doesn't. It
just converts a PIN into an auth_value, and I think saying so explicitly
makes things easier to grok.
|
|
|
|
| |
We later want to use this from pcrlock.c, hence export it.
|
| |
|
|
|
|
|
|
|
| |
Let's move more code to using struct iovec for passing around binary
chunks of data.
No real changes in behaviour, just refactoring.
|
|\
| |
| | |
repart: add --tpm2-seal-key= support, matching the recently added support cryptenroll has
|
| |
| |
| |
| |
| |
| | |
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)
|
|/
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Add testing for tpm2_calculate_seal().
|
|
|
|
| |
Add functions to calculate a sealed secret object.
|
|
|
|
|
| |
Add functions to convert between alg id and string name for symmetric
algorithms and symmetric encryption modes.
|
|
|
|
|
| |
Verify the tpm2_get_srk_template() and tpm2_get_best_srk_template() functions
work as expected.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
This is useful to enumerate all hash algorithms we want to predict
measurements for.
|
|
|
|
|
|
|
|
| |
use them internally in tpm2-util.c
Note, some of these were just added in this same PR. We only exported
them initially to make sure gcc doesn't complained about unused local
symbols.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
TPM2 policies
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
tpm2-util.c
|
|
|
|
|
|
|
| |
These are not used outside of tpm2-util.[ch], and the way they merge
public/private key pair into one blob is kinda specific to our
implementation, hence better should be hidden away, and not used for new
code anyway.
|
|
|
|
|
|
| |
We'll soon have a function for determining the name of an NV index,
hence let's rename the existing function for the same of a public key to
make clear it's about public keys only.
|
|
|
|
|
|
|
|
|
| |
In TEST-70-TPM2, test systemd-cryptenroll --tpm2-seal-key-handle using the
default (0) as well as the SRK handle (0x81000001), and test using a non-SRK
handle index after creating and persisting a primary key.
In test/test-tpm2, test tpm2_seal() and tpm2_unseal() using default (0), the SRK
handle, and a transient handle.
|
|
|
|
| |
This defaults to the SRK index.
|
|
|
|
|
| |
This brings the tpm2_supports_ecc_curve() api in line with the other
tpm2_supports_*() functions, of returning a boolean.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds an explicit service for initializing the TPM2 SRK. This is
implicitly also done by systemd-cryptsetup, hence strictly speaking
redundant, but doing this early has the benefit that we can parallelize
this in a nicer way. This also write a copy of the SRK public key in PEM
format to /run/ + /var/lib/, thus pinning the disk image to the TPM.
Making the SRK public key is also useful for allowing easy offline
encryption for a specific TPM.
Sooner or later we should probably grow what this service does, the
above is just the first step. For example, the service should probably
offer the ability to reset the TPM (clear the owner hierarchy?) on a
factory reset, if such a policy is needed. And we might want to install
some default AK (?).
Fixes: #27986
Also see: #22637
|
|
|
|
|
|
|
|
|
| |
Adjust the tpm2_esys_handle_from_tpm_handle() function into better-named
tpm2_index_to_handle(), which operates like tpm2_get_srk() but allows using any
handle index. Also add matching tpm2_index_from_handle().
Also change the references to 'location' in tpm2_persist_handle() to more
appropriate 'handle index'.
|
|
|
|
| |
Add functions to marshal and unmarshal our 'blob' object.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we only logged our measurements to the journal. This is not a
great solution though, since regular logs are subject to rotation, which
is something we really cannot have for measurements (as it means we can
never reproduce the PCR values from the data). Hence, let's maintain an
explicit log.
Ideally, we'd just use the TCG Canonical Event Log format 1:1
(https://trustedcomputinggroup.org/resource/canonical-event-log-format/).
However it's not a perfect fit fo us, for various reasons. But let's
follow it (in its JSON incantation) as closely at it makes sense, so
that it can easily be converted to the full format by programs consuming
it.
Code comments explain where we deviate from the TCG CEL-JSON, and what
to do about it when reading the data.
|