← X3DH/
X3DH · Bölüm 04 cryptography / x3dh

4. Güvenlik Değerlendirmeleri

4.1. Doğrulama

X3DH anahtar anlaşmasından önce veya sonra taraflar, kimlik açık anahtarları IK_A ve IK_B'yi doğrulanmış bir kanal üzerinden karşılaştırabilir. Örneğin açık anahtar parmak izlerini elle karşılaştırabilir veya bir QR kod tarayabilirler. Bunun nasıl yapılacağı bu belgenin kapsamı dışındadır.

Doğrulama yapılmazsa taraflar, kiminle iletişim kurduklarına dair hiçbir kriptografik güvence almaz.

4.2. Protokol tekrar oynatması

Alice'in ilk iletisi tek kullanımlık bir ön anahtar kullanmıyorsa, bu ileti Bob'a tekrar oynatılabilir ve Bob bunu kabul eder. Bu, Bob'un Alice'in kendisine aynı iletiyi (veya iletileri) tekrar tekrar gönderdiğini düşünmesine neden olabilir.

Bunu hafifletmek için X3DH sonrası bir protokol, Bob'dan gelen taze rastgele girdiye dayanarak Alice için yeni bir şifreleme anahtarını hızla müzakere etmek isteyebilir. Bu, Diffie-Hellman tabanlı cırcır protokollerinin [5] tipik davranışıdır.

Bob, gözlemlenen iletilerin bir kara listesini tutmak veya eski imzalı ön anahtarları daha hızlı yenilemek gibi başka hafifletmeler de deneyebilir. Bu hafifletmelerin analizi bu belgenin kapsamı dışındadır.

4.3. Tekrar oynatma ve anahtar yeniden kullanımı

Önceki bölümde ele alınan tekrar oynatmaların bir başka sonucu da, başarıyla tekrar oynatılan bir ilk iletinin Bob'un farklı protokol çalıştırmalarında aynı SK'yi türetmesine yol açacak olmasıdır.

Bu nedenle, X3DH sonrası herhangi bir protokol Bob şifreli veri göndermeden önce şifreleme anahtarını rastgeleleştirmek ZORUNDADIR. Örneğin Bob, rastgeleleştirilmiş bir şifreleme anahtarı elde etmek için SK'yi yeni üretilmiş bir DH çıktısıyla birleştiren DH tabanlı bir cırcır protokolü kullanabilir [5].

Bob'un şifreleme anahtarını rastgeleleştirmemesi yıkıcı anahtar yeniden kullanımına yol açabilir.

4.4. İnkâr edilebilirlik

X3DH, Alice'e ya da Bob'a iletişimlerinin içeriği veya iletişim kurdukları gerçeği konusunda yayımlanabilir bir kriptografik kanıt vermez.

