How does journalctl sign the logs if the “The verification key should be stored externally.”?

Question

$ man journalctl
...
--setup-keys
Instead of showing journal contents, generate a new key pair for Forward Secure Sealing (FSS). This will generate a
sealing key and a verification key. The sealing key is stored in the journal data directory and shall remain on the
host. The verification key should be stored externally. Refer to the Seal= option in journald.conf(5) for
information on Forward Secure Sealing and for a link to a refereed scholarly paper detailing the cryptographic
theory it is based on.
...
--verify
Check the journal file for internal consistency. If the file has been generated with FSS enabled and the FSS
verification key has been specified with --verify-key=, authenticity of the journal file is verified.

--verify-key=
Specifies the FSS verification key to use for the --verify operation.

afaik, signing in a PKI system works only If we have the private key.

afaik the advise: "The verification key should be stored externally." is that the private key (?) should be stored at another place?

Q: So how are the encrypted log messages signed in this situation?

afaik if the encrypted logs aren't signed, then an attacker can fake the logs, by encrypting the modified ones, and it will be accepted, since they are not signed. But keeping the private key there too is again bad, since they could be signed by the attacker.

Answer 1

Firstly, we need to understand some points given by the LWN article : Forward secure sealing

• FSS [Forward Secure Sealing] provides a way to at least detect tampering using only a single system, though it won't provide all of the assurances that external logging can.

• the binary logs handled by the systemd journal can be "sealed" at regular time intervals. That seal is a cryptographic operation on the log data such that any tampering prior to the seal can be detected.

• The algorithm for FSS is based on "Forward Secure Pseudo Random Generators" (FSPRG),

• One key is the "sealing key" which is kept on the system, and the other is the "verification key" which should be securely stored elsewhere. Using the FSPRG mechanism, a new sealing key is generated periodically using a non-reversible process. The old key is then securely deleted from the system after the change.

• The verification key can be used to calculate the sealing key for any given time range. That means that the attacker can only access the current sealing key (which will presumably be used for the next sealing operation), while the administrator can reliably generate any sealing key to verify previous log file seals. Changing log file entries prior to the last seal will result in a verification failure.

Then, the answer to your question :

Q: So how are the encrypted log messages signed in this situation?

is that the log files are not really encrypted nor signed but they are sealed. This is done via a specific cryptographic operation. The two main properties of the seal operation should be :

1) forward-security :

the adversary gets no advantage from learning current keys when aiming at forging past log entries

2) seekability :

the auditor can verify the integrity of log entries in any order or access pattern, at virtually no computational cost

Full details are given in the article : Practical Secure Logging: Seekable Sequential Key Generators by Giorgia Azzurra Marson and Bertram Poettering.

You can also check the source code of fsprg.c