¿Cómo firma Journalctl los registros si “La clave de verificación debe almacenarse externamente”?

$ 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, iniciar sesión en un sistema PKI solo funciona si tenemos la clave privada.

afaik el consejo: "La clave de verificación debe almacenarse externamente". ¿Es que la clave privada (?) debe almacenarse en otro lugar?

P: Entonces, ¿cómo se firman los mensajes de registro cifrados en esta situación?

afaik si los registros encriptados no están firmados, entonces un atacante puede falsificar los registros encriptando los modificados, y será aceptado, ya que no están firmados. Pero mantener la clave privada allí también es malo, ya que podrían ser firmados por el atacante.

En primer lugar, debemos comprender algunos puntos dados por el artículo de LWN: sellado seguro hacia adelante

• FSS [Forward Secure Sealing] proporciona una forma de al menos detectar la manipulación mediante un solo sistema, aunque no proporcionará todas las garantías que el registro externo puede .

• los registros binarios manejados por el diario systemd se pueden "sellar" a intervalos regulares de tiempo. Ese sello es una operación criptográfica en los datos de registro de manera que se puede detectar cualquier alteración antes del sello.

• El algoritmo para FSS se basa en "Forward Secure Pseudo Random Generators" (FSPRG),

• Una clave es la "clave de sellado" que se mantiene en el sistema, y ​​la otra es la "clave de verificación" que debe almacenarse de forma segura en otro lugar. Usando el mecanismo FSPRG, se genera periódicamente una nueva llave de sellado utilizando un proceso no reversible. La clave anterior se elimina de forma segura del sistema después del cambio.

• La clave de verificación se puede utilizar para calcular la clave de sellado para cualquier rango de tiempo dado. Eso significa que el atacante solo puede acceder a la clave de sellado actual (que probablemente se utilizará para la próxima operación de sellado), mientras que el administrador puede generar de manera confiable cualquier clave de sellado para verificar los sellos de archivos de registro anteriores. Cambiar las entradas del archivo de registro antes del último sello resultará en una falla de verificación.

Luego, la respuesta a tu pregunta:

P: Entonces, ¿cómo se firman los mensajes de registro cifrados en esta situación?

es que los archivos de registro no están realmente cifrados ni firmados, pero están sellados . Esto se realiza a través de una operación criptográfica específica. Las dos propiedades principales de la operación de sellado deben ser:

1) seguridad delantera:

el adversario no obtiene ninguna ventaja al aprender las claves actuales cuando intenta forjar entradas de registro pasadas

2) capacidad de búsqueda:

el auditor puede verificar la integridad de las entradas de registro en cualquier orden o patrón de acceso, prácticamente sin costo computacional

Los detalles completos se dan en el artículo: Registro seguro práctico: generadores de claves secuenciales buscables por Giorgia Azzurra Marson y Bertram Poettering .

También puede consultar el código fuente de fsprg.c