Wie signiert journalctl die Protokolle, wenn der "Bestätigungsschlüssel extern gespeichert werden soll"?

$ 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, das Anmelden in einem PKI-System funktioniert nur, wenn wir den privaten Schlüssel haben.

afaik der Hinweis: "Der Bestätigungsschlüssel sollte extern gespeichert werden." Soll der private Schlüssel (?) an einem anderen Ort gespeichert werden?

F: Wie werden die verschlüsselten Protokollnachrichten in dieser Situation signiert?

afaik Wenn die verschlüsselten Protokolle nicht signiert sind, kann ein Angreifer die Protokolle fälschen, indem er die geänderten verschlüsselt. Dies wird akzeptiert, da sie nicht signiert sind. Aber auch dort den privaten Schlüssel zu behalten ist wieder schlecht, da sie vom Angreifer signiert werden könnten.

Zunächst müssen wir einige Punkte des LWN-Artikels verstehen: Vorwärtssichere Abdichtung

• FSS [Forward Secure Sealing] bietet eine Möglichkeit, Manipulationen zumindest mit nur einem einzigen System zu erkennen, bietet jedoch nicht alle Garantien, die die externe Protokollierung bieten kann .

• Die vom systemd-Journal verarbeiteten Binärprotokolle können in regelmäßigen Zeitintervallen "versiegelt" werden. Dieses Siegel ist eine kryptografische Operation für die Protokolldaten, sodass Manipulationen vor dem Siegel erkannt werden können.

• Der Algorithmus für FSS basiert auf "Forward Secure Pseudo Random Generators" (FSPRG),

• Ein Schlüssel ist der "Versiegelungsschlüssel", der im System aufbewahrt wird, und der andere ist der "Verifizierungsschlüssel", der an anderer Stelle sicher aufbewahrt werden sollte. Unter Verwendung des FSPRG-Mechanismus wird periodisch ein neuer Versiegelungsschlüssel unter Verwendung eines nicht umkehrbaren Prozesses erzeugt. Der alte Schlüssel wird dann nach der Änderung sicher aus dem System gelöscht.

• Mit dem Bestätigungsschlüssel kann der Versiegelungsschlüssel für einen bestimmten Zeitraum berechnet werden. Dies bedeutet, dass der Angreifer nur auf den aktuellen Versiegelungsschlüssel zugreifen kann (der vermutlich für den nächsten Versiegelungsvorgang verwendet wird), während der Administrator zuverlässig jeden Versiegelungsschlüssel generieren kann, um frühere Versiegelungen der Protokolldatei zu überprüfen. Das Ändern von Protokolldateieinträgen vor dem letzten Siegel führt zu einem Überprüfungsfehler.

Dann die Antwort auf Ihre Frage:

F: Wie werden die verschlüsselten Protokollnachrichten in dieser Situation signiert?

ist, dass die Protokolldateien nicht wirklich verschlüsselt oder signiert sind, sondern versiegelt sind . Dies erfolgt über eine bestimmte kryptografische Operation. Die zwei Haupteigenschaften des Dichtungsvorgangs sollten sein:

1) Vorwärtssicherheit:

Der Gegner hat keinen Vorteil darin, aktuelle Schlüssel zu lernen, wenn er versucht, vergangene Protokolleinträge zu fälschen

2) Suchbarkeit:

Der Prüfer kann die Integrität von Protokolleinträgen in beliebiger Reihenfolge oder in jedem Zugriffsmuster praktisch ohne Rechenaufwand überprüfen

Ausführliche Informationen finden Sie im Artikel: Praktische sichere Protokollierung: Suchbare sequentielle Schlüsselgeneratoren von Giorgia Azzurra Marson und Bertram Poettering .

Sie können auch den Quellcode von fsprg.c überprüfen