Harika bir soru sordunuz. Soru çok basit görünüyor, ama aslında cevap biraz daha karmaşık. Kısa ve öz bir cevap vermek için elimden geleni yapacağım. Ayrıca, ISAKMP'den bahsettiğinizden beri, IKEv1 ile ilgilendiğinizi varsayacağım. IKEv2 için işler biraz değişiyor (iyi, çok), ancak aşağıdaki cevabın sadece IKEv1 ile ilişkili olduğunu belirtmek istedim.
Faz 1 iki farklı modda gerçekleştirilebilir: Ana Mod ve Agresif Mod. Her iki modda da ilk mesaj Başlatıcı tarafından ve ikinci mesaj Yanıtlayıcı tarafından gönderilir. Bu mesajların her ikisi de şifreleme dünyasında Nonce olarak bilinenleri içerir . Bir Nonce, anahtar oluşturmada kullanılacak rastgele üretilen bir sayıdır. (Nonce terimi kullanılan _N_umber'dan _Once_ gelir) . Yani, mesaj 1 ve mesaj 2'den sonra, her iki taraf birbirlerinin Nonces'lerini bilir.
Nonce'ler, gizli anahtarlar oluşturmak için bir Seed değeri oluşturmak üzere Ön Paylaşımlı Anahtar ile birleştirilir. IKE RFC'nin göreceli kısmı burada:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID, daha sonra ek gizli anahtarlar oluşturmak için kullanılacak Tohum değeridir. Ön Paylaşımlı Anahtar ve her iki Nonce değeri (Ni_b Başlatıcı'nın Nonce'si ve Nr_B, Yanıtlayıcının Nonce'si) bir PRF veya Psuedo Rastgele İşlevi kullanılarak birleştirilir. Bir PRF bir hash algoritması gibidir, ancak sonuç ihtiyacınız kadar bit olabilir.
Başlangıçta Ana Mod yapıyorsanız, 3 ve 4 numaralı mesajlar Başlatıcı ve Yanıtlayıcının (sırasıyla) Diffie-Hellman genel anahtarlarını paylaşır. Her ikisi de bu değerleri Diffie-Hellman paylaşılan sırrını oluşturmak için kullanır . Agresif mod yapıyorsanız, bu DH Public değerleri Message 1 ve Message 2'ye (Nonces ile birlikte) de dahil edilir.
Tohum değeri daha sonra üç Oturum Anahtarı oluşturmak için DH Shared Secret (ve birkaç başka değer) ile birleştirilir : Derevative anahtarı, Kimlik Doğrulama anahtarı ve Şifreleme anahtarı. RFC bunu şöyle ifade eder:
Ana Mod veya Agresif Modun sonucu, üç grup kimliği doğrulanmış anahtarlama malzemesidir:
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 ve _e, yukarıda belirtilen üç Oturum anahtarıdır. SKEYIDTohum değeridir. g^xyDH Paylaşılan Sırdır. CKY-Ive CKI-RBaşlatıcı ve Yanıtlayıcı Çerezleridir, bunlar daha sonra bu belirli ISAKMP alışverişi ve güvenlik ilişkisini tanımlamak için kullanılan, rastgele oluşturulmuş ek değerlerdir. 0 1 20, 1 ve 2 sabit sayılarıdır. Boru sembolü |birleştirme anlamına gelir.
Her durumda, tüm bu değerler üç Oturum anahtarı oluşturan bir PRF kullanılarak birleştirilir:
- Türev Anahtarı - Bu anahtar olduğunu değil ISAKMP kullandığı ve bunun yerine IPsec kendi gizli Keys oluşturabilir böylece IPsec teslim edilir
- Kimlik Doğrulama Anahtarı - bu anahtar HMAC'de ISAKMP tarafından kullanılır (diğer adıyla Gizli anahtarla güvenli Hashing algoritması)
- Şifreleme Anahtarı - Bu anahtar ISAKMP tarafından ISAKMP'nin diğer eşe güvenli bir şekilde istediği her şeyi simetrik olarak şifrelemek için kullanılır. Dolayısıyla, Aşama1 için seçilen Şifreleme algoritması AES ise, AES bu simetrik verileri şifrelemek için kullanır - AES kendi anahtarlama malzemesini oluşturmaz.
Doğrulama Anahtarı ve Şifreleme Anahtarı, bundan sonraki Faz 2 anlaşmasını güvence altına almak / şifrelemek için kullanılır. Ana Modda, Faz 1'in 5 ve 6 numaralı mesajları da bu tuşlarla korunur. Ayrıca, gelecekteki herhangi bir ISAKMP bilgi alışverişi (DPD, Rekey olayları, Mesajları sil vb.) De bu iki anahtarla korunur.
Türev Anahtarı IPsec'e verilir ve IPsec bu Anahtardan kendi Anahtarlama malzemesini oluşturur. Hatırlıyorsanız, IPsec doğal olarak bir Anahtar Değişimi mekanizması içermez, bu yüzden gizli anahtarları elde etmenin tek yolu onları manuel olarak ayarlamaktır (arkaiktir ve artık gerçekten yapılmaz), VEYA ISAKMP gibi anahtarlama malzemelerini sağlayın.
RFC bunu şöyle söylüyor:
SKEYID_e, ISAKMP SA tarafından mesajlarının gizliliğini korumak için kullanılan anahtarlama malzemesidir.
SKEYID_a, ISAKMP SA tarafından iletilerinin kimliğini doğrulamak için kullanılan anahtarlama malzemesidir.
SKEYID_d, ISAKMP dışı güvenlik ilişkilendirmeleri için anahtar türetmek amacıyla kullanılan anahtarlama malzemesidir.
Tüm bunları söyledikten sonra, sorunuza geri dönebiliriz: Ön Paylaşımlı Anahtarı güvence altına almak için hangi anahtar kullanılır?
Ana Modda, Önceden Paylaşılan Anahtar (PSK) İleti 5 ve 6'da doğrulanır. İleti 5 ve 6, yukarıda açıklanan ISAKMP'nin oluşturduğu Oturum anahtarlarıyla korunur.
Agresif Modda, görüşmedeki mesajların hiçbiri şifrelenmez. Ve PSK Mesajlar 2 ve 3'te doğrulandı. Uyarı, her iki durumda da PSK'nın doğrulandığını ve PSK'nın değiş tokuş edildiğini asla söylemedim . Açıkçası, Agresif moddaki hiçbir şey Şifrelenmemişse ve Ön Paylaşımlı Anahtarı şifrelenmemiş tel üzerinden gönderdiyseniz, büyük bir boşluk güvenlik açığı olacaktır.
Şanslıyız, ISAKMP yazarları bunu zaten düşünmüşlerdi. Sonuç olarak, her bir tarafın kabloda gerçekten paylaşmadan doğru PSK'ya sahip olduğunu doğrulamak için özel bir yöntem oluşturdular. Her bir Eşe her ikisinin de aynı PSK'ya sahip olduğunu doğrulamak için kullanılan iki öğe vardır: Kimlik Yöntemi ve Kimlik Karması .
VPN Eşleri kendilerini çeşitli yöntemlerle tanımlamayı seçebilir; en yaygın olarak, eşler basitçe kaynak IP adreslerini kullanırlar. Ancak FQDN veya Ana Bilgisayar Adı kullanma seçeneğine sahiptirler. Bunların her biri, seçilen yöntemin korelasyon değeri ile birlikte Kimlik Yöntemi'ni oluşturur. Örneğin, IP 5.5.5.5'e sahip olsaydım ve kendimi tanımlamak için IP adresimi kullanmak istersem, Kimlik Yöntemim etkili bir şekilde [IP Adresi, 5.5.5.5] olurdu . (Not: BOTH değerleri tüm Kimlik Yöntemini oluşturur)
Kimlik Yöntemi daha sonra (PRF kullanılarak) daha önce tartıştığımız Tohum değeri (SKEYID) ve birkaç değerle birleştirilir ve Kimlik Karması oluşturulur . Hatırlayın, SKEYID'i ilk etapta oluşturan şeyin Ön Paylaşımlı Anahtar olduğunu hatırlayın.
Kimlik Yöntemi ve Kimlik Karması daha sonra kablo üzerinden gönderilir ve karşı taraf aynı formülü kullanarak Kimlik Karmasını yeniden oluşturmaya çalışır. Alıcı aynı kimlik karmasını yeniden oluşturabiliyorsa, göndericinin doğru önceden paylaşılan anahtara sahip olması gerektiğini alıcıya kanıtlar.
Bu, burada RFC'de açıklanmaktadır:
Kimlik doğrulamasını yapmak için, protokolün başlatıcısı HASH_I ve yanıtlayan HASH_R üretir, burada:
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 ve IDir, ID Yöntemi'dir. Ve HASH_I ve HASH_R Başlatıcı ve Yanıtlayıcı karmasıdır. Bunların her ikisi de Aşama 1'de paylaşılmaktadır. RFC'den:
Önceden paylaşılan bir anahtar kimlik doğrulaması yaparken Ana Mod aşağıdaki gibi tanımlanır:
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
Önceden paylaşılan bir anahtar içeren agresif mod aşağıdaki gibi açıklanır:
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR, HASH_I -->
Ve şimdi, nihayet sorunuza tam olarak cevap verebiliriz:
Ön Paylaşımlı Anahtar, Nonces ile bir PRF ve görüşmedeki herkes tarafından bilinen bir dizi başka değer kullanılarak birleştirilir. Sonuç, her iki tarafın da aynı değerlerle (yani aynı önceden paylaşılmış anahtarla) başlatılması durumunda iki tarafça karşılıklı olarak elde edilebilecek bir değerdir. Ortaya çıkan değer, tel üzerinde paylaşılan değerdir ve iki tarafın Ön Paylaşımlı Anahtarın kendisi hakkında herhangi bir bilgi göstermeden eşleşen Ön Paylaşımlı Anahtarlara sahip olduklarını doğrulamasına izin verir.
Ana Mod, yukarıda açıklanan "sonuç değerinin" değişimini şifreleyerek bir adım daha güvenli hale gelir ve Ön Paylaşımlı Anahtarın ne olduğu hakkında yararlı bilgilerin çıkarılmasını daha da zorlaştırır.
(bu özlü bir şekilde cevap vermede perişan bir şekilde başarısız oldum)