In che modo journalctl firma i registri se "La chiave di verifica deve essere archiviata esternamente"?

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

dopo, l'accesso a un sistema PKI funziona solo se abbiamo la chiave privata.

afaik il consiglio: "La chiave di verifica deve essere memorizzata esternamente". è che la chiave privata (?) dovrebbe essere memorizzata in un altro posto?

D: Quindi come vengono firmati i messaggi di registro crittografati in questa situazione?

afaik se i registri crittografati non sono firmati, un utente malintenzionato può falsificare i registri crittografando quelli modificati e verrà accettato, poiché non sono firmati. Ma mantenere la chiave privata anche lì è di nuovo male, poiché potrebbero essere firmati dall'attaccante.

In primo luogo, dobbiamo comprendere alcuni punti forniti dall'articolo LWN: sigillatura sicura in avanti

• FSS [Forward Secure Sealing] fornisce un modo per rilevare almeno manomissioni utilizzando un solo sistema, sebbene non fornisca tutte le garanzie che la registrazione esterna può offrire .

• i registri binari gestiti dal journal di systemd possono essere "sigillati" a intervalli di tempo regolari. Tale sigillo è un'operazione crittografica sui dati di registro in modo tale da poter rilevare eventuali manomissioni prima del sigillo.

• L'algoritmo per FSS si basa su "Forward Secure Pseudo Random Generators" (FSPRG),

• Una chiave è la "chiave di tenuta" che viene conservata sul sistema e l'altra è la "chiave di verifica" che deve essere conservata in modo sicuro altrove. Utilizzando il meccanismo FSPRG, viene periodicamente generata una nuova chiave di tenuta mediante un processo non reversibile. La vecchia chiave viene quindi eliminata in modo sicuro dal sistema dopo la modifica.

• La chiave di verifica può essere utilizzata per calcolare la chiave di tenuta per un determinato intervallo di tempo. Ciò significa che l'attaccante può accedere solo alla chiave di tenuta corrente (che presumibilmente verrà utilizzata per la successiva operazione di tenuta), mentre l'amministratore può generare in modo affidabile qualsiasi chiave di tenuta per verificare i sigilli dei file di registro precedenti. La modifica delle voci del file di registro prima dell'ultimo sigillo comporterà un errore di verifica.

Quindi, la risposta alla tua domanda:

D: Quindi come vengono firmati i messaggi di registro crittografati in questa situazione?

è che i file di registro non sono realmente crittografati né firmati ma sono sigillati . Questo viene fatto tramite una specifica operazione crittografica. Le due proprietà principali dell'operazione di tenuta dovrebbero essere:

1) sicurezza diretta:

l'avversario non ottiene alcun vantaggio dall'apprendimento delle chiavi correnti quando mira a forgiare le voci del registro passate

2) cercabilità:

il revisore può verificare l'integrità delle voci di registro in qualsiasi ordine o modello di accesso, praticamente senza costi di calcolo

I dettagli completi sono riportati nell'articolo: Registrazione sicura pratica: generatori di chiavi sequenziali ricercabili di Giorgia Azzurra Marson e Bertram Poettering .

Puoi anche controllare il codice sorgente di fsprg.c