Comment journalctl signe-t-il les journaux si la «clé de vérification doit être stockée en externe»?

$ 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, la connexion à un système PKI ne fonctionne que si nous avons la clé privée.

afaik le conseil: "La clé de vérification doit être stockée en externe." est-ce que la clé privée (?) doit être stockée à un autre endroit?

Q: Comment les messages de journal chiffrés sont-ils signés dans cette situation?

afaik si les journaux chiffrés ne sont pas signés, alors un attaquant peut truquer les journaux, en chiffrant les journaux modifiés, et il sera accepté, car ils ne sont pas signés. Mais garder la clé privée là-bas est également mauvais, car ils pourraient être signés par l'attaquant.

Tout d'abord, nous devons comprendre certains points donnés par l' article de LWN:

• FSS [Forward Secure Sealing] fournit un moyen de détecter au moins la falsification en utilisant un seul système, bien qu'il ne fournisse pas toutes les garanties que la journalisation externe peut .

• les journaux binaires traités par le journal systemd peuvent être "scellés" à intervalles de temps réguliers. Ce sceau est une opération cryptographique sur les données de journal de telle sorte que toute falsification avant le sceau puisse être détectée.

• L'algorithme pour FSS est basé sur des "Générateurs pseudo-aléatoires sécurisés avancés" (FSPRG),

• Une clé est la "clé de scellage" qui est conservée sur le système, et l'autre est la "clé de vérification" qui doit être stockée en toute sécurité ailleurs. À l'aide du mécanisme FSPRG, une nouvelle clé d'étanchéité est générée périodiquement à l'aide d'un processus non réversible. L'ancienne clé est ensuite supprimée du système en toute sécurité après la modification.

• La clé de vérification peut être utilisée pour calculer la clé de scellage pour une plage de temps donnée. Cela signifie que l'attaquant ne peut accéder qu'à la clé de scellage actuelle (qui sera vraisemblablement utilisée pour la prochaine opération de scellage), tandis que l'administrateur peut générer de manière fiable n'importe quelle clé de scellage pour vérifier les scellés des fichiers journaux précédents. La modification des entrées du fichier journal avant le dernier sceau entraînera un échec de vérification.

Ensuite, la réponse à votre question:

Q: Comment les messages de journal chiffrés sont-ils signés dans cette situation?

est que les fichiers journaux ne sont pas vraiment cryptés ni signés mais ils sont scellés . Cela se fait via une opération cryptographique spécifique. Les deux propriétés principales de l'opération d'étanchéité doivent être:

1) sécurité avancée:

l'adversaire ne tire aucun avantage de l'apprentissage des clés actuelles lorsqu'il vise à forger des entrées de journal antérieures

2) possibilité de recherche:

l'auditeur peut vérifier l'intégrité des entrées de journal dans n'importe quel ordre ou modèle d'accès, à peu près sans frais de calcul

Tous les détails sont donnés dans l'article: Journalisation sécurisée pratique: générateurs de clés séquentielles rechercheables par Giorgia Azzurra Marson et Bertram Poettering .

Vous pouvez également vérifier le code source de fsprg.c