Anda telah mengajukan pertanyaan yang bagus. Pertanyaannya tampaknya sangat sederhana, tetapi sebenarnya jawabannya agak lebih kompleks. Saya akan melakukan yang terbaik untuk menjawabnya secara ringkas. Juga, karena Anda menyebutkan ISAKMP, saya akan menganggap Anda tertarik pada IKEv1. Hal-hal berubah sedikit untuk IKEv2 (well, banyak), tetapi saya memang ingin menyebutkan jawaban di bawah ini hanya berkorelasi dengan IKEv1.
Fase 1 dapat dicapai dalam dua mod yang berbeda: Mode Utama dan Mode Agresif. Dalam kedua mode, pesan pertama dikirim oleh Inisiator, dan pesan kedua dikirim oleh Responder. Kedua pesan ini termasuk apa yang dikenal di dunia kriptografi sebagai Nonce . Nonce adalah angka yang dibuat secara acak untuk digunakan dalam pembuatan kunci. (istilah Nonce berasal dari _N_umber digunakan _Once_) . Jadi, setelah pesan 1 dan pesan 2, kedua belah pihak saling mengenal Nonces.
Nonce's dikombinasikan dengan Pre-Shared-Key untuk menciptakan nilai Seed untuk menghasilkan kunci rahasia. Bagian relatif IKE RFC ada di sini:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID adalah nilai Seed yang nantinya akan digunakan untuk menghasilkan kunci rahasia tambahan. Pre-Shared-Key dan kedua nilai Nonce (Ni_b adalah Nonce Inisiator, dan Nr_B adalah Nonce Responder) dikombinasikan dengan menggunakan PRF, atau Fungsi Acak Psuedo. PRF seperti algoritma hashing, kecuali bahwa hasilnya bisa sebanyak yang Anda butuhkan.
Sekarang, jika Anda awalnya melakukan Main Mode, pesan 3 dan 4 membagikan kunci publik Diffie-Hellman milik Inisiator dan Responder (masing-masing). Mereka berdua menggunakan nilai-nilai ini untuk menghasilkan rahasia bersama Diffie-Hellman . Jika Anda melakukan mode Agresif, nilai-nilai Publik DH ini juga termasuk dalam Pesan 1 dan Pesan 2 (bersama dengan Nonces).
Nilai Seed kemudian digabungkan dengan DH Shared Secret (dan beberapa nilai lainnya) untuk membuat tiga Kunci Sesi : kunci Derevatif, kunci Otentikasi, dan kunci Enkripsi. RFC menyatakannya sebagai berikut:
Hasil dari Mode Utama atau Mode Agresif adalah tiga kelompok materi kunci yang diautentikasi:
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d, _a, dan _e adalah tiga kunci Sesi yang disebutkan di atas. SKEYIDadalah nilai Seed. g^xyadalah Rahasia Bersama DH. CKY-Idan CKI-Rmerupakan Penggagas dan Pengirim Cookie, ini hanya nilai-nilai tambahan yang dihasilkan secara acak yang digunakan kemudian untuk mengidentifikasi pertukaran ISAKMP dan asosiasi keamanan khusus ini. 0 1 2adalah angka literal 0, 1, dan 2. Simbol Pipa |mewakili penggabungan.
Bagaimanapun, semua nilai ini digabungkan bersama-sama menggunakan PRF yang menciptakan tiga kunci Sesi:
- Kunci Derivatif - kunci ini tidak digunakan oleh ISAKMP, dan sebaliknya diserahkan ke IPsec sehingga IPsec dapat membuat Kunci Rahasia sendiri
- Kunci Otentikasi - kunci ini digunakan oleh ISAKMP dalam HMAC-nya (alias, algoritma Hashing diamankan dengan kunci Rahasia)
- Kunci Enkripsi - kunci ini digunakan oleh ISAKMP untuk mengenkripsi secara simetris apa pun yang ingin ISAKMP amankan ke rekan lain. Jadi jika algoritma Enkripsi yang dipilih untuk Phase1 adalah AES, AES akan menggunakan kunci ini untuk mengenkripsi data secara simetris - AES tidak akan menghasilkan materi kunci sendiri.
Kunci Otentikasi dan Kunci Enkripsi digunakan untuk mengamankan / mengenkripsi negosiasi Phase2 berikutnya. Dalam Mode Utama, pesan 5 dan 6 dari Phase1 juga dilindungi oleh tombol-tombol ini. Selanjutnya, setiap pertukaran informasi ISAKMP di masa depan (DPD, acara Rekey, Hapus pesan, dll) juga dilindungi oleh dua kunci ini.
Kunci Derivatif diserahkan kepada IPsec, dan IPsec menghasilkan materi Kunci sendiri dari Kunci ini. Jika Anda ingat, IPsec tidak secara bawaan menyertakan mekanisme Pertukaran Kunci, jadi satu-satunya cara untuk memperoleh kunci rahasia adalah dengan mengaturnya secara manual (yang kuno, dan tidak pernah benar-benar dilakukan lagi), ATAU bergantung pada layanan eksternal untuk berikan materi kunci, seperti ISAKMP.
RFC mengatakannya seperti ini:
SKEYID_e adalah materi kunci yang digunakan oleh ISAKMP SA untuk melindungi kerahasiaan pesannya.
SKEYID_a adalah materi kunci yang digunakan oleh ISAKMP SA untuk mengotentikasi pesannya.
SKEYID_d adalah material kunci yang digunakan untuk mendapatkan kunci untuk asosiasi keamanan non-ISAKMP.
Dengan semua itu, kami dapat merujuk kembali ke pertanyaan Anda: Kunci apa yang digunakan untuk mengamankan Pra-Berbagi-Kunci?
Dalam Mode Utama, Pra-Berbagi-Kunci (PSK) diverifikasi di Pesan 5 dan 6. Pesan 5 dan 6 Dilindungi oleh kunci Sesi yang dihasilkan ISAKMP, dijelaskan di atas.
Dalam Mode Agresif, tidak ada pesan dalam negosiasi yang dienkripsi. Dan PSK diverifikasi di Pesan 2 dan 3. Perhatikan, saya katakan dalam kedua kasus PSK diverifikasi , dan saya tidak pernah mengatakan PSK dipertukarkan . Jelas, jika tidak ada dalam mode Aggressive yang Dienkripsi, dan Anda cukup mengirim Pre-Shared-Key melalui kabel yang tidak terenkripsi, akan ada kerentanan keamanan yang sangat besar.
Beruntung bagi kami, para penulis ISAKMP sudah memikirkan hal itu. Dan sebagai hasilnya, mereka menciptakan metode khusus untuk memverifikasi bahwa masing-masing pihak memiliki PSK yang benar, tanpa benar-benar membagikannya melalui kawat. Ada dua item yang digunakan untuk memvalidasi masing-masing Peer bahwa mereka berdua memiliki PSK yang sama: Metode Identitas dan Identitas Hash .
Peer VPN dapat memilih untuk mengidentifikasi diri mereka dengan berbagai metode; paling umum, rekan hanya akan menggunakan alamat IP sumber mereka. Tetapi mereka memiliki opsi untuk menggunakan FQDN atau Hostname. Masing-masing, bersama dengan nilai korelasi untuk metode yang dipilih, adalah apa yang membentuk Metode Identitas. Jadi misalnya, jika saya memiliki IP 5.5.5.5, dan saya ingin menggunakan alamat IP saya untuk mengidentifikasi diri saya, Metode ID saya akan secara efektif menjadi [Alamat IP, 5.5.5.5] . (Catatan: KEDUA nilai membentuk seluruh Metode ID)
Metode ID kemudian digabungkan (menggunakan PRF) dengan nilai Seed yang telah kita bahas sebelumnya (SKEYID), dan beberapa nilai lainnya, untuk membuat Identity Hash . Ingat, bahwa yang menciptakan SKEYID pada awalnya adalah Pre-Shared-Key.
Metode ID dan ID Hash kemudian dikirim melintasi kawat, dan pihak lain mencoba untuk membuat kembali ID Hash menggunakan rumus yang sama. Jika penerima dapat membuat ulang ID Hash yang sama, itu membuktikan kepada penerima bahwa pengirim harus memiliki kunci pra-bagi-pakai yang benar.
Ini dijelaskan dalam RFC di sini:
Untuk mengotentikasi baik pertukaran, inisiator protokol menghasilkan HASH_I dan responden menghasilkan HASH_R di mana:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDii dan IDir adalah Metode ID. Dan HASH_I dan HASH_R adalah inisator dan hash Responder. Keduanya dibagikan di Phase1. Dari RFC:
Saat melakukan otentikasi kunci yang dibagikan sebelumnya, Mode Utama didefinisikan sebagai berikut:
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
Mode agresif dengan kunci yang dibagikan sebelumnya dijelaskan sebagai berikut:
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR, HASH_I -->
Dan sekarang, kami akhirnya dapat menjawab pertanyaan Anda sepenuhnya:
Pre-Shared-Key dikombinasikan menggunakan PRF dengan Nonces, dan banyak nilai lain yang diketahui orang lain dalam negosiasi. Hasilnya adalah nilai yang hanya bisa dicapai oleh dua pihak jika kedua belah pihak mulai dengan nilai yang sama - alias, kunci yang dibagikan sebelumnya yang sama. Nilai yang dihasilkan adalah apa yang dibagikan pada kabel, dengan memungkinkan dua pihak untuk memverifikasi bahwa mereka telah mencocokkan Tombol Sebelum Dibagikan tanpa benar-benar memaparkan informasi apa pun tentang Kunci Sebelum Dibagikan itu sendiri.
Mode Utama berjalan selangkah lebih aman dengan juga mengenkripsi pertukaran "nilai yang dihasilkan" yang dijelaskan di atas, sehingga semakin sulit untuk mengekstraksi informasi yang berguna tentang apa Pre-Shared-Key itu.
(Sepertinya saya gagal total dalam menjawab ini dengan ringkas)