OTR protokolünde [6] olduğu gibi, bazı durumlarda Alice veya Bob'dan alınmış meşru özel anahtarları ele geçirmiş üçüncü bir tarafa, Alice ile Bob arasında gibi görünen ve yalnızca Alice veya Bob'un meşru özel anahtarlarına erişimi olan başka bir tarafça hazırlanmış olabilecek bir iletişim dökümü sunulabilir (yani Alice veya Bob'un kendileri ya da onların özel anahtarlarını ele geçirmiş başka biri).

Taraflardan biri protokol çalıştırması sırasında üçüncü bir tarafla işbirliği yapıyorsa, bu üçüncü tarafa iletişimlerinin kanıtını sunabileceklerdir. "Çevrimiçi" inkâr edilebilirliğe ilişkin bu sınırlama eşzamansız ortama içkin görünmektedir [7].

4.5. İmzalar

Karşılıklı doğrulama ve ileri gizliliğin DH hesaplamalarıyla elde edildiği gözlenerek ön anahtar imzasını atlamak cazip gelebilir. Ancak bu, bir "zayıf ileri gizlilik" saldırısına izin verir: Kötü niyetli bir sunucu Alice'e sahte ön anahtarlar içeren bir ön anahtar paketi sağlayabilir ve daha sonra SK'yi hesaplamak için Bob'un IK_B anahtarını ele geçirebilir.

Alternatif olarak, DH tabanlı karşılıklı doğrulamanın (DH1 ve DH2) kimlik anahtarlarından gelen imzalarla değiştirilmesi cazip gelebilir. Ancak bu, inkâr edilebilirliği azaltır, ilk iletilerin boyutunu büyütür ve geçici veya ön anahtar özel anahtarları ele geçirilirse ya da imza düzeni kırılırsa oluşacak zararı artırır.

4.6. Anahtar ele geçirilmesi

Bir tarafın özel anahtarlarının ele geçirilmesi güvenlik üzerinde yıkıcı bir etki yapar, ancak geçici anahtarlar ve ön anahtarların kullanımı bir miktar hafifletme sağlar.

Bir tarafın kimlik özel anahtarının ele geçirilmesi, o tarafın başkalarına karşı taklit edilmesine izin verir. Bir tarafın ön anahtar özel anahtarlarının ele geçirilmesi ise, birçok etkene bağlı olarak, eski veya yeni SK değerlerinin güvenliğini etkileyebilir.

Olası tüm ele geçirilme senaryolarının tam analizi bu belgenin kapsamı dışındadır; ancak aşağıda olası bazı senaryoların kısmi analizi verilmiştir:

4.7. Sunucuya güven

Kötü niyetli bir sunucu, Alice ile Bob arasındaki iletişimin başarısız olmasına yol açabilir (örneğin iletileri iletmeyi reddederek).

Alice ve Bob, Bölüm 4.1'deki gibi birbirlerini doğrularsa, sunucunun kullanabileceği tek ek saldırı tek kullanımlık ön anahtarları vermeyi reddetmektir; bu da SK için ileri gizliliğin imzalı ön anahtarın ömrüne bağlı olmasına yol açar (önceki bölümde analiz edildiği gibi).

Başlangıçtaki ileri gizlilikteki bu azalma, bir tarafın kötü niyetli biçimde diğer tarafın tek kullanımlık ön anahtarlarını tüketmesi halinde de yaşanabilir; bu nedenle sunucu bunu önlemeye çalışmalıdır, örneğin ön anahtar paketi alma işlemlerine oran sınırı koyarak.

4.8. Kimlik bağlama

Bölüm 4.1'deki gibi doğrulama, bir "kimlik yanlış bağlama" veya "bilinmeyen anahtar paylaşımı" saldırısını mutlaka önlemez.

Bu, bir saldırgan ("Charlie") Bob'un kimlik anahtarı parmak izini Alice'e kendi (Charlie'nin) parmak iziymiş gibi sahte biçimde sunduğunda ve ardından ya Alice'in ilk iletisini Bob'a ilettiğinde ya da Bob'un iletişim bilgilerini kendi bilgileriymiş gibi sahte biçimde sunduğunda ortaya çıkar.

Bunun etkisi, Alice'in Charlie'ye ilk iletiyi gönderdiğini düşünürken aslında Bob'a göndermesidir.

Bunu zorlaştırmak için taraflar AD içine daha fazla tanımlayıcı bilgi ekleyebilir veya kullanıcı adları, telefon numaraları, gerçek adlar ya da başka tanımlayıcı bilgiler gibi daha fazla tanımlayıcı bilgiyi parmak izine özetleyebilir. Charlie bu ek değerler hakkında yalan söylemek zorunda kalacaktır; bu da zor olabilir.

Ancak Charlie'nin ek değerler hakkında yalan söylemesini güvenilir biçimde önlemenin bir yolu yoktur ve protokole daha fazla kimlik bilgisi eklemek çoğu zaman gizlilik, esneklik ve kullanıcı arayüzü açısından tavizler getirir. Bu tavizlerin ayrıntılı analizi bu belgenin kapsamı dışındadır.