Neden şimdi?
"Şimdi topla, sonra çöz" (harvest now, decrypt later) saldırı modeli, bugün ele geçirilen şifreli trafiğin yeterince güçlü bir kuantum bilgisayar ortaya çıktığında geriye dönük çözülebileceği varsayımına dayanıyor. NIST'in 2024'te nihaileştirdiği kuantum sonrası kriptografi (PQC) standartları, ABD ulusal güvenlik sistemleri için 2033 gibi net son tarihler koyarken, büyük bulut sağlayıcıları ve tarayıcılar hibrit PQC desteğini 2025-2026 arasında varsayılan hale getirmeye başladı. Uzun ömürlü gizlilik gerektiren veriler (sağlık kayıtları, devlet iletişimi, fikri mülkiyet) için geçiş artık teorik değil, operasyonel bir öncelik.
Yeni standartlar: ML-KEM, ML-DSA, SLH-DSA
NIST FIPS 203/204/205 ile üç algoritma ailesi resmileşti:
- ML-KEM (FIPS 203, eski adıyla CRYSTALS-Kyber): Anahtar kapsülleme mekanizması (KEM), TLS anahtar değişiminde RSA/ECDH'nin yerini alıyor. Kafes tabanlı (lattice-based) bir yapı kullanır.
- ML-DSA (FIPS 204, eski adıyla CRYSTALS-Dilithium): Dijital imza standardı; sertifikalarda ve kod imzalamada RSA/ECDSA'nın yerini almayı hedefliyor.
- SLH-DSA (FIPS 205, eski adıyla SPHINCS+): Hash tabanlı, kafes varsayımlarına dayanmayan alternatif imza şeması; ML-DSA'ya kriptografik çeşitlilik sağlamak için tutulan yedek.
Bunlara ek olarak FIPS 206 ile FN-DSA (Falcon) standardizasyonu da ilerliyor; küçük imza boyutu gerektiren kısıtlı ortamlar için önemli.
Hibrit yaklaşım: neden tek başına PQC yeterli değil
Yeni algoritmalar matematiksel olarak farklı zorluk varsayımlarına dayansa da göreceli olarak genç oldukları için kriptanaliz riski klasik eğrilere göre daha az test edilmiş kabul ediliyor. Bu yüzden endüstri, geçiş döneminde hibrit anahtar değişimi kullanıyor: X25519 (klasik) ile ML-KEM-768 (PQC) aynı el sıkışmada birleştirilir; oturum anahtarı her iki bileşenin de kırılmasını gerektirir. TLS 1.3'te bu, IETF taslağı "X25519MLKEM768" grup kimliğiyle tanımlanıyor ve Chrome, Firefox ile OpenSSL 3.2+ tarafından destekleniyor.
CODE TERMINAL
# OpenSSL 3.2+ ile hibrit grup desteğini kontrol etme
openssl list -kem-algorithms | grep -i mlkem
# Nginx 1.25+ / OpenSSL ile hibrit TLS 1.3 grubunu etkinleştirme
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1;
# Bağlantının hangi grubu kullandığını doğrulama
openssl s_client -connect ornek-alan.com:443 -tls1_3 -groups X25519MLKEM768 2>/dev/null | grep "Server Temp Key"Envanter çıkarmadan geçiş olmaz
PQC geçişi önce bir kriptografik envanter (CBOM - Cryptography Bill of Materials) gerektirir:
- TLS sonlandırma noktaları: yük dengeleyiciler, CDN, ters proxy'ler.
- Kod ve firmware imzalama zincirleri (CI/CD, paket yöneticileri, IoT/OT güncellemeleri).
- Uzun ömürlü belgeler ve arşivler için kullanılan şifreleme (PDF imzaları, e-posta S/MIME).
- Donanım güvenlik modülleri (HSM) ve akıllı kartların PQC algoritma desteği.
- Üçüncü taraf kütüphaneler ve bağımlılıklardaki gömülü kriptografi (SBOM ile çapraz eşleme).
Envanterden sonra öncelik, kriptografik çevikliği (crypto-agility) en düşük olan sistemlere verilmeli: sabit algoritma ID'leri kod içine gömülü, güncellenmesi yıllar süren gömülü/endüstriyel sistemler en riskli kategoridir.
Sertifika otoritelerinde ve PKI'da durum
Genel güven ekosistemi henüz tam ML-DSA sertifikalarına geçmedi; CA/Browser Forum ve IETF, klasik ve PQC imzalarını birlikte taşıyan "kataliz" (composite) sertifika formatları üzerinde çalışıyor. Kurum içi PKI'lar için önerilen yol:
- Kök CA'yı ML-DSA-87 ile yeniden kurmak yerine önce ara CA seviyesinde hibrit imza (ECDSA + ML-DSA) pilotu yapın.
- HSM'lerinizin FIPS 204 desteğini üreticinizle doğrulayın; birçok HSM üretici yazılım güncellemesiyle destek ekliyor.
- Sertifika ömürlerini kısaltarak (90 gün ve altı) algoritma değişikliklerinin daha hızlı yayılmasını sağlayın.
Uygulama katmanında somut adımlar
- TLS sonlandırma yapan tüm bileşenlerde OpenSSL/BoringSSL/wolfSSL sürümlerini hibrit KEM destekleyen sürümlere yükseltin.
- Test ortamında X25519MLKEM768 grubunu zorunlu kılıp performans ve el sıkışma boyutu etkisini ölçün (PQC anahtarları klasik eğrilerden büyüktür, MTU/parçalanma etkisini kontrol edin).
- Kod imzalama boru hattında Sigstore/cosign gibi araçların PQC yol haritasını izleyin ve imza doğrulama servislerini algoritma-bağımsız (agile) tasarlayın.
- Uzun ömürlü gizlilik gerektiren arşivlenmiş verileri, mümkün olan yerlerde simetrik şifrelemeyle (AES-256, kuantuma karşı görece dayanıklı) yeniden şifreleyin.
- Tedarikçilerinizden PQC destek zaman çizelgesi isteyin; sözleşmelere kriptografik çeviklik maddesi ekleyin.
Sık yapılan hatalar
- PQC'yi yalnızca TLS ile sınırlı sanmak: imza, VPN (IKEv2), SSH ve S/MIME de kapsam dışında bırakılmamalı.
- Hibrit modu atlayıp doğrudan saf PQC'ye geçmek: birlikte çalışabilirlik sorunlarına ve olası kriptanaliz risklerine karşı savunmasız kalınır.
- Performans testi yapmadan üretime almak: ML-KEM anahtarları ve ML-DSA imzaları klasik muadillerinden belirgin biçimde büyük, CPU ve bant genişliği etkisini önceden ölçün.
- Envanter çıkarmadan "PQC'ye geçtik" demek: gömülü kriptografi ve üçüncü taraf bağımlılıklar genellikle gözden kaçar.
Kuantum sonrası kriptografiye geçiş, tek seferlik bir yama değil, çok yıllı bir programdır. Bugün atılacak en değerli adım; envanter çıkarmak, hibrit TLS'i pilot ortamda etkinleştirmek ve kriptografik çevikliği mimari bir gereksinim haline getirmektir.
TR Siber Ekibi