Como o journalctl assina os logs se “A chave de verificação deve ser armazenada externamente”?

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, entrar em um sistema PKI só funciona se tivermos a chave privada.

afaik o advise: "A chave de verificação deve ser armazenada externamente." é que a chave privada (?) deve ser armazenada em outro lugar?

P: Então, como as mensagens de log criptografadas são assinadas nesta situação?

Se os registros criptografados não estiverem assinados, um invasor poderá falsificar os registros, criptografando os modificados e eles serão aceitos, uma vez que não estão assinados. Mas manter a chave privada lá também é ruim, já que eles podem ser assinados pelo invasor.

    

Answer 1

Em primeiro lugar, precisamos entender alguns pontos dados pelo a"rtigo do LWN: o selamento seguro

• 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.

Então, a resposta para sua pergunta:

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

é que os arquivos de log não são realmente criptografados nem assinados, mas são selados . Isso é feito através de uma operação criptográfica específica. As duas principais propriedades da operação de vedação devem ser:

1) segurança antecipada:

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

2) buscabilidade:

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

Detalhes completos são fornecidos no artigo: Registro Seguro Prático: Geradores de Chaves Sequenciais por Giorgia Azzurra Marson e Bertram Poettering a">.

Você também pode verificar o código-fonte de fsprg.c