Как 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 совет: «Ключ проверки должен храниться извне». Это закрытый ключ (?) должен храниться в другом месте?

Q: Так как зашифрованные сообщения журнала подписываются в этой ситуации?

afaik, если зашифрованные журналы не подписаны, то злоумышленник может подделать журналы, зашифровав измененные, и это будет принято, поскольку они не подписаны. Но хранить закрытый ключ там тоже плохо, так как он может быть подписан злоумышленником.

Во-первых, нам нужно понять некоторые моменты, изложенные в статье LWN: прямая надежная герметизация

• FSS [Forward Secure Sealing] предоставляет способ, по крайней мере, для обнаружения взлома, используя только одну систему, хотя он не обеспечивает всех гарантий, которые может сделать внешняя регистрация .

• двоичные журналы, обрабатываемые журналом systemd, могут быть «запечатаны» через регулярные промежутки времени. Эта печать является криптографической операцией с данными журнала, так что может быть обнаружено любое вмешательство перед печатью.

• Алгоритм для FSS основан на «Прямых безопасных псевдослучайных генераторах» (FSPRG),

• Один ключ - это «ключ запечатывания», который хранится в системе, а другой - «ключ проверки», который следует надежно хранить в другом месте. Используя механизм FSPRG, новый ключ герметизации генерируется периодически с использованием необратимого процесса. После этого старый ключ надежно удаляется из системы.

• Ключ проверки можно использовать для расчета ключа герметизации для любого заданного временного диапазона. Это означает, что злоумышленник может получить доступ только к текущему ключу запечатывания (который, вероятно, будет использоваться для следующей операции запечатывания), в то время как администратор может надежно создать любой ключ запечатывания для проверки предыдущих запечатываний файла журнала. Изменение записей файла журнала до последней печати приведет к ошибке проверки.

Затем ответьте на свой вопрос:

Q: Так как зашифрованные сообщения журнала подписываются в этой ситуации?

заключается в том, что файлы журнала не зашифрованы и не подписаны, но они запечатаны . Это делается с помощью специальной криптографической операции. Два основных свойства операции уплотнения должны быть:

1) форвардная безопасность:

злоумышленник не получает никаких преимуществ от изучения текущих ключей, когда стремится подделать прошлые записи в журнале

2) поиск:

аудитор может проверить целостность записей журнала в любом порядке или схеме доступа практически без затрат на вычисления.

Полная информация дана в статье: Практическое безопасное ведение журнала: Seekable последовательные генераторы ключей от Giorgia Azzurra Marson и Bertram Poettering .

Вы также можете проверить исходный код fsprg.c