如果“验证密钥应存储在外部”，journalctl如何签名日志？

$ 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，只有拥有私钥，才能登录PKI系统。

afaik建议：“验证密钥应存储在外部。” 私钥（？）应该存储在另一个地方吗？

问：在这种情况下，如何对加密的日志消息进行签名？

afaik如果未对加密的日志进行签名，则攻击者可以通过对修改后的日志进行加密来伪造日志，由于未签名，因此将被接受。但是，将私钥保留在那里也是不好的，因为攻击者可能会签名。

首先，我们需要了解LWN文章提供的一些要点：前向安全密封

• FSS [Forward Secure Sealing]提供了一种至少仅使用单个系统即可检测到篡改的方法，尽管它不能提供外部日志记录可以提供的所有保证。

• 可以按固定的时间间隔“密封”由systemd日志处理的二进制日志。该密封是对日志数据的加密操作，以便可以检测到密封之前的任何篡改。

• FSS的算法基于“前向安全伪随机生成器”（FSPRG），

• 一个密钥是保存在系统中的“密封密钥”，另一个是“验证密钥”，应将其安全地存储在其他位置。使用FSPRG机制，使用不可逆过程定期生成新的密封密钥。更改后，旧密钥将从系统中安全删除。

• 验证密钥可用于计算任何给定时间范围内的密封密钥。这意味着攻击者只能访问当前的密封密钥（大概将用于下一个密封操作），而管理员可以可靠地生成任何密封密钥来验证以前的日志文件密封。在最后印章之前更改日志文件条目将导致验证失败。

然后，您的问题的答案：

问：在这种情况下，如何对加密的日志消息进行签名？

是日志文件并未真正加密或签名，但已密封。这是通过特定的加密操作完成的。密封操作的两个主要属性应该是：

1）前向安全性：

旨在伪造过去的日志条目时，对手无法从学习当前密钥中获得好处

2）可寻性：

审核员可以以任何顺序或访问方式验证日志条目的完整性，而实际上无需任何计算成本

Giorgia Azzurra Marson和Bertram Poettering撰写的文章：实用的安全日志记录：可寻找的顺序密钥生成器中提供了完整的细节。

您还可以检查fsprg.c的源代码