☰

「確認キーを外部に保存する必要がある場合」Journalctlはどのようにログに署名しますか？

tag-icon • tag-icon encryption journalctl
「確認キーを外部に保存する必要がある場合」Journalctlはどのようにログに署名しますか？ 
$ 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.

私が知っている限り、PKIシステムにログインすることは秘密鍵がある場合にのみ可能です。

私の知る限り、「認証キーは外部に保管する必要があります」秘密鍵（？）は他の場所に保管する必要がありますか？

尋ねる：では、この場合、暗号化されたログメッセージはどのように署名されますか？

私が知っている限り、暗号化されたログが署名されていない場合、攻撃者は変更されたログを暗号化してログを偽造する可能性があり、ログは署名されていないため許可されます。しかし、攻撃者が署名する可能性があるので、秘密鍵をそこに保管するのも良いことではありません。

答え1

まず、質問の主題が提示する意見のいくつかを理解する必要があります。LWN記事：前面安全シール

  • FSS [Forward Security Seal]は、少なくとも1つのシステムを使用して変調を検出する方法を提供します。外部ロギングが提供できるすべての保証を提供するわけではありません。。

  • systemd ロギングで処理されるバイナリログは、定期的に「封印」することができます。封印は、封印前の変調を検出できるように、ログデータの暗号化操作です。

  • FSSのアルゴリズムは、FSPRG（Forward Secure Pseudo-Random Generator）に基づいています。

  • 1つのキーはシステムに保管されている「封印キー」、もう1つは「確認キー」なので、別の場所に安全に保管する必要があります。 FSPRGメカニズムを使用すると、元に戻すことができないプロセスによって、新しい封印されたキーが定期的に生成されます。変更後、既存のキーはシステムから安全に削除されます。

  • 検証キーは、所与の期間中の封印キーを計算するために使用することができる。これは、攻撃者が現在の封印キー（次の封印操作に使用することができます）にのみアクセスできるのに対して、管理者は以前のログファイルの封印を確認するために封印キーを確実に生成できることを意味します。最後の封印の前にログファイルエントリを変更すると、検証は失敗します。

次に、質問に答えるには:

Q：もしそうなら、暗号化されたログメッセージはどのように署名されますか？

ログファイルは実際に暗号化または署名されませんが、密封する。これは特定の暗号化操作によって行われます。シール作業の2つの主な特性は次のとおりです。

1）前方セキュリティ：

敵が過去のログエントリを偽造しようとすると、現在のキーを学習しても何の利点も得られません。

2）検索可能性：

監査人は、計算コストをほとんど必要とせずに、順序やアクセスパターンに関係なく、ログエントリの整合性を確認できます。

詳細は次の記事に記載されています。実用的なセキュリティロギング：Giorgia Azzurra MarsonとBertram Poetteringの検索可能なシーケンシャルキージェネレータ。

ソースコードも見ることができます。fsprg.c

関連情報