TLS yığınlarınızın sessizce güvendiği açıklanmayan NIST eğri seed'leri

dev.to'da yayımlanan bir yazı, kendisine herkesin bağımlı olduğu halde neredeyse kimsenin incelemediği bir kriptografik altyapı parçasına dikkat çekiyor: NIST eliptik eğrilerinin türetildiği seed'ler. Schiff Heimlich adıyla yazan bir sistem yöneticisi tarafından kaleme alınan ve Filippo Valsorda'nın ECDSA eğri seed'lerinin nereden geldiğine dair derinlemesine incelemesinden ilham alan yazı, modern TLS yığınları çalıştıran operatörlerin rutin olarak kökenini doğrulayamadıkları sabitlere güvendiğini savunuyor.

1990'lardan kalma şeffaf olmayan sabitler

NIST eğrileri P-256, P-384 ve P-521 — çoğu ECDSA sertifikasının bel kemiği, daha küçük anahtarları ve daha iyi performansları nedeniyle RSA'ya tercih edilen — her biri bir seed'den türetilmiştir. Bu seed'ler herkese açıktır. Örneğin P-256 seed'i c49d3608 86e70493 6a6678e1 139d26b7 819f7e90 değeridir.

Yazıya göre asıl açıklanmayan şey, bu seed'lerin içine neyin girdiğidir. Seed'ler 1990'larda NSA tarafından, görünüşe göre bir girdinin SHA-1 ile hash'lenmesi sonucu üretildi. Resmi açıklama rastgele bir değerin hash'lendiği yönündeydi, ancak bu değerin kendisi hiçbir zaman yayımlanmadı. Bu durum, eğrileri kullanan herkesi türetmeyi yeniden üretilemez hale getiriyor — ki bu da seed yayımlamanın asıl amacını, yani dışarıdan gelenlerin parametrelerin bir zayıflığı gizlemek için özellikle seçilmediğini doğrulayabilmesini fiilen ortadan kaldırıyor.

Bilinen bir açık değil, bir güven sorusu

Heimlich, bir backdoor iddiasında bulunmama konusunda özenli. Yazıda belirtildiği üzere kriptografi topluluğu NIST eğrilerini kapsamlı biçimde analiz etti ve hiçbir zayıflık bulamadı. Sorun köken meselesi: nginx'e ssl_ecdh_curve secp256r1 yapılandırıldığında ya da Go'nun crypto/tls paketi varsayılan olarak P-256'yı seçtiğinde, operatör onlarca yıl önce üretilmiş açıklanmayan bir sabite güvenmiş oluyor.

Yazı, çoğu dağıtım için bunun sorun olmadığını — matematiğin sağlam olduğunu — kabul ediyor. Ancak regüle edilmiş ortamlarda ya da bir denetçinin doğrulanamayan rastgelelik iddialarını kabul etmeyeceği her yerde alternatifler mevcut.

Şeffaf alternatifler

Yazı, sabitlerini herkesin doğrulayabildiği iki eğri ailesini öne çıkarıyor:

• Curve25519 ve Ed25519. Bunların karşılık gelen başlangıç değerleri tamamen açıklanabilir — Curve25519 için küçük 9 tam sayısı, Ed25519 içinse "Ed25519" dizgisinin bir hash'i. Her ikisi de modern TLS kütüphanelerinde yaygın biçimde destekleniyor. Önerilen yapılandırma, uyumluluk için P-256'yı korurken X25519'u öne çıkarıyor: nginx'de ssl_ecdh_curve X25519:secp256r1; ya da Go'nun tls.Config'inde CurvePreferences: []tls.CurveID{tls.X25519, tls.P256}.
• Brainpool eğrileri. brainpoolP256r1 gibi türevler, seed'lerini pi ve e'nin basamaklarından alıyor ve NIST eğrilerine daha yakın bir biçimde şeffaf parametreler sunuyor. Bunun bedeli ise uygulamalar arası desteğin daha dar olması.

Gerçekte ne çalıştığınızı denetlemek

Herhangi bir değişiklik yapmadan önce, yazı varsayılanlar hakkında tahminlere dayanmak yerine altyapınızın pratikte neyi müzakere ettiğini kontrol etmeyi öneriyor:

openssl s_client -connect yourhost:443 -curves P-256:X25519 </dev/null 2>/dev/null | grep "Curve is"

Neden önemli

Bu, bir güvenlik acil durumundan çok TLS'den sorumlu herkes için bir hijyen meselesi. Eğrilerin kırıldığı bilinmiyor ve yazı yarın P-256'yı söküp atmayı açıkça önermiyor. Ancak arkasındaki seed'ler, çoğu ekibin hiç bilinçli olarak vermediği süregiden bir güven kararını temsil ediyor ve kriptografik parametrelerle ilgili uyumluluk gereksinimlerinin bulunduğu ortamlarda bu karar, dokümantasyon olmadan savunulması zor bir karardır.

dev.to yazısından pratik çıkarım mütevazı ve uygulanabilir: servislerinizin hangi eğrileri müzakere ettiğini bilin, nedenini anlayın ve doğrulanabilir köken sizin için önemliyse, sabitleri herkes tarafından kontrol edilebilen X25519 gibi eğrileri tercih edin. Yazının vardığı sonuç şu: seed'ler bir güvenlik açığı değil — bir güven kararı ve bilinçli bir şekilde verilmesi gereken bir karardır.