[systemd-devel] JournalD with TPM

[Lennart Poettering]

On Mi, 10.02.21 16:56, Andreas Krüger (DrAndreasKrueger at web.de) wrote:

>    Hi folks,
>
>    I'm freelancer and for my client I'm currently working on a board with
>    securtity features running Debian OS and SystemD. Logging is done by
>    JournalD and should run in "sealing" mode. For that, the Logger must be
>    activated by a special journalctl command, which generates a key
>    (FSS) that shall be stored in a "safe" location. Since there is no
>    possiblity (use case) for the key to leave the board, this "safe" location
>    has to be somewhere on the board. For safety reasons, this obviously
>    cannot be a simple cell in RAM.
>
>    Fortunately, the board includes a TPM (Trusted Platform Module) that could
>    be used for this purpose. However, when verifying the logger's storage the
>    TPM has to be "opened" to get the key. This means that a kind of password
>    is used for this, which is somewhere unprotected in RAM. So with the TPM,
>    I've shifted my problem from key to password.

tpms don't need passwords, unless that's the policy you define. But
there's no need to do that. You can also bind your stuff to PCRs,
i.e. hashes of the software you use so that only trusted software can
access the data. You could also define an empty policy, so that anyone
with API access to the TPM can get the key.

>    In my opinion, the only way to successfully use a TPM is to let the
>    verification be done by the TPM instead by the logger. In this case, the
>    key will not leave the TPM.
>
>    Has there been anything developed in that direction yet?
>
>    Or maybe there is another approach to solve my problem?

So we'll have some direct TPM2 support in the upcoming systemd version
248, in the cryptsetup logic.

I am very interested in combining TPM and FSS together, but it's not
clear to me how to do this best.

FSS so far works with a key pair: the sealing key and the verification
key. The sealing key remains on the system and is regularly updated to
a new one, in a forward-secure way, so that you can go from the older
to newer keys, but never back. And the verification key is stored
offline so that the system cannot modify/replace it.

The question is how to map this to the TPM. i.e. can we maybe sign the
verification key with a key from the TPM that can never be regenerated
or replaced by something else without us noting? i figure
"counter" policies of tpm2 could actually work for this, but this
requires some more research.

I am very sympathetic to the cause though, and given the recent
additions to the cryptsetup logic we already have a lot of TPM infra
in place in the systemd tree, i.e. after figuring out what to actualy
do I guess the implementation could be a pretty short patch.

(I'd try to focus on securing the verification key of FSS only with the
TPM, i.e. i'd probably leave the sealing key stored on disk as before,
simply to make things simple so that people can optionally do both:
store the verification key offline *and* in TPM, and if the TPM is
lost they can still use the verification key they stored elsewhere)

Lennart

--
Lennart Poettering, Berlin