Como o journalctl assina os logs se "A chave de verificação deve ser armazenada 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.

depois, entrar em um sistema PKI funciona apenas se tivermos a chave privada.

após o aviso: "A chave de verificação deve ser armazenada externamente." é que a chave privada (?) deve ser armazenada em outro local?

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

se os logs criptografados não forem assinados, um invasor poderá falsificar os logs, criptografando os modificados, e ele será aceito, uma vez que eles não são assinados. Mas manter a chave privada lá também é ruim novamente, pois elas podem ser assinadas pelo invasor.

Em primeiro lugar, precisamos entender alguns pontos apresentados no artigo do LWN:

• O FSS [Forward Secure Sealing] fornece uma maneira de, pelo menos, detectar adulterações usando apenas um único sistema, embora não forneça todas as garantias que o log externo pode oferecer .

• os logs binários manipulados pelo diário systemd podem ser "selados" em intervalos regulares. Esse selo é uma operação criptográfica nos dados do registro, de forma que qualquer violação anterior ao selo possa ser detectada.

• O algoritmo do FSS é baseado em "Geradores pseudo-aleatórios seguros para a frente" (FSPRG),

• Uma chave é a "chave de vedação" mantida no sistema e a outra é a "chave de verificação" que deve ser armazenada com segurança em outro local. Usando o mecanismo FSPRG, uma nova chave de vedação é gerada periodicamente usando um processo não reversível. A chave antiga é excluída com segurança do sistema após a alteração.

• A chave de verificação pode ser usada para calcular a chave de vedação para qualquer intervalo de tempo. Isso significa que o invasor pode acessar apenas a chave de vedação atual (que provavelmente será usada para a próxima operação de vedação), enquanto o administrador pode gerar com segurança qualquer chave de vedação para verificar as vedações anteriores do arquivo de log. Alterar as entradas do arquivo de log antes do último selo resultará em uma falha na verificação.

Em seguida, a resposta para sua pergunta:

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

é que os arquivos de log não são realmente criptografados nem assinados, mas são lacrados . 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 para a frente:

o adversário não obtém vantagem ao aprender as chaves atuais ao tentar falsificar entradas de log anteriores

2) busca:

o auditor pode verificar a integridade das entradas do log em qualquer ordem ou padrão de acesso, praticamente sem custo computacional

Detalhes completos são fornecidos no artigo: Registro seguro prático: geradores de chaves seqüenciais procuráveis ​​por Giorgia Azzurra Marson e Bertram Poettering .

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