Bagaimana cara jurnalctl menandatangani log jika “Kunci verifikasi harus disimpan secara eksternal.”?

$ 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, masuk dalam sistem PKI hanya berfungsi Jika kita memiliki kunci pribadi.

afaik saran: "Kunci verifikasi harus disimpan secara eksternal." Apakah kunci pribadi (?) harus disimpan di tempat lain?

T: Jadi bagaimana pesan log terenkripsi masuk dalam situasi ini?

afaik jika log terenkripsi tidak ditandatangani, maka penyerang dapat memalsukan log, dengan mengenkripsi yang dimodifikasi, dan itu akan diterima, karena mereka tidak ditandatangani. Tetapi menjaga kunci pribadi di sana juga sekali lagi buruk, karena mereka dapat ditandatangani oleh penyerang.

Pertama, kita perlu memahami beberapa poin yang diberikan oleh artikel LWN: Forward sealing secure

• FSS [Forward Secure Sealing] menyediakan cara untuk setidaknya mendeteksi gangguan menggunakan hanya satu sistem, meskipun itu tidak akan memberikan semua jaminan bahwa penebangan eksternal dapat .

• log biner yang ditangani oleh jurnal systemd dapat "disegel" secara berkala. Segel itu adalah operasi kriptografi pada data log sehingga setiap gangguan sebelum segel dapat dideteksi.

• Algoritma untuk FSS didasarkan pada "Forward Secure Pseudo Random Generator" (FSPRG),

• Satu kunci adalah "kunci segel" yang disimpan pada sistem, dan yang lainnya adalah "kunci verifikasi" yang harus disimpan dengan aman di tempat lain. Menggunakan mekanisme FSPRG, kunci penyegelan baru dihasilkan secara berkala menggunakan proses yang tidak dapat dibalik. Kunci lama kemudian dihapus dengan aman dari sistem setelah perubahan.

• Kunci verifikasi dapat digunakan untuk menghitung kunci penyegelan untuk rentang waktu tertentu. Itu berarti bahwa penyerang hanya dapat mengakses kunci penyegelan saat ini (yang mungkin akan digunakan untuk operasi penyegelan berikutnya), sementara administrator dapat dengan andal menghasilkan kunci penyegelan untuk memverifikasi segel file log sebelumnya. Mengubah entri file log sebelum segel terakhir akan menghasilkan kegagalan verifikasi.

Lalu, jawaban untuk pertanyaan Anda:

T: Jadi bagaimana pesan log terenkripsi masuk dalam situasi ini?

adalah bahwa file log tidak benar-benar dienkripsi atau ditandatangani tetapi disegel . Ini dilakukan melalui operasi kriptografi tertentu. Dua sifat utama dari operasi seal adalah:

1) keamanan maju:

musuh tidak mendapat keuntungan dari mempelajari kunci saat ini ketika bertujuan menempa entri log yang lalu

2) kemampuan dicari:

auditor dapat memverifikasi integritas entri log dalam urutan atau pola akses apa pun, tanpa biaya komputasi apa pun

Rincian lengkap diberikan dalam artikel: Pembalakan Aman Praktis: Seekable Sequential Key Generator oleh Giorgia Azzurra Marson dan Bertram Poettering .

Anda juga dapat memeriksa kode sumber fsprg.c