☰

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

tag-icon • tag-icon encryption journalctl
如果“验证密钥应该存储在外部”，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.

据我所知，只有当我们拥有私钥时，才能在 PKI 系统中签名。

据我所知，建议：“验证密钥应存储在外部。”私钥（？）应该存储在其他地方吗？

问：那么在这种情况下加密的日志消息是如何签名的呢？

据我所知，如果加密的日志没有签名，那么攻击者可以通过加密修改后的日志来伪造日志，并且日志将被接受，因为它们没有签名。但将私钥保留在那里也很糟糕，因为它们可能会被攻击者签名。

答案1

首先我们需要了解一下题主给出的一些观点LWN 文章：前向安全密封

  • FSS [前向安全密封] 提供了一种至少仅使用单个系统即可检测篡改的方法它不会提供外部日志记录可以提供的所有保证。

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

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

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

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

然后，回答你的问题：

问：那么在这种情况下加密的日志消息是如何签名的呢？

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

1）前向安全：

当对手试图伪造过去的日志条目时，对手无法从学习当前密钥中获得任何优势

2）可查找性：

审计员可以以任何顺序或访问模式验证日志条目的完整性，几乎不需要计算成本

文章中给出了完整的详细信息：实用的安全日志记录：可查找的顺序密钥生成器，作者：Giorgia Azzurra Marson 和 Bertram Poettering。

您还可以查看源代码fsprg.c

相关内容